B2B SaaS 결제 공급사 failover·multi-gateway 준비 체크리스트 2026
B2B SaaS 결제 공급사 failover·multi-gateway 준비 체크리스트 2026
B2B SaaS 결제에서 두 번째 gateway를 연결하면 첫 번째 공급사 장애 때 자동으로 우회할 수 있을 것처럼 보입니다. 그러나 실제 준비 범위는 API 연결 두 개보다 훨씬 넓습니다. 저장된 결제수단을 대체 경로에서 사용할 수 있는지, 진행 중인 구독과 invoice의 기준 상태를 어느 시스템이 소유하는지, timeout 뒤 같은 청구를 다시 보내도 중복 실행되지 않는지, 두 gateway의 거래를 같은 장부에서 대사할 수 있는지를 함께 확인해야 합니다.
이 글은 장애가 발생한 뒤 queue와 webhook을 복구하는 절차가 아닙니다. 사고 후 대응은 B2B SaaS 결제 공급사 장애 대응 체크리스트에서 다룹니다. 여기서는 장애가 나기 전에 failover와 multi-gateway가 실제로 작동할 조건을 설계하고 시험하는 방법에 집중합니다.
플랫폼 선택 단계라면 B2B SaaS 구독 관리 플랫폼 비교에서 Stripe Billing·Chargebee·Paddle·Recurly의 역할 차이를 먼저 확인할 수 있습니다. 이미 플랫폼 이전을 계획하고 있다면 B2B SaaS 구독 청구 플랫폼 이전 체크리스트의 mapping·dry run·cutover 기준을 함께 적용해야 합니다.
이 문서는 결제 운영과 시스템 통제를 위한 일반 체크리스트입니다. 특정 공급사의 가용성, 승인율 향상, 무중단 전환을 보장하지 않으며 법률·세무·회계 또는 PCI 준수 판단을 대신하지 않습니다. 지원 gateway, 결제수단, token 이전, routing 기능은 계정·지역·계약·processor 조합에 따라 달라질 수 있으므로 2026년 7월 30일 확인한 공식 문서와 실제 계약·테스트 환경을 함께 검증해야 합니다.
먼저 결론: 두 번째 gateway보다 일곱 개의 연결 고리를 먼저 확인합니다
failover 준비는 다음 순서로 진행하는 편이 안전합니다.
[현재 결제 아키텍처와 의존성 지도]
↓
[결제수단·token·데이터 이식성 확인]
↓
[subscription·invoice 기준 상태 확정]
↓
[routing·failover 규칙과 중단 조건]
↓
[webhook·idempotency·중복 방지]
↓
[거래·수수료·payout 대사 설계]
↓
[소규모 리허설·rollback·승인]
이 순서를 건너뛰고 routing만 켜면 다음과 같은 문제가 생길 수 있습니다.
- 주 gateway에 저장된 결제수단을 대체 gateway에서 사용할 수 없어 우회가 시작되지 않습니다.
- 첫 요청이 실제 승인됐는지 모르는 상태에서 두 번째 gateway에 다시 보내 중복 청구가 발생합니다.
- billing platform과 gateway가 서로 다른 subscription·invoice 상태를 기준값으로 사용합니다.
- 우회 거래는 성공했지만 환불, dispute, fee, payout을 원거래와 연결하지 못합니다.
- 장애가 끝난 뒤 어느 시점에 주 경로로 되돌릴지 판단하지 못해 거래가 계속 갈라집니다.
따라서 gateway B 연결 완료가 아니라 고객군별로 결제수단 사용 가능성, 상태 전이, 중복 방지, 대사와 복귀까지 재현 가능함을 준비 완료 기준으로 삼아야 합니다.
1단계: 현재 결제 아키텍처와 단일 장애 지점을 그립니다
먼저 고객이 결제 버튼을 누른 뒤 지급 내역이 은행과 내부 장부에 반영될 때까지의 경로를 한 장에 그립니다. billing platform, payment gateway, processor, 저장 결제수단, 3DS나 추가 인증, webhook, 내부 주문·권한 시스템, ERP, payout을 별도 구성요소로 표시합니다.
[Checkout / Invoice]
↓
[Billing platform 또는 내부 billing service]
↓
[Routing layer]
├────────> [Gateway A / Processor A]
└────────> [Gateway B / Processor B]
↓
[Webhook inbox + action ledger]
↓
[Subscription / Entitlement / CRM / ERP]
↓
[Balance / Payout / Bank]
그림에는 제품 이름만 쓰지 말고 각 연결의 책임과 식별자를 붙입니다.
| 연결 구간 | 확인할 owner | 반드시 보존할 키 |
|---|---|---|
| checkout → billing | 제품 또는 billing 팀 | checkout ID, customer ID, cart·contract version |
| billing → routing | 결제 플랫폼 또는 내부 서비스 | payment intent ID, invoice ID, route decision ID |
| routing → gateway | 결제 운영 팀 | gateway account, request ID, idempotency key |
| gateway → webhook | 플랫폼·개발 팀 | provider event ID, object ID, signature result |
| payment → subscription | billing·제품 팀 | payment ID, subscription ID, state version |
| subscription → entitlement | 제품 운영 팀 | account ID, entitlement action ID |
| gateway → payout | 재무 운영 팀 | transaction ID, balance record, payout ID |
단일 장애 지점도 표시합니다. gateway를 두 개 쓰더라도 routing service, token vault, DNS, credential store, webhook endpoint, database 또는 수동 승인 담당자가 하나뿐이면 전체 흐름은 여전히 한 지점에서 멈출 수 있습니다.
다음 질문에 답하지 못하면 아직 route 설계를 시작할 단계가 아닙니다.
- 결제 요청을 생성하는 기준 시스템은 어디인가.
- 고객 결제수단은 누가 보관하고 어떤 형태의 참조값으로 연결되는가.
- gateway별 merchant account, 통화, 지역, 결제수단 범위는 무엇인가.
- invoice와 subscription의 최종 상태를 누가 확정하는가.
- webhook이 지연돼도 현재 상태를 다시 조회할 경로가 있는가.
- 거래 성공부터 refund·dispute·payout까지 같은 원거래를 추적할 수 있는가.
- routing layer 자체가 실패하면 사용할 정해진 안전 상태가 있는가.
2단계: token portability를 결제수단별로 확인합니다
multi-gateway 설계에서 가장 자주 놓치는 전제는 customer_id나 payment_method_id가 모든 공급사에서 통용되지 않는다는 점입니다. gateway 내부 token, processor token, network token, raw card data는 같은 것이 아닙니다. 한 시스템의 참조 ID를 다른 gateway API에 그대로 전달할 수 있다고 가정하면 안 됩니다.
Stripe의 PAN 데이터 가져오기 공식 문서는 카드 데이터 이전이 일반 CSV 업로드가 아니라 별도 지원 절차와 기술적 조건을 확인해야 하는 작업임을 보여주는 출발점입니다. 이 문서를 특정 source·destination·지역에서 항상 이전할 수 있다는 보장으로 읽어서는 안 됩니다. 실제 프로젝트에서는 source와 destination 양쪽에 지원 범위, 데이터 형식, 식별자 mapping, 일정과 실패 처리 방식을 확인해야 합니다.
Recurly gateway token 지원 문서는 gateway별 token 지원을 확인할 수 있는 공식 기준입니다. 표에 gateway가 있다는 사실만으로 현재 사용하는 모든 결제수단과 기존 token이 그대로 호환된다는 뜻은 아닙니다. site 설정, gateway 조합, token type과 이전 절차를 실제 계정 기준으로 확인해야 합니다.
결제수단 inventory는 다음처럼 분리합니다.
| 결제수단 cohort | 현재 저장 위치 | 대체 경로 사용 가능성 | 검증 방법 | 실패 시 대안 |
|---|---|---|---|---|
| 저장 카드 | gateway vault 또는 별도 vault | token 유형과 계약에 따라 다름 | 공급사 확인 + 허용된 테스트 | 고객 재등록, 기존 경로 유지 |
| 은행 자동이체 | gateway·지역별 mandate와 연결 | 지역·scheme별 제약 가능 | mandate와 customer 참조 확인 | cohort 제외, 별도 안내 |
| wallet | provider·device·domain 설정과 연결 | 동일 credential 재사용 불가 가능 | 실제 checkout 경로 시험 | 주 경로 유지 |
| invoice/manual payment | 자동 gateway 우회 대상이 아닐 수 있음 | 수금 절차에 따라 다름 | invoice와 입금 경로 확인 | 수동 queue 분리 |
| 신규 고객 결제수단 | 아직 기존 token 없음 | 대체 checkout을 설계하기 쉬움 | 소규모 신규 cohort 시험 | 주 경로 복귀 |
inventory에는 최소 다음 필드를 둡니다.
customer_id
subscription_id
payment_method_type
vault_owner
gateway_token_reference
processor_or_gateway
country
currency
authentication_or_mandate_state
portability_status
portability_evidence
fallback_eligible
last_verified_at
portability_status는 yes/no 두 값으로 끝내지 않습니다. confirmed, requires_vendor_assistance, customer_action_required, unsupported, unknown처럼 증거 수준을 구분합니다. 특히 unknown을 자동 우회 대상으로 포함하면 장애 중에 처음 보는 실패가 대량으로 발생할 수 있습니다.
데이터 이식과 실시간 failover를 구분합니다
token을 지원 절차로 다른 공급사에 이전할 수 있다는 사실과 한 요청을 실시간으로 두 gateway 사이에서 전환할 수 있다는 사실은 다릅니다.
- migration은 일정, batch, mapping, 검증과 고객군 전환이 있는 프로젝트입니다.
- failover는 이미 준비된 대체 경로로 제한된 조건에서 요청을 전환하는 운영입니다.
- re-entry는 장애가 끝난 뒤 주 경로로 안전하게 복귀하는 별도 전환입니다.
따라서 token 이전 프로젝트가 끝나지 않은 cohort를 failover 대상처럼 표시하지 않습니다. 이전 자체의 mapping·dual run·rollback은 구독 청구 플랫폼 이전 체크리스트에서 더 자세히 확인할 수 있습니다.
gateway가 둘이면 결제 상태도 둘로 늘어나지만, 고객의 subscription과 entitlement 기준 상태까지 둘이 되어서는 안 됩니다. 어느 시스템이 invoice를 생성하고, 결제 결과를 확정하고, subscription 기간과 접근 권한 변경을 승인하는지 명시해야 합니다.
권장 구조는 gateway별 원문 상태를 보존하되 내부 기준 상태를 별도 state machine에서 결정하는 것입니다.
| 상태 층 | 예시 | 역할 |
|---|---|---|
| gateway 원문 | authorized, succeeded, failed, refunded | 공급사 객체 상태를 변형 없이 보존 |
| billing 원문 | invoice open·paid, subscription active·past due | 청구 플랫폼의 현재 상태 보존 |
| 내부 결제 상태 | pending_verify, paid, failed_final, refunded | 여러 공급사 결과를 한 업무 상태로 통합 |
| workflow 상태 | route_selected, failover_blocked, reconciled | 운영 처리 단계 표현 |
| entitlement 상태 | active, grace, restricted, ended | 제품 접근 정책을 결제와 분리 |
기준 상태를 만들 때는 다음 원칙을 적용합니다.
- timeout과 명시적인 실패를 같은 상태로 저장하지 않습니다.
- gateway A 응답이 불명확하면 gateway B로 보내기 전에 A의 현재 객체를 재조회합니다.
- webhook 도착 하나만으로 invoice, subscription, entitlement를 모두 덮어쓰지 않습니다.
- gateway별 transaction ID와 내부 payment action ID를 함께 보존합니다.
- 결제 성공과 대사 완료를 다른 상태로 관리합니다.
- 수동 조정에는 actor, reason, before/after, 승인 근거를 남깁니다.
예를 들어 주 gateway가 timeout을 반환하면 내부 상태를 즉시 failed로 바꾸지 않고 pending_verify로 둡니다. 공급사 조회에서 거래 미생성과 재시도 가능성이 확인돼야 다음 route를 선택합니다. 이미 승인된 거래가 확인되면 대체 gateway 요청을 막고 그 거래를 기준 상태에 반영합니다.
Paddle의 Merchant of Record 구조는 같은 표에 억지로 넣지 않습니다
Paddle의 Merchant of Record 공식 설명처럼 Paddle 같은 Merchant of Record 모델은 외부 gateway 하나를 단순히 교체하거나 사용자가 임의로 두 processor 사이를 routing하는 구조와 같지 않습니다. 판매자 역할, checkout, 고객 문서, 결제 처리와 지급 경계가 함께 연결될 수 있으므로 일반 gateway failover 표의 한 열처럼 취급하면 역할을 오해하기 쉽습니다. MoR을 포함한 구조 비교는 구독 관리 플랫폼 비교에서 별도 기준으로 검토하고, 이번 체크리스트의 자동 전환 범위에는 계약상 통제할 수 있는 경로만 포함합니다.
4단계: routing과 failover 규칙을 분리해 설계합니다
routing은 평상시 어떤 거래를 어느 경로로 보낼지 결정하는 규칙이고, failover는 특정 오류나 장애 조건에서 대체 경로로 전환하는 규칙입니다. 둘을 하나의 if error then gateway B로 합치면 승인 거절, 시스템 장애, 인증 필요, 설정 오류를 모두 같은 방식으로 재시도할 수 있습니다.
Chargebee payment gateways 공식 페이지는 Chargebee에서 연결 가능한 payment gateway 구성을 검토하는 공식 출발점입니다. 다만 목록에 gateway가 존재한다고 해서 현재 제품·site·지역·플랜에서 모든 결제수단과 자동 failover가 제공된다는 뜻은 아닙니다. 실제 설정과 지원 범위를 계정별로 확인해야 합니다.
Recurly custom gateway routing 공식 문서는 gateway routing 설정을 검토할 기준을 제공합니다. Recurly gateway failover 공식 문서는 failover 기능의 현재 동작과 전제 조건을 확인할 자료입니다. 문서에 기능이 있어도 현재 site, gateway, payment method와 계약에 적용되는지는 별도 검증이 필요합니다.
routing decision에는 최소 다음 증거를 남깁니다.
route_decision_id
internal_payment_action_id
customer_cohort
payment_method_type
country
currency
amount_band
selected_gateway
rule_id
rule_version
decision_reason
health_signal_version
decided_at
오류를 네 가지로 나눕니다
| 오류 유형 | 예시 | 자동 failover 기본값 |
|---|---|---|
| 명시적 고객·발급사 거절 | 잔액 부족, 카드 제한, 인증 필요 | 무조건 우회하지 않음 |
| 불명확한 처리 결과 | timeout, 연결 종료, 5xx 뒤 결과 미확정 | 원문 상태 확인 전 우회 금지 |
| 명확한 사전 실패 | 요청이 gateway에 도달하지 않았다는 근거가 있음 | 승인된 규칙과 멱등성 확인 후 검토 |
| 구성·데이터 오류 | 잘못된 currency, token 미지원, credential 오류 | 우회보다 설정 수정·cohort 격리 |
거절된 카드를 다른 gateway로 무조건 다시 보내는 규칙은 고객 경험과 중복 처리 위험을 높일 수 있습니다. failover는 승인율을 보장하는 기능이 아니라 정해진 기술적 실패에서 이미 검증된 대체 경로를 선택하는 통제로 정의하는 편이 안전합니다.
health signal도 단일 지표에 의존하지 않습니다
전환 조건은 status page 하나나 5xx 한 건으로 만들지 않습니다. route별 latency, timeout, 오류 코드, webhook 지연, provider object 조회 성공률, 내부 queue backlog를 함께 봅니다.
| signal | 경고 질문 | 전환 전 확인 |
|---|---|---|
| API error rate | 특정 endpoint·지역·결제수단 문제인가 | 읽기와 쓰기 영향 범위 분리 |
| latency·timeout | 실제 미처리인가 결과만 못 받은 것인가 | provider object 재조회 가능성 |
| webhook lag | 공급사 전송 지연인가 내부 worker 지연인가 | ingress·queue·consumer 구간 분리 |
| token error | 일부 cohort의 portability 문제인가 | 해당 cohort만 routing 제외 |
| internal dependency | routing service·DB·vault 장애인가 | gateway 전환으로 해결되는지 |
전환 규칙에는 threshold뿐 아니라 최소 관찰 구간, 승인자, 최대 전환 cohort, 자동 중지 조건, 원복 전 안정 구간을 함께 둡니다.
5단계: webhook과 idempotency를 gateway별·업무별로 설계합니다
Stripe webhook 공식 문서는 endpoint 구성, 서명 검증, 이벤트 처리와 재전송을 확인할 공식 자료입니다. webhook은 중요한 알림 경로지만 이벤트가 도착했다는 사실이 내부 업무 완료나 최종 금액 일치를 뜻하지는 않습니다.
multi-gateway 환경에서는 provider event ID만으로 중복을 막으면 부족합니다. gateway A와 B가 서로 다른 event ID를 만들면서 같은 내부 결제 업무를 나타낼 수 있기 때문입니다.
webhook inbox와 action ledger를 나눕니다.
webhook_inbox
- provider
- provider_event_id
- provider_object_id
- event_type
- provider_created_at
- received_at
- signature_verified
- payload_checksum
- processing_status
- related_internal_action_id
payment_action_ledger
- internal_payment_action_id
- customer_id
- invoice_id
- requested_amount
- currency
- route_decision_id
- gateway_attempts
- business_idempotency_key
- authoritative_status
- verified_at
- reconciliation_status
Stripe idempotent requests 공식 문서는 Stripe API 요청의 멱등 처리 방식을 확인하는 출발점입니다. 공급사가 idempotency key를 지원하더라도 내부 업무 키가 없으면 사람이 누른 재처리, queue 재실행, 다른 gateway 요청을 하나의 결제 의도로 묶기 어렵습니다.
업무 키는 timestamp나 worker 실행 번호보다 고객의 결제 의미를 반영해야 합니다. 예를 들어 정기 invoice 수금이라면 account + invoice + collection_version + amount + currency처럼 동일한 수금 결정을 식별할 수 있어야 합니다. gateway마다 다른 API key를 쓰더라도 같은 내부 action에 연결합니다.
대체 gateway 요청 전 guard를 둡니다
대체 경로 요청 직전에는 최소 다음 조건을 다시 확인합니다.
- 같은 내부 action이 이미
paid,authorized,refund_pending상태가 아닌가. - 주 gateway의 transaction 또는 payment 객체를 현재 시점에 조회했는가.
- 기존 요청이 명시적으로 미생성 또는 재시도 가능한 상태임을 확인했는가.
- 결제수단과 인증 상태가 대체 gateway에서 사용 가능한가.
- 요청 금액, 통화, invoice, customer가 원래 action과 같은가.
- 대체 gateway용 idempotency key와 route decision이 기록됐는가.
- 성공 뒤 어느 webhook과 조회 결과로 기준 상태를 확정할지 정했는가.
이 guard를 통과하지 못하면 자동 전환보다 manual_verify queue로 보내는 편이 안전합니다.
정상적인 결제 실패와 dunning은 공급사 장애 failover와 다른 흐름입니다. 발급사 거절이나 고객 결제수단 문제는 B2B SaaS 결제 실패·dunning 자동화 체크리스트에서 재시도, 고객 안내, CRM 상태를 별도로 설계해야 합니다.
6단계: 두 gateway의 거래를 하나의 reconciliation ledger로 연결합니다
failover 성공률만 보면 운영이 정상처럼 보일 수 있습니다. 하지만 gateway별 fee, refund, dispute, balance, payout이 서로 다른 시점과 ID로 기록되면 월말에 순액을 설명하지 못할 수 있습니다.
대사 ledger에는 주 경로와 대체 경로를 같은 업무 키로 연결합니다.
internal_payment_action_id
route_decision_id
gateway
gateway_account
gateway_transaction_id
invoice_id
customer_id
amount
currency
provider_status
fee_amount
refund_id
dispute_id
balance_reference
payout_id
erp_reference
bank_reference
match_status
exception_code
대사는 다음 세 층으로 나눕니다.
| 대사 층 | 비교 대상 | 대표 예외 |
|---|---|---|
| 업무 대사 | invoice ↔ 내부 action ↔ gateway transaction | 같은 invoice의 이중 승인, 거래 미연결 |
| 상태 대사 | payment ↔ subscription ↔ entitlement | 결제 성공 후 권한 미반영 |
| 금액 대사 | transaction ↔ fee·refund·dispute ↔ payout·bank | route별 fee 누락, 다른 payout에 반영 |
control total도 gateway별·통화별·route별로 계산합니다.
- 요청 건수와 고유 내부 action 수
- gateway별 attempt·승인·실패·미확정 건수
- 같은 action에 연결된 gateway transaction 수
- 승인 금액, refund 금액, dispute 금액, fee와 net
- payout에 연결되지 않은 balance record 수
- entitlement와 결제 기준 상태가 다른 계정 수
월말 대사의 ID 연결, cutoff, 예외 queue와 sign-off는 B2B SaaS 구독 청구 월말 대사 체크리스트를 적용합니다. failover 리허설도 대사할 수 없다면 실제 장애에서 사용할 준비가 끝난 것이 아닙니다.
7단계: 리허설은 신규 저위험 cohort부터 단계적으로 진행합니다
리허설의 목표는 dashboard에서 gateway B가 초록색으로 보이는지 확인하는 것이 아닙니다. 실제 운영 흐름에서 route 선택, 결제 결과, webhook, subscription, entitlement, refund와 대사가 모두 이어지는지 증명하는 것입니다.
권장 순서는 다음과 같습니다.
- 허용된 테스트 환경에서 성공·거절·timeout·중복 요청 시나리오를 검증합니다.
- token portability가 이미 확인된 결제수단만 대상으로 잡습니다.
- 신규 저위험 고객처럼 이전 거래 의존성이 낮은 작은 cohort를 선택합니다.
- route decision과 내부 action ID가 모든 로그·ledger에 남는지 확인합니다.
- 결제 성공 뒤 invoice·subscription·entitlement가 한 번만 갱신되는지 확인합니다.
- 환불을 실행할 수 있는 승인된 테스트 범위에서 원거래 연결을 검증합니다.
- gateway별 거래가 payout·대사 ledger에 들어오는지 확인합니다.
- 중단 조건이나 예외가 나오면 cohort 확대를 멈추고 원인을 닫습니다.
- 정해진 안정 구간을 확인한 뒤에만 다음 cohort로 확대합니다.
최소 시나리오 표는 다음처럼 준비할 수 있습니다.
| 시나리오 | 기대 결과 | 반드시 남길 증거 |
|---|---|---|
| gateway A 정상 | A 경로 한 번 실행 | route ID, transaction ID, webhook, 대사 |
| A 요청 전 명확한 실패 | 승인 조건일 때만 B 선택 | failure evidence, B route decision |
| A timeout·결과 미확정 | A 조회 전 B 금지 | pending_verify 상태, 조회 결과 |
| A 실제 성공 뒤 늦은 응답 | B 요청 없음 | A 원문 성공, 단일 내부 action |
| webhook 중복·순서 역전 | 업무 한 번 실행 | event inbox, state version, skip 근거 |
| B token 미지원 | cohort 자동 격리 | portability status, manual queue |
| B 성공·A 복구 | 즉시 왕복하지 않고 복귀 규칙 적용 | 안정 구간, 승인, re-entry route |
| refund·dispute 발생 | 원 gateway 원거래에 연결 | refund/dispute ID, 대사 상태 |
부정사용 신호와 결제 경로를 함께 검토해야 한다면 B2B SaaS 결제 부정사용 방지 도구 비교를 연결할 수 있습니다. 다만 fraud 판단과 gateway 장애 판단을 같은 오류 코드로 합치면 정상적인 위험 통제가 장애처럼 보일 수 있으므로 사유를 분리합니다.
8단계: rollback과 주 경로 복귀를 서로 다른 절차로 만듭니다
rollback은 대체 경로를 끄는 버튼이 아닙니다. 이미 gateway B에서 생성된 승인, refund, dispute, payout은 그대로 존재할 수 있습니다. 주 경로로 돌아간다고 외부 거래가 사라지지 않으므로 어느 action까지 실행됐는지 먼저 확정해야 합니다.
단계를 세 구간으로 나눕니다.
| 구간 | 가능한 조치 | 주의할 점 |
|---|---|---|
| 외부 요청 전 | route rule 원복, cohort 제외 | queue의 기존 route decision 확인 |
| 요청 후 결과 미확정 | 신규 전환 중지, 객체 재조회 | 다른 gateway로 즉시 재전송 금지 |
| 승인·환불 등 외부 action 후 | forward fix와 대사 | 거래 삭제 가정 금지, 고객 영향 확인 |
rollback runbook에는 다음 항목이 필요합니다.
- 전환 중지 명령과 실행 owner
- 신규 route decision을 막는 방법
- 처리 중 queue와 미확정 action을 보존하는 방법
- gateway별 transaction 재조회 순서
- webhook consumer와 replay 범위
- subscription·entitlement 기준 상태 복구 방법
- 환불·dispute를 원거래에 연결하는 절차
- 고객 안내가 필요한 조건과 승인자
- 대사 완료와 종료 sign-off 기준
주 경로 복귀는 장애 해제 알림 하나만 보고 실행하지 않습니다. 오류율과 latency가 안정됐는지, provider object 조회와 webhook이 정상인지, 내부 backlog가 통제됐는지 확인합니다. 일부 cohort로 복귀한 뒤 이중 승인, 미확정 action, 상태 불일치와 payout 대사를 보고 단계적으로 확대합니다.
사고가 실제로 발생했다면 결제 공급사 장애 대응 체크리스트의 retry 제한, webhook 복구, canary replay와 최종 상태 대사를 적용합니다.
공급사에 확인할 질문 15개
기능 이름보다 실제 계정에 적용되는 범위를 확인하기 위해 다음 질문을 서면으로 정리합니다.
- 현재 merchant account에서 연결할 수 있는 gateway와 processor 조합은 무엇인가.
- 국가·통화·결제수단별 지원 범위와 제외 조건은 무엇인가.
- 기존 card·bank·wallet 참조값은 어느 유형이며 다른 경로에서 사용할 수 있는가.
- token 또는 결제 데이터 이전은 self-service, API, 지원 요청 중 어떤 절차인가.
- 이전할 수 없는 결제수단과 고객 재인증·재등록이 필요한 cohort는 무엇인가.
- routing rule의 우선순위와 변경 반영 방식은 무엇인가.
- failover를 촉발하는 오류와 촉발하지 않는 거절은 어떻게 구분되는가.
- 결과가 불명확한 timeout에서 중복 실행을 막는 권장 조회 절차는 무엇인가.
- gateway별 idempotency 지원과 key 적용 범위는 무엇인가.
- gateway 변경 뒤 webhook event와 객체 ID를 어떻게 연결하는가.
- 환불·void·dispute는 반드시 원거래 gateway에서 처리해야 하는가.
- fee, balance, payout export에서 route와 원거래를 식별할 필드는 무엇인가.
- sandbox 또는 허용된 시험 환경에서 어떤 실패 시나리오를 재현할 수 있는가.
- 기능이 계정·site·플랜·계약에 따라 달라지는 지점은 무엇인가.
- 장애 후 주 경로 복귀와 미확정 transaction 처리에 권장 절차가 있는가.
답변에는 문서 URL, 답변자, 확인일, 적용 계정, 테스트 결과를 연결합니다. 영업 자료의 기능명만 evidence로 남기지 않습니다.
최종 go/no-go 체크리스트
다음 항목을 모두 확인한 뒤 작은 cohort부터 전환합니다.
아키텍처
- [ ] checkout부터 payout까지 시스템·owner·ID 흐름을 그렸다.
- [ ] routing layer, vault, webhook, database 등 단일 장애 지점을 표시했다.
- [ ] gateway A와 B의 merchant account·지역·통화·결제수단 범위를 확인했다.
token과 데이터
- [ ] gateway token, processor token, raw card data를 구분했다.
- [ ] 결제수단 cohort별 portability 상태와 증거가 있다.
- [ ]
unknown또는 고객 action 필요 cohort를 자동 전환에서 제외했다. - [ ] 이전과 실시간 failover를 별도 계획으로 관리한다.
상태와 routing
- [ ] invoice·subscription·entitlement의 기준 시스템을 정했다.
- [ ] timeout, 명시적 거절, 구성 오류를 서로 다른 상태로 처리한다.
- [ ] route rule ID·version·decision reason을 기록한다.
- [ ] 전환 threshold, 최대 cohort, 자동 중지, 복귀 조건이 있다.
중복 방지
- [ ] provider event ID와 내부 payment action ID를 함께 보존한다.
- [ ] gateway가 달라도 같은 업무를 묶는 idempotency key가 있다.
- [ ] 결과 미확정 시 다른 gateway 요청을 막는 guard가 있다.
- [ ] webhook 중복·지연·순서 역전 테스트를 통과했다.
대사와 복구
- [ ] invoice부터 transaction·fee·refund·payout까지 연결된다.
- [ ] gateway·통화·route별 control total과 예외 queue가 있다.
- [ ] 소규모 리허설에서 subscription·entitlement까지 한 번만 갱신됐다.
- [ ] rollback과 주 경로 복귀 runbook을 실제로 연습했다.
- [ ] 미확정 거래와 고객 영향 건의 owner·SLA·sign-off를 정했다.
하나라도 증거가 없으면 전체 자동 전환보다 제한된 수동 검증 경로가 낫습니다. multi-gateway의 목적은 요청을 더 많이 보내는 것이 아니라 같은 결제 의도를 중복 없이 처리하고, 어느 경로를 탔든 상태와 금액을 설명할 수 있게 만드는 것입니다.
마무리: failover 준비의 완성은 전환이 아니라 재현 가능한 복귀입니다
B2B SaaS 결제 공급사 failover는 gateway를 두 개 계약하는 것으로 완성되지 않습니다. 결제수단이 실제로 대체 경로에서 작동하고, invoice와 subscription의 기준 상태가 흔들리지 않으며, timeout 뒤 중복 청구를 막고, 거래부터 payout까지 대사한 뒤 주 경로로 돌아올 수 있어야 합니다.
실행 순서는 간단하게 기억할 수 있습니다.
- 현재 아키텍처와 단일 장애 지점을 그립니다.
- 결제수단별 token·데이터 이식성을 증거로 확인합니다.
- subscription·invoice·entitlement의 기준 상태를 하나로 정합니다.
- 평상시 routing과 장애 failover 규칙을 분리합니다.
- webhook과 업무 idempotency를 gateway보다 상위에서 묶습니다.
- 두 gateway 거래를 같은 reconciliation ledger에서 맞춥니다.
- 작은 cohort로 리허설하고 rollback과 복귀까지 검증합니다.
이 구조가 갖춰져야 공급사 장애 때 “어디로 보낼까”보다 중요한 질문인 “이미 처리됐는가, 한 번만 처리됐는가, 고객 상태와 금액이 맞는가”에 답할 수 있습니다.
공식 출처
About The Author
