Zamieniaj e-maile w przychody dzięki Brew.
Połącz Stripe z Brew, wybierz właściwe zdarzenia płatności i przed wysłaniem kolejnych przypomnień sprawdzaj bieżący stan faktury lub subskrypcji.
Stripe emituje zdarzenia, gdy zmieniają się subskrypcje, faktury i płatności. Takie zdarzenia mogą uruchamiać przydatne e-maile, ale każda wiadomość nadal potrzebuje określonego odbiorcy, celu i reguły, która rozstrzyga, czy wysyłka jest jeszcze na czasie.
Integracja Brew ze Stripe obsługuje połączenie OAuth i konfigurację webhooka. Ten poradnik pokazuje, jak zaprojektować program e-maili, który na tej podstawie zbudujesz. Sekwencje, które startują od zdarzeń w produkcie, a nie od płatności, opisuje poradnik Automatyzacja e-maili z AI.
| Cel | Zdarzenie do rozważenia | Co sprawdzić przed wysyłką |
|---|---|---|
| Powitanie subskrybenta | customer.subscription.created |
Unikaj podwójnego powitania po zdarzeniu z Checkout |
| Informacja o końcu okresu próbnego | customer.subscription.trial_will_end |
Faktyczny termin i to, czy nastąpi obciążenie |
| Informacja o nieudanej płatności za fakturę | invoice.payment_failed |
Aktualna faktura, link do płatności, powiadomienia, które już wysyła Stripe |
| Wyjaśnienie zmiany planu | customer.subscription.updated |
Które pola się zmieniły i czy zmiana ma znaczenie |
| Potwierdzenie anulowania subskrypcji | customer.subscription.deleted |
Kiedy kończy się dostęp i o co prosił klient |
| Wyjaśnienie zwrotu | refund.created |
Pola dotyczące zwrotu dostępne w zdarzeniu |
Korzystaj z dokumentacji zdarzeń Stripe i schematu wybranego wyzwalacza w Brew. Aktualizacja subskrypcji może oznaczać różne rodzaje zmian, więc nie wysyłaj e-maila o zmianie planu po każdej aktualizacji bez sprawdzenia jej danych.
Autoryzuj Stripe na stronie Integracje w Brew. Brew rejestruje webhook i konfiguruje obsługiwane wyzwalacze. Nie ma przełącznika do włączania lub wyłączania zdarzeń. Uruchamiają się tylko aktywne automatyzacje powiązane ze zdarzeniem.
Jeśli chcesz zaimportować wcześniejsze kontakty, użyj opcji „Synchronizuj klientów ze Stripe”. Import kontaktu z danych płatności nie oznacza zgody marketingowej. Ustawienie „Synchronizuj imię i nazwisko”, określane osobno dla każdego zdarzenia, decyduje o aktualizacji imienia i nazwiska, a nie o tym, czy e-maile zostaną wysłane.
Pierwszą automatyzację zbuduj jako wersję roboczą, obejrzyj wygenerowany e-mail i przed publikacją przetestuj ją na kontrolowanych odbiorcach. Szczegóły połączenia znajdziesz w instrukcji konfiguracji Stripe; Brew łączy się z kontami Stripe w trybie produkcyjnym, a zdarzenia z trybu testowego nie uruchamiają automatyzacji.
Natychmiastowe powiadomienie o nieudanej płatności może startować od invoice.payment_failed. Wyjaśnij, co się stało, i dodaj link do własnej strony płatności. Nie obiecuj, że Brew ponowi obciążenie – za operacje płatnicze odpowiada Stripe.
Jeśli chcesz wysłać przypomnienie trzy dni później, niech Twoja aplikacja zaplanuje sprawdzenie statusu faktury. Jeśli faktura nadal jest nieopłacona, a klient nadal spełnia warunki, wywołaj osobne zdarzenie przypomnienia w Brew. Jeśli płatność udało się odzyskać, zakończ bez wywoływania go.
Po kroku „Czekaj” pola zdarzenia nadal zawierają pierwotne dane zdarzenia. Warunek na contact.stripe_subscription_status odczytuje bieżącą wartość pola kontaktu w Brew w chwili wykonania tego kroku. Nie odpytuje Stripe i nie dowodzi, że ta konkretna faktura została opłacona. Późniejsze zdarzenie invoice.paid nie anuluje automatycznie starszego uruchomienia. Aktualizacja metody płatności również nie jest dowodem płatności.
Przetestuj trzy przypadki: płatność odzyskaną przed zaplanowanym sprawdzeniem, fakturę, która pozostaje nieopłacona, i ponowione zadanie. W ramach udokumentowanego okna ponowień używaj tego samego klucza idempotentności dla tego samego zdarzenia logicznego.
Brew może synchronizować w kontaktach pola z danymi o płatnościach, w tym status subskrypcji i plan. Dane zdarzeń i pola kontaktu to różne źródła. Zanim użyjesz amount, currency, invoiceNumber, previousPlan, newPlan lub failureMessage, przeczytaj schemat wyzwalacza – nie każde zdarzenie dostarcza każde z tych pól.
Identyfikatory obiektów Stripe są pomijane w danych zdarzenia przekazywanych do automatyzacji. Nie składaj adresu URL portalu klienta z domniemanego identyfikatora faktury lub subskrypcji. Używaj strony płatności w swojej aplikacji (dostępnej po zalogowaniu) albo linku celowo przekazanego we własnym zdarzeniu. Postępuj zgodnie z poradnikiem o tagach personalizacji.
Przejrzyj ustawienia e-maili do klientów w Stripe. Zdecyduj, który system wysyła potwierdzenia płatności, powiadomienia o nieudanych płatnościach i przypomnienia. Włączenie automatyzacji w Brew nie wyłącza e-maili wysyłanych przez Stripe.
Nie umieszczaj treści promocyjnych w powiadomieniach dotyczących konta, dopóki nie sprawdzisz celu wiadomości i posiadanych zgód. Przypomnienia marketingowe wymagają odpowiedniej zgody i obsługi wypisań.
Upewnij się, że zdarzenie widać w Brew, powiązana automatyzacja jest aktywna, a jej historia uruchomień pokazuje oczekiwanego odbiorcę i wynik. Potem obejrzyj odebrany e-mail i link do płatności. Jeśli zdarzenie dotarło, ale wiadomość nie została wysłana, sprawdź filtry, wykluczenia i gotowość domeny wysyłkowej, zanim uznasz, że zawiódł webhook.
Zacznij od jednego zdarzenia i jednego przetestowanego e-maila. Kolejne przypomnienia dodawaj dopiero wtedy, gdy sprawdzanie bieżącego stanu i obsługę ponowień obejmą testy Twojej aplikacji.
