Stripe의 Payment Retries는 무딘 도구다 (그리고 수천 달러를 잃게 합니다)
Source: Dev.to
위에 제공된 소스 링크 외에 번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.
Stripe의 기본 재시도 로직 문제
결제가 실패합니다. Stripe가 재시도합니다. 문제 해결, 맞죠?
전혀 그렇지 않습니다.
무슨 일이 일어나고 있는지 깨닫기 전에 $4,200의 월 매출이 사라지는 것을 지켜봤습니다. Stripe의 내장 재시도 로직은 설계대로 정확히 작동하고 있었고—그게 바로 문제였습니다.
Stripe는 “도난 카드” 거절을 “잔액 부족” 거절과 동일하게 취급합니다: 같은 재시도 타이밍, 같은 접근 방식. 지능이 전혀 없습니다.
- 도난당한 카드는 24시간 안에 마법처럼 사용 가능해지지 않습니다.
- 급여 사이에 있는 고객은 며칠 후에 자금이 들어올 수 있습니다.
Stripe의 재시도 로직은 차이를 알지 못합니다. 그냥… 다시 시도할 뿐입니다.
Data snapshot (last month)
| Outcome | Count | Rate |
|---|---|---|
| 실패한 결제 | 127 | 100% |
| 성공적으로 회수된 건 | 31 | 24% |
| 조용히 이탈한 고객 | 96 | 76% |
우리의 $47/month 가격대에서, 이는 $4,512/month가 문을 나서는 것과 같습니다—고객이 떠나고 싶어서가 아니라, 부적절한 시점에 강경한 재시도가 작용했기 때문입니다.
스마트 회수에 대한 업계 벤치마크는 40–60% 수준입니다. 우리는 잠재 회수의 절반을 놓치고 있었습니다.
모든 결제 실패가 동일한 것은 아니다
| 거절 사유 | Stripe 코드 |
|---|---|
| 잔액 부족 | insufficient_funds |
| 카드 만료 | expired_card |
| 도난 또는 분실 카드 | stolen_or_lost_card |
| 일반 거절 | generic_decline |
Stripe의 기본 로직은 이들을 대략 동일하게 처리합니다.
Source: …
무엇이 변화를 만들었는가
1. Stripe의 기본 동작을 신뢰하지 않기
구독 결제에 대해 Stripe Smart Retries를 끄세요. 거절 코드에 따라 의도적으로 재시도 로직을 설계하면 더 나은 결과를 얻을 수 있습니다.
2. 재시도 시점을 급여일에 맞추기
insufficient_funds(잔액 부족) 거절에 대해 최적의 재시도 창은 다음과 같습니다:
- 월 1일 또는 15일 (급여일)
- 최초 실패 후 48~72시간
- 주말은 절대 피하기 (은행 처리 속도가 느림)
우리는 재시도 시점을 1일과 15일로 맞추는 것만으로 회복율이 34% 상승하는 것을 확인했습니다.
3. 재시도 전에 이메일 보내기
expired_card(만료된 카드) 거절에 대해서는 재시도를 전혀 하지 말고, 사람처럼 보이는 간단한 텍스트 이메일을 보내세요:
Hey [name],
Your card on file expired. Takes 30 seconds to update: [link]
— [Founder name]HTML이나 마케팅 템플릿을 사용하지 마세요. 이 이메일은 **68%**의 전환율을 기록했습니다.
4. 언제 멈춰야 할지 알기
카드가 업데이트되지 않은 상태에서 세 번 재시도에 실패하면, 청구를 중단하고 복귀 유도 시퀀스를 시작하세요. 더 많은 시도는 이미 마음을 떠난 고객을 더욱 짜증나게 할 뿐입니다.
내 생각을 바꾼 수학
- 평균 SaaS는 **9 %**의 MRR을 비자발적 이탈(결제 실패)로 잃는다.
- 스마트 복구 도구는 그 손실의 **40–60 %**를 회복한다.
- Stripe의 기본 복구율은 아마 20–25 % 정도이다.
이는 20–35 포인트 차이이다. $50 K MRR 기준으로 $900–$1,575/월을 회복하지 못한다. 1년이면 $10,800–$18,900이다.
신규 SaaS 창업자를 위한 행동 계획
| Timeline | Steps |
|---|---|
| Day 1 | 구독에 대한 Stripe Smart Retries를 끄세요. |
| Week 1 | 실패한 결제 모두에 대한 이메일 알림을 설정하세요 (해지 시점에만이 아니라). |
| Week 2 | 거절 코드 인식을 포함한 재시도 로직을 직접 구축하거나 구매하세요 (웹훅과 약간의 코드를 사용). |
| Week 3 | 인간적인 느낌의 복구 이메일 3개를 작성하세요. |
| Month 2 | 데이터를 검토하고 재시도 타이밍을 최적화하세요. |
웹훅을 사용해 수동으로 구현하거나 목적에 맞는 도구를 사용할 수 있습니다—어느 쪽이든 Stripe 기본값에 의존하지 마세요.
Conclusion
Stripe는 결제 처리에 뛰어나지만, 그 인센티브는 돈을 이동시키는 것이지 회수율을 극대화하는 것이 아닙니다. 만약 **9 %**의 MRR을 실패한 결제로 잃고 그 중 사분의 일만 회수한다면, 상당한 금액을 놓치고 있는 것입니다. 해결책은 복잡하지 않으며—단지 의도적인 접근입니다.
Revive에서 이탈 복구를 구축하고 있습니다. Revive는 수익 공유 도구에 대한 고정 수수료 대안입니다. 회수된 수익의 25 %를 다른 사람에게 지불하는 것이 지긋지긋하다면 revive‑hq.com에서 확인해 보세요.