Stripe를 Brew에 연결하고 알맞은 결제 이벤트를 고르세요. 이후 리마인더를 보내기 전에 인보이스나 구독의 현재 상태를 확인하는 방법도 정리했어요.
Stripe는 구독, 인보이스, 결제가 바뀔 때 이벤트를 발생시켜요. 이 이벤트로 유용한 이메일을 시작할 수 있지만, 메시지마다 수신자와 목적, 그리고 지금 보내는 게 맞는지 판단할 규칙은 여전히 정해 둬야 해요.
OAuth 연결과 웹훅 설정은 Brew의 Stripe 연동이 처리해요. 이 가이드는 그 위에서 이메일 프로그램을 설계하는 방법을 다뤄요. 결제가 아니라 제품 이벤트에서 시작하는 플로우는 AI 이메일 자동화를 참고하세요.
| 목적 | 후보 이벤트 | 보내기 전 검토할 것 |
|---|---|---|
| 구독자 환영하기 | customer.subscription.created |
Checkout에서 나가는 웰컴 이메일과 중복되지 않게 하기 |
| 체험 종료 안내하기 | customer.subscription.trial_will_end |
실제 종료 시점과 요금이 청구되는지 여부 |
| 인보이스 결제 실패 알리기 | invoice.payment_failed |
현재 인보이스, 결제 링크, 이미 나가고 있는 Stripe 안내 |
| 요금제 변경 안내하기 | customer.subscription.updated |
어떤 필드가 바뀌었는지, 그 변경이 안내할 만한 것인지 |
| 해지 확인 안내하기 | customer.subscription.deleted |
이용이 끝나는 시점과 고객이 요청한 내용 |
| 환불 안내하기 | refund.created |
이벤트에 담긴 환불 관련 필드 |
Stripe 이벤트 레퍼런스와 선택한 Brew 트리거의 스키마를 참고하세요. 구독 업데이트에는 여러 종류의 변경이 담길 수 있어요. 데이터를 확인하지 않고 업데이트마다 요금제 변경 이메일을 보내지 마세요.
Brew의 ‘연동’ 페이지에서 Stripe를 승인하세요. Brew가 웹훅을 등록하고 지원되는 트리거를 프로비저닝해요. 이벤트별로 켜고 끄는 스위치는 없어요. 해당 이벤트에 연결된 활성 상태인 자동화만 실행돼요.
기존 연락처를 가져와야 한다면 ‘Stripe에서 고객 동기화’를 사용하세요. 결제 연락처를 가져왔다고 해서 마케팅 수신 동의가 성립하지는 않아요. 이벤트별 ‘전체 이름 동기화’ 설정은 이름 업데이트를 제어할 뿐, 이메일 발송 여부와는 관계가 없어요.
첫 자동화는 초안으로 만들고, 생성된 이메일을 살펴본 다음, 게시하기 전에 직접 관리하는 수신자로 테스트하세요. 연결에 관한 자세한 내용은 Stripe 설정 가이드를 따르세요. Brew는 라이브 Stripe 계정을 연결하며, 테스트 모드 이벤트로는 자동화가 시작되지 않아요.
즉시 보내는 결제 실패 안내는 invoice.payment_failed 이벤트에서 시작할 수 있어요. 무슨 일이 있었는지 설명하고, 자체 결제 페이지로 연결하세요. Brew가 결제를 재시도한다고 약속하지 마세요. 결제 처리는 Stripe가 담당해요.
3일 뒤에 리마인더를 보내려면 애플리케이션이 인보이스 상태를 확인하도록 예약하세요. 인보이스가 여전히 미결제이고 고객이 계속 대상에 해당하면 별도의 Brew 리마인더 이벤트를 보내세요. 결제가 정상화됐다면 이벤트를 보내지 않고 끝내세요.
대기 단계가 지난 뒤에도 이벤트 필드에는 원래 페이로드가 그대로 들어 있어요. contact.stripe_subscription_status 조건은 해당 노드가 실행되는 시점에 Brew 연락처 필드의 현재 값을 읽어요. Stripe를 조회하거나 바로 이 인보이스가 결제됐음을 증명하지는 않아요. 나중에 들어온 invoice.paid 이벤트가 이전 실행을 자동으로 취소하지도 않아요. 결제 수단을 업데이트했다고 해서 결제가 된 것도 아니에요.
리마인더 확인 전에 결제가 정상화되는 경우, 인보이스가 계속 미결제인 경우, 작업이 재시도되는 경우를 모두 테스트하세요. 같은 논리적 이벤트에는 문서에 나온 재시도 기간 안에서 같은 멱등성 키를 다시 쓰세요.
Brew는 구독 상태와 요금제를 포함한 결제 필드를 연락처에 동기화할 수 있어요. 이벤트 페이로드와 연락처 필드는 서로 다른 출처예요. amount, currency, invoiceNumber, previousPlan, newPlan, failureMessage 필드를 쓰기 전에 트리거 스키마를 읽어 보세요. 모든 이벤트가 모든 필드를 제공하지는 않아요.
Stripe 객체 ID는 자동화 페이로드에서 제외돼요. 인보이스 ID나 구독 ID를 짐작해 고객 포털 URL을 만들지 마세요. 로그인해야 볼 수 있는 애플리케이션의 결제 페이지나, 사용자 지정 이벤트에 의도적으로 담아 보낸 링크를 쓰세요. 개인화 태그 가이드를 따르세요.
Stripe의 고객 이메일 설정을 검토하세요. 영수증, 결제 실패 안내, 리마인더를 각각 어느 시스템이 보낼지 정하세요. Brew 자동화를 켠다고 Stripe 이메일이 꺼지지는 않아요.
메시지의 목적과 수신 동의 여부를 검토하지 않았다면 계정 안내 이메일에 프로모션 콘텐츠를 넣지 마세요. 마케팅 리마인더에는 그에 맞는 수신 동의와 수신 거부 처리가 필요해요.
이벤트가 Brew에 표시되는지, 연결된 자동화가 활성 상태인지, 실행 기록에 예상한 수신자와 결과가 나오는지 확인하세요. 그런 다음 받은 이메일과 결제 링크를 살펴보세요. 이벤트는 들어왔는데 메시지가 발송되지 않았다면, 웹훅이 실패했다고 단정하기 전에 필터, 발송 제외, 발신 도메인 준비 상태를 확인하세요.
이벤트 하나와 테스트를 마친 이메일 하나로 시작하세요. 이후 리마인더는 현재 상태 확인과 재시도 동작을 애플리케이션 테스트로 검증한 뒤에 추가하세요.
