결제 연동을 붙이기 전에 정해 둘 상태 값

주문과 결제 시도를 별도로 기록합니다

주문은 사용자가 무엇을 구매하려는지 나타내고, 결제 시도는 그 주문의 대금을 처리하려는 한 번의 작업입니다. 사용자가 결제를 취소한 뒤 다른 수단으로 다시 시도할 수 있으므로 두 개념을 같은 기록 하나로만 관리하면 이전 결과를 추적하기 어려워집니다.

주문 식별자와 결제 시도 식별자를 구분하고, 외부 결제 서비스의 식별자를 어느 시도에 연결할지 정합니다. 금액과 통화, 대상 상품은 서버가 확인하는 정보여야 하며 화면이 보낸 값만으로 최종 결과를 판단하지 않도록 설계합니다.

화면에 필요한 문구와 운영자가 보는 상세 상태도 구분합니다. 사용자에게는 다음 행동이 명확해야 하고, 운영자는 어떤 시도가 어떤 외부 응답과 연결되는지 찾아볼 수 있어야 합니다.

결과를 모르는 상태를 실패와 구분합니다

결제창을 닫았거나 응답을 기다리다 연결이 끊겼다고 해서 실제 결제가 실패했다고 단정할 수는 없습니다. 외부 처리는 끝났지만 앱이 결과를 받지 못한 상황도 고려해야 합니다. 결과를 확인하는 동안에는 재결제를 바로 유도하기보다 현재 상태를 조회하는 흐름을 준비합니다.

• 준비·진행 중 요청을 만들거나 사용자 입력을 기다리는 상태
• 결과 확인 중 최종 결과를 아직 확정할 수 없는 상태
• 완료·실패·취소 확인된 결과에 따라 후속 행동을 정하는 상태
• 환불 요청·진행·완료·실패 결제 완료 이후 별도로 추적할 상태

이 목록은 설계 예시입니다. 실제 상태와 전환은 사용하는 결제 서비스의 모델에 맞춰 정하고, 어떤 사건이 각 상태를 바꿀 수 있는지 표로 남깁니다.

알림의 순서와 중복에 기대지 않습니다

서버가 결제 결과를 받는 경로와 앱이 보여 주는 화면은 함께 검토해야 합니다. 브라우저가 완료 주소로 돌아왔다는 사실만으로 주문을 최종 확정하지 않고, 서버에서 확인한 결과를 기준으로 표시하도록 구성합니다.

Stripe의 웹훅 문서는 이벤트의 중복 수신과 순서 차이를 고려하고 서명을 검증하도록 설명합니다. 연동하는 서비스의 계약을 확인한 뒤, 이미 처리한 이벤트를 다시 받거나 늦은 이벤트가 도착해도 주문 상태가 잘못 바뀌지 않게 설계해야 합니다.

알림을 받았다는 기록과 후속 작업을 완료했다는 기록도 구분합니다. 결제 확인 뒤 상품 제공이나 영수증 처리에 실패했다면 어느 단계부터 재시도할지 추적할 수 있어야 합니다. 외부 결과를 다시 조회해 맞추는 운영 절차도 마련합니다.

실패와 재시도를 포함한 흐름을 확인합니다

테스트 환경에서는 성공 결제 외에 사용자 취소, 연결 중단, 결과 지연, 같은 요청의 재전송, 중복 알림, 환불 처리 실패를 확인합니다. 각 경우에 주문과 결제 시도, 사용자 안내가 서로 맞는지 살펴보세요.

예를 들어 결과가 늦게 도착한 뒤 사용자가 새로고침했을 때 결제 완료 화면이 일관되게 보이는지, 중복 이벤트가 와도 상품 제공이 반복되지 않는지 확인할 수 있습니다. 금액을 변경한 요청이나 다른 주문의 식별자에 대해서도 서버의 거부 동작을 검사합니다.

운영 화면에는 확인이 필요한 건을 찾을 수 있는 상태와 이력을 남깁니다. 민감한 결제 정보를 무분별하게 로그에 기록하지 않으면서 주문과 시도를 추적할 수 있어야 합니다. 완료 기준에는 화면뿐 아니라 복구 절차도 포함됩니다.