거래 실패

​

개요

Dodo Payments는 결제 시도가 실패할 때마다 자세한 실패 이유를 반환합니다. 이 이유는 결제 방법과 공급자에 따라 표준화되어 있어, 애플리케이션에서 일관된 처리를 구현할 수 있습니다. 결제가 실패하면, payment.failed 웹훅과 결제 객체가 다음을 노출합니다:

• error_code — 아래 표에서 표준화된 실패 이유.
• error_message — 사람이 읽을 수 있는 설명.
• retry_attempt — 원래의 청구에 대한 0, 정기 구독 갱신 재시도마다 1 이상.

이 실패 이유를 이해하면 고객에게 명확한 피드백을 제공하고, 재시도가 가치 있는지 판단하며, 더 많은 수익을 회수할 수 있습니다. A step-by-step developer guide for reading these codes from webhooks and the API, surfacing them to customers, and deciding when to retry.

​

소프트 vs. 하드 거절

모든 실패 코드는 두 가지 범주 중 하나에 속합니다. 이 구분은 동일한 결제 수단을 재시도할지 아니면 고객에게 새로운 수단을 요청할지를 결정하는 데 중요합니다. 구독 갱신의 경우, Dodo Payments는 이 구분을 자동으로 적용합니다: Subscription Payment Retries를 통해 소프트 거절은 재시도되고, 하드 거절은 즉시 재시도가 종료되며, Subscription Dunning으로 가장 잘 처리됩니다. STOLEN_CARD, LOST_CARD, PICKUP_CARD, 또는 FRAUDULENT의 실제 이유를 고객에게 공개하지 마십시오. 이를 노출하면 부정 행위자를 경계하게 될 수 있습니다. 항상 고객에게 일반적인 거절 메시지를 표시하십시오 (예를 들어, “카드가 거절되었습니다. 은행에 문의하거나 다른 카드를 사용하십시오.”) 그리고 내부적으로만 특정 코드를 기록하십시오.

​

거래 실패 이유

다음 표는 모든 실패 코드, 거절 유형, 고객이 해결 가능한지 여부, 설명, 그리고 권장 조치를 나열합니다. 사용자 오류는 결제 거절을 고객이 해결할 수 있는지 여부를 나타냅니다. Yes일 때, 고객은 문제를 해결하기 위해 조치를 취할 수 있습니다 (예: 올바른 카드 세부사항 입력). No일 때, 거절은 시스템적 문제나 고객이 직접 해결할 수 없는 은행 제한 때문입니다.

​

실패를 프로그래밍 방식으로 처리하기

error_code를 payment.failed 웹훅 또는 결제 객체에서 읽고, 위에서 권장된 조치에 맵핑한 다음, 재시도할지 여부를 결정하십시오. 정기 구독 갱신의 경우, 소프트 거절은 자동으로 다시 시도됩니다 — Subscription Payment Retries 를 참조하세요. 카드 거절이 아닌 API 수준 및 비즈니스 로직 오류 (예: PAYMENT_NOT_SUCCEEDED 또는 REFUND_WINDOW_EXPIRED)에 대해서는 Error Codes 참고서를 참조하세요.

​

관련 자료

End-to-end guide to detecting, surfacing, and retrying failed payments. API and business-logic error codes for non-decline failures. Automatic retries that recover soft declines on subscription renewals. Email sequences that recover hard declines by prompting a payment method update.

​

지원

거래 실패나 통합 문제에 대한 추가 도움이 필요하면 support@dodopayments.com으로 지원팀에 연락하십시오. 거래 실패 또는 통합 문제에 대한 추가 지원이 필요하시면 support@dodopayments.com으로 저희 지원팀에 연락해 주세요.