자사몰 결제 오류 뒤 주문이 안 보일 때: 승인·주문생성·취소를 나누는 확인표
고객이 “결제는 됐는데 주문내역이 없어요”라고 문의하면 고객에게 같은 결제를 다시 시도해 달라고 먼저 말하기 쉽습니다. 그러나 결제창이 끝났다는 화면, PG의 승인 기록, 자사몰 주문 생성은 서로 다른 기록일 수 있습니다. 첫 결제가 승인된 상태에서 재결제를 권하면 고객에게 두 건의 승인이 생기고, 반대로 승인이 없는데 주문만 만들어진 상태라면 재고와 CS가 다른 방향으로 움직입니다.
이 글은 자사몰 결제 오류를 특정 PG의 설정 문제로 단정하지 않고, 고객 문의가 들어온 순간 운영자가 확인할 순서를 다룹니다. 결제 요청·인증·승인·주문 생성·취소라는 다섯 지점을 분리하고, 쇼핑몰 관리자·PG 조회 화면·서버 또는 웹훅 로그에서 같은 거래를 찾는 방식입니다. 결제 전 이탈률 개선은 자사몰 결제 전환율 최적화, 사기 주문을 미리 거르는 운영은 자사몰 주문 이상 감지에서 별도로 다룹니다.
결제 오류를 ‘실패’ 한 단어로 묶지 않습니다
결제 과정에서 화면이 멈추거나 성공 페이지로 돌아오지 않았다는 사실만으로 승인 여부를 알 수 없습니다. 운영자는 아래 다섯 상태를 별도로 표시해야 합니다. PG마다 이름과 화면 위치는 다르지만, 토스페이먼츠 공식 문서도 결제 승인·결제 조회·결제 취소·거래 조회를 구분하고 주문번호와 결제 식별자를 별도로 다룹니다.
| 단계 | 고객이 보는 현상 | 운영자가 확인할 기록 | 이 단계만으로 확정할 수 없는 것 |
|---|---|---|---|
| 결제 요청 | 결제창을 열고 금액을 확인함 | 장바구니·주문 초안·요청 시각 | 카드 승인 |
| 인증 | 카드·간편결제 인증을 통과함 | PG 요청 ID·인증 결과 | 자사몰 주문 생성 |
| 승인 | PG가 결제를 승인함 | 결제키·주문번호·승인 금액 | 출고 가능한 주문 상태 |
| 주문 생성 | 관리자에 주문이 보임 | 주문 ID·상품·재고·고객 정보 | PG 취소 완료 |
| 취소·환불 | 결제 취소 또는 환불을 요청함 | 취소 거래·환불 상태·처리 시각 | 고객 계좌 반영 완료 |
토스페이먼츠의 코어 API 문서에는 승인된 결제를 결제키나 주문번호로 조회하는 기능과 취소 기능이 별도로 설명되어 있습니다. 이 글에서 특정 서비스의 API를 사용하라는 뜻은 아닙니다. 현재 자사몰이 사용하는 PG에서 ‘승인된 결제 조회’, ‘주문 조회’, ‘취소 거래’에 해당하는 화면과 필드를 먼저 찾아야 한다는 의미입니다. 토스페이먼츠 코어 API를 공통 개념을 확인하는 참고 자료로 볼 수 있습니다.
먼저 세 기록의 공통 키를 찾습니다
고객 이름과 금액만으로 결제 건을 찾으면 동명이인·동일 금액 주문·재시도 결제가 섞일 수 있습니다. 문의가 들어오면 고객에게 카드번호 전체나 비밀번호를 요구하지 말고, 자사몰 주문번호·결제 완료 화면의 주문 식별자·결제 시각·결제수단의 일부 정보만 안전한 채널로 확인합니다. PG 관리자는 그 식별자를 사용해 결제 조회를 하고, 쇼핑몰 관리자는 같은 시간대 주문을 검색합니다.
| 기록 | 일반적으로 찾을 식별자 | 대조할 값 | 없을 때 해석 |
|---|---|---|---|
| 자사몰 주문 | 주문번호·주문 ID | 상품·금액·고객·생성 시각 | 승인 뒤 주문 생성 실패 가능성 |
| PG 결제 | paymentKey·merchant UID·거래번호 등 | 승인 상태·승인 금액·결제수단 | 승인 전 이탈 또는 조회 키 오류 가능성 |
| 취소 거래 | transactionKey·취소 ID 등 | 취소 금액·사유·요청 시각 | 아직 취소 요청 전이거나 다른 건을 조회한 상태 |
| 웹훅·서버 로그 | 이벤트 ID·요청 ID·수신 시각 | 수신 성공·재시도·응답 코드 | 주문 생성 이벤트 누락 가능성 |
식별자 명칭은 PG와 쇼핑몰에 따라 달라질 수 있으므로, 표의 예시를 모든 시스템의 필수 값처럼 복사하지 않습니다. 핵심은 한 거래의 요청·승인·주문·취소를 연결할 수 있는 고유값을 하나의 사건표에 모으는 것입니다. 고객이 주문번호를 받지 못했다면 결제 시각과 금액으로 후보를 좁힌 다음, PG의 고객 식별 정보와 자사몰의 비회원 주문 정보를 제한적으로 대조합니다.
고객에게 처음 요청할 정보
| 요청 항목 | 요청하는 이유 | 받지 말아야 할 정보 |
|---|---|---|
| 결제 시각과 시간대 | 요청·승인 시각을 맞추기 위해 | 카드번호 전체 |
| 결제 금액·통화 | 동일 금액 주문을 구분하기 위해 | CVC·비밀번호 |
| 결제수단 종류 | PG 조회 필터를 맞추기 위해 | 앱 로그인 비밀번호 |
| 성공 화면의 주문번호 일부 | 자사몰 주문과 PG 기록을 연결하기 위해 | 신분증 전체 이미지 |
| 오류 문구·화면 캡처 | 인증·승인·주문 생성 지점을 추정하기 위해 | 공개 게시판에 올린 개인정보 |
고객이 보내는 화면에는 이름·전화번호·주소·결제수단 정보가 함께 보일 수 있습니다. CS 도구에 저장할 때는 필요 없는 개인정보를 가리고, 상담 기록에는 결제 상태를 확인하는 데 필요한 정보만 남깁니다.
쇼핑몰 주문과 PG 승인을 같은 시간창에서 비교합니다
첫 번째 조회는 넓게, 두 번째 조회는 좁게 합니다. 예를 들어 고객이 14시 03분에 결제했다고 하면 14시 00분부터 14시 10분까지 같은 금액·결제수단의 주문과 PG 거래를 찾고, 후보가 발견되면 주문번호와 결제 식별자를 정확히 대조합니다. 요청 시각과 승인 시각이 다를 수 있으므로 관리자 화면의 ‘주문일’ 하나만 보고 누락을 결론 내리지 않습니다.
포트원 결제 내역 문서도 결제 요청 시각과 상태 승인 시각을 기준으로 조회 결과가 달라질 수 있다고 설명하고, 결제 예정·완료·실패·취소 등 상태 필터를 구분합니다. 따라서 시간 범위를 한 번만 고정하지 말고 요청 시각과 승인 시각 두 기준으로 확인합니다. 포트원 결제 내역 조회는 이런 조회 기준을 점검할 때 참고할 수 있습니다.
| 조회 순서 | 자사몰 관리자 | PG·결제 관리자 | 판단 메모 |
|---|---|---|---|
| 1차 | 고객이 알려 준 시각 전후 주문 | 같은 시간대 요청·승인 내역 | 후보를 넓게 찾기 |
| 2차 | 주문번호·금액·고객 정보 | orderId·paymentKey·승인 금액 | 같은 결제인지 대조 |
| 3차 | 주문 상태·재고 차감 여부 | DONE·실패·취소 등 상태 | 출고 보류 여부 판단 |
| 4차 | 주문 생성 로그·웹훅 처리 | 거래·취소 로그 | 누락·재시도 여부 확인 |
| 5차 | 고객 안내 기록 | 취소·환불 응답 | 다음 확인 시각 예약 |
주문이 없다고 해서 PG 승인도 없다고 가정하지 않습니다. 반대로 PG 조회 결과가 없다고 해서 고객이 거짓말한다고 단정하지 않습니다. 결제수단, 조회 기준 시각, 테스트·실결제 모드, 상점 ID가 서로 다르면 같은 화면에서도 결과가 달라질 수 있습니다.
승인만 있고 주문이 없으면 재결제보다 주문 생성 경로를 확인합니다
가장 조심해야 하는 경우는 PG에는 승인 거래가 있지만 자사몰 관리자에 주문이 보이지 않는 상황입니다. 이때 고객에게 재결제를 권하기 전에 해당 승인과 연결된 주문 생성 요청, 웹훅 수신, 재시도 로그를 확인합니다. 주문 생성이 늦어진 것인지, 필수 고객 정보 검증에서 실패했는지, 서버 응답이 끊겼는지에 따라 다음 조치가 달라집니다.
| 관찰 결과 | 고객에게 말할 내용 | 운영자가 할 일 |
|---|---|---|
| PG 승인 없음·자사몰 주문 없음 | 결제가 승인된 기록을 먼저 확인 중이라고 안내 | 실패 코드·요청 로그 확인 후 재시도 안내 |
| PG 승인 있음·자사몰 주문 없음 | 승인 기록을 확인했으니 중복 결제 전 추가 확인한다고 안내 | 주문 생성 로그·웹훅·재처리 경로 확인 |
| PG 승인 있음·주문 있음 | 주문번호와 현재 상태를 안내 | 재고·출고·알림 발송 상태 확인 |
| PG 승인 취소·주문 있음 | 결제 상태와 주문 상태를 함께 확인 중이라고 안내 | 주문 보류·취소·재결제 필요 여부 판단 |
| 같은 금액 승인 두 건 | 두 거래를 구분해 확인하겠다고 안내 | 고객에게 임의 재결제를 요구하지 않고 각각 조회 |
주문 생성 재처리를 할 때는 같은 결제 식별자로 중복 주문이 생기지 않는지 확인해야 합니다. 관리자에서 버튼 하나를 반복해서 누르거나, 고객에게 새 주문을 먼저 넣으라고 안내하기보다 기존 승인과 주문 ID의 연결 여부를 먼저 확인합니다. 결제 승인 웹훅이 늦게 들어오는 시스템이라면 재처리 기준과 중복 방지 규칙을 문서화해 담당자마다 다른 조치를 하지 않게 합니다.
승인 뒤 취소가 필요한지 거래 이력으로 판별합니다
PG 승인만 확인하고 바로 취소를 보내면, 이미 취소된 거래에 두 번째 취소를 요청하거나 잘못된 결제 건을 취소할 수 있습니다. 먼저 거래 이력에서 승인 거래와 취소·부분 취소 거래를 함께 봅니다. 토스페이먼츠 문서에서는 승인·취소·부분 취소가 각각 거래로 기록되고, 취소 요청에는 승인 결과의 결제 식별자가 필요하며, 멱등키로 중복 취소를 줄일 수 있다고 설명합니다.
| 상태 조합 | 취소 버튼을 누르기 전 확인 | 운영 방향 |
|---|---|---|
| 승인 거래만 있음 | 주문 생성 실패·재고·고객 의사 | 주문 복구와 취소 중 하나를 결정 |
| 승인+전액 취소 거래 | 취소 금액과 취소 완료 상태 | 추가 취소 금지, 고객에게 반영 단계 안내 |
| 승인+부분 취소 거래 | 남은 승인 금액과 부분 취소 사유 | 금액을 다시 계산한 뒤 추가 처리 |
| 승인 상태를 찾지 못함 | 조회 기간·상점 ID·결제수단 | PG 문의 전 조회 조건 재확인 |
| 취소 요청 실패 | 실패 코드·재시도 가능 여부 | 같은 요청 반복 전 멱등·상태 확인 |
취소는 주문 상태 변경과 결제 거래 취소를 동시에 의미하지 않을 수 있습니다. 상품을 출고하지 않도록 주문을 보류하는 것, 자사몰 주문을 취소 상태로 바꾸는 것, PG에 결제 취소를 요청하는 것은 서로 다른 기록입니다. 일반적인 주문 취소 흐름은 자사몰 주문 취소 상태값 설계, 환불이 늦어지는 고객 안내는 자사몰 환불 지연 운영표에서 별도로 확인합니다.
토스페이먼츠의 취소 가이드도 결제수단에 따라 취소 기한과 환불 소요가 다를 수 있다고 안내합니다. 따라서 “몇 분이면 입금됩니다” 같은 고정 문장을 만들지 말고, 확인된 취소 요청 시각·현재 상태·다음 확인 시각만 고객에게 전달합니다. 토스페이먼츠 결제 취소 가이드는 특정 PG를 사용하지 않는 운영자도 취소 거래를 어떤 항목으로 확인할지 참고할 수 있습니다.
고객 안내는 확인된 상태와 다음 확인 시각만 말합니다
결제 장애 때 고객이 가장 불안해하는 것은 돈이 빠져나갔는지와 다시 결제해야 하는지입니다. 아직 승인 여부를 확인하지 못했다면 “결제 실패”라고 단정하지 말고, 현재 확인 중인 기록과 다음 답변 시간을 안내합니다. 운영자가 확인하지 않은 환불 시각이나 보상 결과를 먼저 약속하면 이후 PG 답변과 충돌할 수 있습니다.
| 확인 수준 | 고객 안내 예시 | 피할 표현 |
|---|---|---|
| 조회 중 | 결제 시각과 금액을 기준으로 승인·주문 기록을 확인 중입니다. 중복 결제 방지를 위해 잠시 재결제를 보류해 주세요. | 아직 결제 상태를 확인할 수 없습니다 |
| 승인·주문 미생성 | PG 승인 기록과 주문 생성 여부를 대조 중이며, 확인 후 주문 생성 또는 취소 방향을 안내하겠습니다. | 주문이 없으니 다시 결제하세요 |
| 승인·주문 생성 | 주문번호와 현재 주문 상태를 안내하고 출고 전 확인 절차를 설명합니다. | 결제 문제는 완전히 해결됐습니다 |
| 취소 접수 | 취소 요청 시각과 현재 취소 상태를 안내하고 카드사·결제수단 반영 시점은 확인 후 안내합니다. | 지금 바로 환불됩니다 |
고객이 비회원이라 주문번호를 잃었다면 자사몰 비회원 주문 조회 UX의 본인 확인 원칙을 따르되, 상담 채널에서 결제 비밀번호나 카드 전체 정보를 받지 않습니다. 고객이 이미 두 번 결제했다면 두 승인 건을 각각 조회해 어느 건을 유지하거나 취소할지 기록으로 남깁니다.
장애가 끝난 뒤에는 다섯 줄의 대사 로그를 남깁니다
한 건의 결제 오류를 해결한 뒤에도 다음 담당자가 같은 실수를 반복하지 않도록 짧은 사후 로그를 남깁니다. 긴 개발 보고서가 아니어도 됩니다. 같은 사건을 다시 찾을 수 있는 식별자와 상태 변화만 남기면 됩니다.
| 로그 줄 | 남길 내용 | 작성 예시 |
|---|---|---|
| 요청 | 고객 문의 시각·주문 시도 시각 | 14:03 요청, 14:06 문의 |
| 승인 | PG 결제 식별자·승인 상태·금액 | 승인 있음, 주문번호 없음 |
| 주문 | 자사몰 주문 ID·생성 시각·재고 | 재처리 후 주문 생성 |
| 취소 | 취소 거래 ID·사유·응답 상태 | 중복 방지 후 취소 접수 |
| 안내 | 고객에게 말한 내용·다음 확인 시각 | 15:00 상태 재안내 |
재발 방지는 결제 코드만 고치는 일로 끝나지 않습니다. 주문 생성 실패 뒤 PG 승인만 남는 사례, 웹훅 재전송이 중복 주문을 만드는 사례, 관리자 화면의 시간대가 다르게 보이는 사례를 분류하고, 각 유형에 담당자·확인 키·고객 안내 문장을 붙입니다. 거래조건과 환불 정책은 고객이 쉽게 확인할 수 있어야 하며, 전자상거래법과 소비자원 안내는 이를 운영 문구와 함께 점검하는 기준이 됩니다. 한국소비자원 온라인 거래 피해예방 체크포인트와 전자상거래 등에서의 소비자보호에 관한 법률을 최신 기준으로 확인합니다.
자사몰 결제 오류 15분 확인표
- [ ] 고객의 결제 시각·금액·결제수단·오류 화면을 안전하게 받았다.
- [ ] 자사몰 주문 검색 기준을 요청 시각과 승인 시각으로 각각 확인했다.
- [ ] PG 승인 상태와 주문 생성 상태를 따로 적었다.
- [ ] 주문번호·결제키·거래번호 등 공통 식별자를 연결했다.
- [ ] 승인만 있는 경우 웹훅·서버 로그·주문 생성 재처리 여부를 확인했다.
- [ ] 승인과 취소 거래가 이미 함께 있는지 확인한 뒤 취소를 판단했다.
- [ ] 같은 거래를 반복 취소하지 않도록 취소 사유·응답·멱등 처리 여부를 기록했다.
- [ ] 고객에게 재결제·환불 시각·보상 결과를 확인 전 약속하지 않았다.
- [ ] 해결 뒤 요청·승인·주문·취소·안내 로그를 다섯 줄로 남겼다.
자사몰 결제 오류의 핵심은 결제창의 마지막 화면을 믿느냐의 문제가 아니라, 고객·쇼핑몰·PG의 서로 다른 기록을 같은 식별자와 시간 기준으로 맞추는 일입니다. 실제 사용하는 PG의 관리자와 문서에서 필드명과 처리 조건을 확인하고, 승인 여부를 모르는 상태에서는 재결제나 중복 취소를 먼저 지시하지 않는 운영표를 팀에 공유하세요.
공식 확인 링크
- 토스페이먼츠 코어 API
- 토스페이먼츠 결제 취소하기
- 토스페이먼츠 결제와 거래, 차이점
- 포트원 결제 내역 조회
- 국가법령정보센터 전자상거래법
- 한국소비자원 온라인 거래 피해예방 체크포인트