자체 SaaS 4종을 운영하며 배운 결제 실패 대응 원칙 4가지
정기결제는 언젠가 반드시 실패해요. 카드 만료부터 한도 초과까지 원인이 제각각인데, 재시도는 아무 때나 한다고 되는 게 아니에요. 자체 SaaS 4종을 10년 이상 운영하며 세운 재시도·알림·환불·해지 처리 원칙 4가지를 정리했어요.
핵심 요약 — 정기결제는 아무리 잘 만들어도 언젠가 실패해요. 저희가 자체 SaaS 4종(D:VALUEUP·Likepro·Globing·Linkmix)을 10년 이상 운영하며 세운 원칙은 네 가지예요 — ① 실패 원인을 소프트·하드로 나누고 ② 재시도는 시간차를 두고 ③ 알림은 채널을 하나로 두지 않고 ④ 해지 후 데이터는 바로 지우지 않아요. 운영하며 겪은 그대로 풀어볼게요.
“결제가 왜 또 실패했지?” 구독형 서비스를 운영하다 보면 이 말을 입에 달고 살게 돼요. 저희도 자체 SaaS 4종을 함께 운영하면서 결제 실패를 완전히 없애는 건 불가능하다는 걸 먼저 인정했어요. 대신 실패했을 때 무엇을, 어떤 순서로 할지를 미리 정해두는 쪽으로 방향을 잡았고, 그 기준을 오늘 풀어볼게요.
1. 정기결제 시스템에서 실패는 왜 피할 수 없을까요
카드는 매달 만료되고, 한도는 매달 다시 채워지고, 은행 서버는 가끔 응답이 느려요. 이 세 가지만으로도 정기결제 실패는 매 결제 주기마다 일정 비율로 발생해요. 저희가 처음 잡은 기준은 “실패를 0으로 만들자”가 아니라 “실패한 결제를 얼마나 빨리, 얼마나 많이 되살리느냐”였어요. 목표를 이렇게 바꾸는 순간부터 재시도·알림·환불 절차를 설계하는 방향이 완전히 달라졌어요.
2. 소프트 실패와 하드 실패를 가르는 게 먼저예요
모든 결제 실패를 똑같이 다루면 안 돼요. 소프트 실패(한도 초과, 일시적인 네트워크 오류, 잔액 부족처럼 시간이 지나면 풀릴 수 있는 실패)는 재시도로 상당수 되살릴 수 있어요. 반면 하드 실패(카드 정지, 분실 신고, 계좌 해지처럼 영구적으로 막힌 실패)는 몇 번을 다시 시도해도 같은 응답만 돌아와요. 이 둘을 가리지 않고 재시도만 반복하면 서버 자원만 낭비하고, 사용자에게는 실패 메일만 반복해서 쌓여요. 저희는 오류 코드를 받는 순간 이 둘을 먼저 가르고, 하드 실패는 재시도 없이 곧바로 카드 변경 안내로 넘겨요.
3. 재시도는 아무 때나 하지 않아요 — 저희가 쓰는 타이밍
소프트 실패라고 바로, 계속 재시도하는 것도 답이 아니에요. 한도 초과는 카드사 결제일이 지나야 풀리고, 일시 오류는 몇 분만 지나도 풀리는 경우가 많아요. 그래서 저희는 재시도 시점에 간격을 둬요.
저희가 쓰는 재시도 타이밍(사내 운영 기준)
| 시점 | 노리는 것 |
|---|---|
| 즉시~수 시간 내 | 일시적인 네트워크 오류·순간 잔액 부족 복구 |
| 며칠 후 | 카드사 결제일이 지나 한도가 다시 열리는 시점 |
| 1～2주 후 | 여러 결제 주기를 넘겨 회복할 여지가 있는 마지막 시도 |
참고 — 해외 결제 업계에서 널리 쓰이는 재시도 리서치(외부 자료)
해외 결제 플랫폼 업계에서는 즉시·3일·7일·14일, 이렇게 네 번에 걸쳐 재시도하는 방식이 자주 소개돼요. 대부분의 복구가 14일 안에 일어나고, 그 뒤로 재시도를 더 늘려도 회수율은 크게 안 오르면서 사용자 피로만 커진다는 자료도 있어요. ⚠️ 이건 저희 실측이 아니라 업계에서 참고 삼아 도는 일반 리서치예요 — 서비스별 결제 주기·객단가에 따라 최적 타이밍은 달라질 수 있어요.
4. 갱신 실패 알림, 채널을 하나로 두지 않아요
이메일 한 통만 보내고 끝내면 사용자가 못 보고 지나가는 경우가 많아요. 저희는 이메일에 더해 앱 내 배너, 필요하면 문자까지 함께 써요. 채널을 하나 더 얹을 때마다 회수율이 눈에 띄게 올라간다는 게 해외 결제 리서치에서도 공통으로 나오는 이야기예요. 다만 채널을 늘릴수록 문구가 반복돼 사용자가 피곤해질 수 있어서, 저희는 채널마다 안내 강도를 다르게 둬요 — 앱 배너는 가볍게, 마지막 문자 안내는 “이번이 마지막 시도”라고 명확하게요.
5. 환불 처리는 왜 유지보수보다 더 조심스러울까요
환불은 버그 수정과 성격이 달라요. 버그는 고치면 끝이지만, 환불은 돈이 실제로 오가고 되돌리기 어려워요. 저희는 자동 환불 대상(예: 결제 직후 짧은 시간 내 취소)과 사람이 한 번 더 확인해야 하는 대상(예: 장기간 사용 후 환불 요청)을 나눠서 처리해요. 이 구분을 안 해두면 자동화 속도만 믿고 처리했다가 나중에 분쟁으로 되돌아오는 경우를 저희도 겪었어요. 장애가 실제로 사용자에게 영향을 준 경우의 우선순위 판단은 저희가 SaaS 4종 운영하며 배운 장애 대응 3원칙에서 다룬 기준과도 이어져요.
6. 구독 해지 시 데이터를 어떻게 처리할까요
해지를 누르는 순간 데이터를 전부 지우면 편해 보이지만, 착오로 해지한 사용자를 구할 방법이 없어져요. 저희는 해지 후에도 일정 보관 기간을 두고, 그 기간이 지나면 규정에 따라 삭제해요. 보관 기간과 삭제 범위는 서비스 시작 전에 사용자에게 미리 안내돼야 하고, 개인정보를 다루는 부분이라 저희는 고객 데이터 품질·개인정보 원칙에서 정리한 기준을 그대로 가져와요.
결제 흐름과 데이터 처리 기준을 처음부터 함께 설계하고 싶다면 결제 흐름부터 함께 점검해요 →
저희는 10년 넘게 자체 SaaS 4종을 직접 운영하면서 이런 판단을 실제 사용자를 앞에 두고 계속 조정해왔어요. 롯데·캐논 같은 곳과 진행한 프로젝트에서도 데이터와 돈이 오가는 부분은 항상 계약 전에 범위를 좁혀두는 쪽이 더 안전했고요.
7. 자주 묻는 질문
정기결제 실패는 어느 정도 발생하나요?
정확한 비율은 서비스마다 다르지만, 카드 만료·한도 초과·일시적인 네트워크 오류가 섞여서 매 결제 주기마다 일정 비율은 항상 발생해요. 저희는 ‘0으로 만드는 것’을 목표로 잡지 않고, ‘실패한 건을 얼마나 빨리 되살리는가’를 목표로 잡아요.
결제 실패 시 바로 재시도해도 되나요?
실패 원인에 따라 달라요. 한도 초과나 일시 오류처럼 시간이 지나면 풀리는 소프트 실패는 재시도가 맞지만, 카드 정지나 분실처럼 영구적인 하드 실패는 재시도해도 같은 결과가 반복돼요. 원인을 가리지 않고 재시도만 반복하면 헛수고가 쌓여요.
구독을 해지하면 데이터는 바로 삭제되나요?
저희는 해지 즉시 삭제 대신, 정해둔 보관 기간을 먼저 둬요. 사용자가 착오로 해지했을 때 복구할 여지를 남기면서도, 보관 기간이 지나면 규정에 따라 삭제해요. 서비스마다 보관 기간과 삭제 범위는 사전에 사용자에게 안내돼야 해요.
개발 외주로 결제 시스템을 맡길 때 이 원칙을 반영할 수 있나요?
네. 재시도 로직·실패 알림 채널·환불 승인 절차·해지 후 데이터 처리 기준을 요구사항 정의 단계에서 미리 정해두면, 나중에 결제 실패가 쌓였을 때 개발사와 발주사가 우왕좌왕하는 일이 줄어요.
8. 마무리
결제 실패는 버그가 아니라 구독형 서비스의 일상이에요. 저희가 배운 건 실패를 막으려고 애쓰기보다, 실패했을 때 소프트·하드를 가르고, 시간차를 두고 다시 시도하고, 여러 채널로 알리고, 해지 후 데이터를 바로 지우지 않는 것 — 이 네 가지 순서를 미리 정해두는 쪽이 훨씬 덜 힘들다는 거예요.
관련해서 함께 보면 좋은 글이에요.