결제 대기 주문 상태 설계는 사용자가 결제창에서 돌아왔을 때 시작되는 문제가 아닙니다. 주문 생성, 결제 시도, 제공자의 결과 통지, 재고 예약이 서로 다른 시간에 진행되기 때문에 처음부터 상태 관계를 정해야 합니다. 화면에 실패라고 쓰는 순간에도 제공자 쪽에서는 결제가 진행 중일 수 있으며, 반대 상황도 가능합니다.
가상의 취미용품 쇼핑 앱에서 사용자가 마지막 재고를 주문한다고 가정합니다. 결제 요청 후 연결이 끊겨 결과를 보지 못했고 다시 결제 버튼을 누릅니다. 이 예시는 실제 거래 실적이 아닙니다. 목표는 같은 구매 의도에서 주문이나 청구가 불필요하게 반복되지 않고, 현재 확인된 상태를 운영자와 사용자가 함께 이해하는 것입니다.
주문과 결제 시도의 관계 정하기
하나의 주문에 여러 결제 시도가 생길 수 있지만, 각 시도가 어떤 주문과 연결되는지 명확해야 합니다. 금액, 통화, 결제 대상, 제공자 식별자를 기록하고 실제 결과와 대조합니다. 새 시도를 허용하기 전에 기존 시도의 상태를 확인하며, 성공한 시도가 있는 주문을 다시 결제하도록 안내하지 않습니다.
시간 초과는 통신 결과이지 곧바로 결제 실패의 증거는 아닙니다. 결과 확인 중이라는 상태와 확인 방법을 제공하고, 제공자의 조회나 통지를 통해 확정합니다. 무제한 조회로 부하를 늘리지 않도록 재확인 정책을 정합니다. 오래 미확정인 건은 담당자가 찾을 수 있는 운영 목록에 남겨야 합니다.
통지는 순서와 중복을 고려하기
결제 통지는 중복되거나 예상과 다른 순서로 도착할 수 있습니다. 이미 처리한 이벤트를 식별하고, 오래된 상태가 확인된 최신 결과를 덮지 못하게 합니다. 통지의 진위를 검증하고 해당 주문의 금액과 통화도 대조합니다. 외부에서 받은 문자열 하나만으로 상품 제공을 결정해서는 안 됩니다.
사용자가 보는 완료 화면과 서버의 주문 처리도 구분해야 합니다. 브라우저 복귀 주소를 열었다는 이유만으로 결제 완료를 확정하지 않습니다. 서버에서 확인된 상태가 준비되면 그 결과를 표시하고, 기다리는 동안에는 중복 결제를 유도하지 않는 안내를 제공합니다. 확인이 늦어져도 기존 주문 번호를 계속 찾을 수 있어야 합니다.
취소와 재고의 시간표 맞추기
주문 취소 요청과 실제 취소 완료는 다른 상태일 수 있습니다. 이미 결제가 완료됐다면 환불 절차가 필요할 수 있고, 제공자가 취소를 허용하지 않는 단계도 있습니다. 어떤 결과에서 누가 후속 조치를 할지 합의합니다. 환불 요청을 보냈다는 사실도 환불 완료와 구분하여 사용자에게 정확한 진행 상황을 보여줍니다.
결제 대기 중 재고를 얼마나 예약할지도 정해야 합니다. 예약이 만료된 뒤 늦은 결제 성공이 도착하면 상품을 제공할 수 있는지 다시 판단해야 합니다. 재고가 없는데 자동으로 주문을 완료하거나, 결제된 사실을 숨긴 채 주문을 삭제하지 않습니다. 예외 목록과 담당자의 처리 경로가 이 상황을 설명할 수 있어야 합니다.
지연과 재시도를 포함해 검증하기
테스트 환경에서 결제 응답 지연, 같은 통지의 반복, 역순 통지, 취소 직후 성공, 재고 예약 만료를 발생시킵니다. 각 상황에서 주문 수, 결제 시도, 청구 결과, 재고, 사용자 안내를 함께 확인하세요. 앱을 닫고 다시 열었을 때도 원래 주문을 찾고 이어서 확인할 수 있어야 합니다.
Brainbaby Labs에는 현재 결제 제공자, 주문 흐름, 재고 정책과 실제로 겪는 미확정 사례를 공유하면 됩니다. 제공자별 동작을 확인하고 주문 백엔드와 앱 화면을 연결해 개발 범위를 정할 수 있습니다. 테스트 성공은 운영 결제의 모든 상황을 보장하지 않으므로, 출시 후 대조와 예외 처리를 맡을 운영 책임도 함께 정해야 합니다.