결제 연동 착수 점검표 · 국내 PG·간편결제

테스트 착수와 운영 전환의 조건을 나눕니다. 결제사가 제공하는 테스트 키와 환경으로 시작할 수 있는 범위를 확인하고 상점 식별자와 필요한 접근 권한을 준비합니다. 실제 결제는 계약과 심사, 운영 키와 해당 결제수단의 활성화 상태를 확인한 뒤 엽니다. 심사 중인 수단은 테스트 가능한 범위와 운영 활성화 일정을 구분해 개발 순서에 반영합니다. 정산 계좌와 세금계산서 발행 조건, 정산 주기가 계약서와 관리자 화면에서 같은 값인지도 착수 전에 맞춥니다. 결제창을 띄울 도메인과 결과를 받을 서버 주소는 결제사에 미리 등록해야 하므로 개발 환경과 운영 환경 주소를 함께 제출합니다. 운영 키를 누가 보관하고 어디에 두는지도 착수 전에 정해 형상 관리에 올라가지 않게 막습니다. 빌링키나 에스크로처럼 별도 심사가 붙는 기능은 신청 시점을 착수 주에 잡습니다. 연동 문서와 SDK 버전도 이때 고정합니다. 결제사가 여러 버전을 함께 공개하는 경우가 있어 어느 문서를 정본으로 볼지 정하지 않으면 앱과 서버를 서로 다른 규격으로 만들게 됩니다.

주문 상태를 먼저 그립니다. 결제 요청, 승인, 승인 실패, 취소, 부분 취소, 환불, 정산 완료까지 상태를 이름으로 적고 각 전이를 누가 일으키는지 표시합니다. 부분 취소를 몇 번까지 허용할지, 배송이 나뉘는 주문의 취소 단위를 무엇으로 둘지도 여기서 정합니다. 요청마다 붙일 고유 키를 어떻게 만들지, 같은 키가 다시 들어왔을 때 무엇을 돌려줄지를 규칙으로 적습니다. 응답을 받지 못한 거래의 처리도 코드 전에 정합니다. 결제사 조회 규격으로 상태를 되묻는 시점과 횟수, 그래도 확인되지 않은 거래를 어느 상태에 두고 누구에게 알릴지를 미리 정해 둡니다. 결제 금액을 결정하는 쪽도 정합니다. 쿠폰과 포인트가 섞이는 주문은 최종 금액을 서버에서 다시 계산해 승인 요청과 맞추고 어긋나면 승인을 내보내지 않습니다.

성공 결제로 기본 흐름을 확인한 뒤 실패와 예외 경로를 재현합니다. 승인 거절, 한도 초과, 인증 중단, 결제창 이탈, 통보 유실, 통보 중복 수신을 테스트 목록에 넣고 제공되는 샌드박스에서 재현할 수 있는 범위를 확인합니다. 각 경우에 주문이 어느 상태로 남는지, 고객 화면에 무엇이 보이는지, 재시도했을 때 승인이 두 번 나지 않는지를 봅니다. 부분 취소와 전액 환불은 같은 거래에서 순서를 바꿔 가며 걸어 봅니다. 금액이 어긋나는 요청과 이미 취소된 거래를 다시 취소하는 요청도 넣어 응답을 확인합니다. 결제수단이 여럿이면 수단마다 이 목록을 다시 돌립니다. 취소 가능 기간과 환불 절차가 수단별로 다르기 때문입니다. 앱과 웹을 함께 내는 서비스는 두 환경에서 같은 목록을 돌립니다. 결제창이 앱 안에서 열릴 때와 외부 브라우저로 나갈 때 돌아오는 경로가 달라 이탈 처리도 따로 짜야 합니다.

출시일 전에 사람이 쓸 화면이 있어야 합니다. 주문 번호로 거래를 찾고 요청과 승인, 통보 수신, 취소까지 시간순으로 읽는 조회 화면을 고객센터에 먼저 엽니다. 승인 실패와 오류 추이를 결제사별로 보는 지표를 켜고 그 값이 정한 범위를 벗어나면 담당자에게 알리는 경로도 함께 엽니다. 증상별로 먼저 열어 볼 화면과 넘길 담당을 적은 한 장을 고객센터 자리에 붙여 둡니다. 환불 실행 권한은 승인 절차를 정한 뒤에 나눕니다. 결제사 장애를 어디에 접수하고 누구에게 회신이 오는지를 연락처와 함께 적어 두고 첫 실거래가 들어오는 날에는 승인과 취소를 한 건씩 실제로 돌려 정산 파일에 그대로 잡히는지 확인합니다. 이때 잡아 두는 것은 대사 규칙이 아니라 대사에 쓸 항목입니다. 거래 식별자와 승인 번호, 수수료가 붙는 시점이 파일에 어떤 이름으로 오는지를 적어 두면 정산 담당이 규칙을 세울 때 다시 묻지 않습니다.