PG결제 시스템 구조,
여섯 칸이 한 줄로 이어져야

서버가 결제 결과를 확인해야 주문이 끝납니다. 개발형 연동은 결제창을 띄우는 코드 외에도 주문 저장, 금액 검증, 승인 결과 확인과 상태 변경을 포함합니다. 고객 화면의 성공 표시만 믿지 않고 서버가 확인한 거래를 기준으로 상품 제공 여부를 결정해야 합니다. 수신 주소와 인증 · 검증 방식, 거래 식별값과 주문 상태 규칙을 정리합니다.

통신이 잠시 끊긴 뒤 고객이 다시 눌러도 이미 처리한 거래를 반복 반영하지 않도록 조회와 중복 처리 방지를 함께 설계합니다. 실제 API 필드와 호출 순서는 선택한 서비스의 공식 문서에 맞춰 구현하며 다른 PG의 코드를 그대로 대입하지 않습니다. 주문 생성부터 결제 요청 · 결과 검증 · 상태 저장을 연결하고 실패 또는 재요청 경로도 구현합니다. 결과가 여러 번 도착하거나 순서가 달라도 주문이 중복 처리되지 않는지 확인합니다.

결과 수신과 주문 상태 변경을 함께 검증합니다. PG에서 승인 결과를 받는 것과 사이트의 주문을 완료로 바꾸는 것은 연결된 별도 작업입니다. 결과를 검증하고 거래를 저장한 뒤 고객 · 운영자가 같은 상태를 볼 수 있도록 처리해야 합니다. 이벤트 종류, 수신 주소, 거래 조회 방법과 재처리 기준을 정리합니다.

승인 알림은 왔는데 주문이 대기로 남았다면 수신 로그와 저장 · 상태 변경 과정에서 멈춘 지점을 찾아볼 수 있습니다. 수신 메시지가 있다는 사실만으로 내용을 신뢰하지 않고 해당 서비스의 검증 · 조회 절차를 따릅니다. 공식 SDK · API의 결과 처리 안내에 맞춰 서버에서 검증 · 저장 · 상태 변경을 수행합니다. 가상계좌 입금처럼 시간이 지난 뒤 들어오는 결과도 주문 상태에 반영되는지 확인합니다. 결과가 여러 번 도착하거나 순서가 달라도 주문이 중복 처리되지 않는지 확인합니다.

완료 페이지는 확인된 주문 상태를 보여 줍니다. 결제창이 닫힌 뒤 고객이 무엇을 샀고 결제가 어떤 상태인지 이해할 수 있어야 합니다. 완료 페이지는 결제를 승인하는 수단 자체가 아니므로 서버에서 확인한 결과와 주문 정보를 가져와 안내하도록 구성합니다. 승인 · 입금 대기 · 취소 접수 · 취소 완료 등 운영 상태별 안내 문구를 준비합니다.

가상계좌가 발급된 단계에서는 결제 완료라고 표시하기보다 입금 대기와 기한을 안내해 출고 판단을 구분합니다. URL에 성공이라는 값이 들어 있다는 이유만으로 상품을 제공하지 말고 서버에 저장된 상태를 기준으로 처리합니다. 주문번호와 결제 상태를 보여 주고 배송 · 예약 등 다음 행동을 실제 상품 흐름에 맞춰 안내합니다. 안내 시점의 상태와 실제 관리자 기록, 고객 조회 화면이 같은지 대조합니다. 새로고침하거나 주소를 다시 열어도 같은 주문이 중복 생성되지 않는지 확인합니다.

실패 재시도 전에 원거래 상태를 조회합니다. 통신 오류나 인증 중단은 결제 자체가 실패했다는 뜻과 같지 않을 수 있습니다. 승인 여부가 불확실한 상태에서 같은 청구를 곧바로 반복하면 고객 안내와 주문 기록이 꼬일 수 있어 확인 순서를 마련합니다. 기록할 작업과 담당자 권한, 거래 식별자 · 시각 · 결과 항목을 정합니다.

정기결제 실패가 카드 만료 때문이라면 무작정 반복 청구하기보다 고객이 결제 수단을 갱신할 수 있는 안내가 필요합니다. 실패 사유별 재시도 가능 여부와 정책은 서비스 문서 · 계약 및 고객에게 안내한 조건을 따릅니다. 거래 조회로 원결제 상태를 확인하고 처리되지 않은 경우에만 정해진 정책으로 재시도합니다. 고객 문의와 실제 처리 내역을 연결할 수 있는지 정기적으로 확인합니다. 성공 처리된 주문에 새 요청이 중복 반영되지 않는지 확인합니다.

흐름도에는 고객과 서버의 역할을 구분합니다. 주문→결제창→승인→결과→완료→정산의 흐름을 볼 때 고객 화면에서 하는 일과 서버 · 운영자가 확인하는 일을 나누면 개발 범위가 선명해집니다. 화면 이동이 성공했다고 서버 검증까지 끝난 것은 아닐 수 있습니다. 주문 · 결제창 · 승인 · 결과 수신 · 완료 · 정산의 담당자와 필요한 값을 적습니다.

고객이 승인 직후 창을 닫아도 서버에서 결제 결과를 확인하고 주문을 조회할 수 있어야 실제 제공 여부를 판단할 수 있습니다. 그림의 순서는 이해를 돕는 구조이며 실제 인증 · 승인 API 호출은 선택한 서비스의 공식 문서에 맞춥니다. 주문 식별값과 금액을 연결하고 결과 검증 뒤 상태를 변경하도록 설계합니다. 중간에 브라우저가 닫히거나 통신이 끊겨도 실제 결제 결과를 조회할 수 있는지 시험합니다. 통신 중단 · 재요청 · 앱 복귀 실패에도 거래 상태를 확인할 수 있는지 시험합니다.

주문번호와 결제 식별값을 연결해 둡니다. 주문은 고객이 무엇을 사기로 했는지에 대한 기록이고 결제는 그 대금이 처리된 기록입니다. 한 주문에 재시도나 부분 취소가 붙을 수 있으므로 번호 하나만으로 두 기록을 같은 것으로 취급하지 않는 것이 좋습니다. 옵션별 구성과 추가 금액, 배송 · 설치 등 부대 비용과 최종 합계를 정리합니다.

고객이 뒤로 가기를 누른 뒤 재결제한 경우에도 각 시도와 최종 유효 거래를 구분하면 문의 대응이 쉬워집니다. 카드번호와 비밀번호를 주문 정보에 직접 저장하는 방식 대신 승인된 결제 서비스가 제공하는 식별자를 사용합니다. 할인 · 배송비 계산이 끝난 금액을 서버에 보관하고 승인 요청과 결과를 그 주문에 연결합니다. 결제 결과에 저장된 금액과 주문 구성, 고객에게 보이는 설명이 맞는지 시험합니다. 같은 주문의 중복 요청, 금액 불일치와 이미 취소된 거래가 걸러지는지 시험합니다.

알림을 받으면 거래 상태를 다시 확인합니다. 결제 결과는 고객의 화면 이동과 서버 알림이 서로 다른 시점에 도착할 수 있습니다. 알림 누락 · 재전송 · 순서 차이를 고려하고 실제 결제 상태 조회를 통해 주문 기록을 일관되게 유지하는 흐름을 마련합니다. 주문 · 승인 · 알림 · 제공 상태와 재처리 가능한 담당 기능을 정리합니다.

고객이 결제 직후 브라우저를 닫아 완료 페이지에 오지 않아도 서버 알림과 거래 조회를 통해 승인 사실을 확인할 수 있어야 합니다. 알림의 서명 · 인증 방식과 재시도 정책은 서비스마다 다르므로 공식 개발 문서 기준으로 적용합니다. 검증된 알림만 처리하고 같은 이벤트가 반복되어도 상품 제공이나 취소를 중복 반영하지 않게 합니다. 재처리 결과가 기존 주문에 한 번만 연결되고 고객 안내가 갱신되는지 확인합니다. 가상계좌 입금처럼 시간이 지난 뒤 들어오는 결과도 주문 상태에 반영되는지 확인합니다.

문제가 난 단계만 다시 처리할 수 있게 합니다. 결제 이후 알림이나 상품 제공이 실패해도 승인 자체가 취소된 것은 아닐 수 있습니다. 각 단계의 상태를 분리해 재처리하면 고객에게 대금을 다시 받거나 같은 상품을 중복 제공하는 문제를 줄일 수 있습니다. 청구 식별자와 주문번호, 실패 유형, 재시도 횟수 · 간격 기준을 정합니다.

결제는 성공했지만 강의 접근 권한이 열리지 않았다면 결제를 다시 요청하는 대신 해당 주문의 권한 부여 결과부터 점검합니다. 원거래 상태가 불확실할 때는 임의로 실패나 취소로 바꾸지 말고 공식 조회 · 문의 경로로 확인합니다. 실패한 단계의 근거를 확인하고 원거래 상태를 유지하며 필요한 작업만 재실행합니다. 성공 처리된 주문에 새 요청이 중복 반영되지 않는지 확인합니다. 재처리 결과가 기존 주문에 한 번만 연결되고 고객 안내가 갱신되는지 확인합니다.

청구액은 서버의 주문 금액과 맞춥니다. 고객 화면에서 전달된 금액은 조작되거나 오래된 값일 수 있어 서버가 보관한 최종 주문 금액과 대조해야 합니다. 할인 · 배송비 계산과 재고 · 옵션을 확정한 뒤 승인 결과를 검증해 실제 주문에 반영합니다. 주문번호, 상품 구성, 최종 청구액, 결제 식별값과 상태를 저장할 항목을 정합니다.

주문서가 열린 동안 상품 가격이나 쿠폰 조건이 바뀌었다면 최종 확정 금액을 고객에게 보여 주고 동일한 값으로 처리해야 합니다. URL이나 브라우저의 성공 표시만 믿고 금액 검증 없이 상품을 제공하지 않습니다. 서버에 보관한 주문과 결제 요청 · 결과의 금액을 비교하고 불일치는 승인 · 제공 흐름에서 분리합니다. 같은 주문의 중복 요청, 금액 불일치와 이미 취소된 거래가 걸러지는지 시험합니다. 같은 주문의 반복 요청과 가격 변경 후 재시도에서도 검증이 유지되는지 시험합니다.

주문에서 정산까지 여섯 단계를 연결합니다. 주문을 만들고 결제창에서 인증한 뒤 서버가 결과를 확인하면 고객에게 완료 상태를 알리고 이후 정산을 확인합니다. 각 단계의 입력과 결과가 이어져야 실패 위치를 찾고 고객에게 현재 상황을 정확히 안내할 수 있습니다. 각 단계의 입력 · 출력과 담당 주체, 실패 시 돌아갈 위치를 정합니다.

완료 페이지가 열리지 않았다고 결제를 다시 받기 전에 승인 결과를 조회할 수 있어야 중복 청구를 줄일 수 있습니다. 여섯 단계는 이해를 위한 공통 구조이며 세부 인증 · 승인 순서는 선택한 결제 서비스의 방식에 맞춰 적용합니다. 각 단계가 끝나는 기준을 정하고 다음 단계로 넘길 식별값과 상태를 연결합니다. 통신 중단 · 재요청 · 앱 복귀 실패에도 거래 상태를 확인할 수 있는지 시험합니다. 중간에 브라우저가 닫히거나 통신이 끊겨도 실제 결제 결과를 조회할 수 있는지 시험합니다.