일본 결제(PG) 연동, 기획자는 무엇을 챙겨야 하는가

들어가며

안녕하세요. 노머스에서 PM으로 근무하고 있는 백승일입니다.

일본 커머스 플랫폼의 결제 파트를 맡았을 때 크게 어렵지 않을 거라 생각했습니다. 카드사 승인받고 결제 완료되면 끝나는 일이고 나라만 다를 뿐 구조는 비슷하지 않을까 하고요.

이 글은 SBPS를 PG사로 일본 결제 연동을 진행하며 실제로 부딪힌 문제들과 그 과정에서 기획자로서 다르게 챙겨야 했던 것들을 정리한 기록입니다.

일본 결제 생태계, 간단히

가맹점 – PG사 – 결제 기관(카드사/편의점/간편결제사)을 연결하는 구조 자체는 한국과 같습니다.

다만 참여자 구성이 조금 다릅니다.

구분	역할	프로젝트 기준
PG사	여러 결제 수단을 하나의 계약으로 묶어 제공	SBPS (소프트뱅크 계열)
카드사(이슈어)	카드 발급, 한도 관리	Visa·Mastercard·JCB 등
수납대행사	PG API 밖의 결제 수단(편의점) 실물 수납 대행	이코넥스트
결제 수단별 심사	수단마다 별도 가맹점 심사	카드·PayPay·편의점 각각

체감상 가장 다른 점은 두 가지입니다. 결제 수단마다 심사가 따로 진행된다는 것, 그리고 PG API가 못 미치는 영역(편의점)은 별도 수납대행사가 있다는 것입니다. 로손·미니스탑·세이코마트 세 브랜드는 이코넥스트라는 대행사 심사 하나로 한 번에 지원됩니다. 참고로 SBPS·GMO 같은 로컬 대형 PG사는 일본 법인과 현지 계좌가 있어야 직접 계약할 수 있습니다.

승인과 매입, 기초 개념부터 다시

결제 완료가 곧 즉시 출금을 의미하지는 않는다는 개념을 이번 프로젝트에서 다시 명확히 확인했습니다. 결제 흐름을 설계하려면 이 두 단계를 구분해서 봐야 합니다.

• 승인(Authorization): 카드사가 결제 가능 여부를 확인하고 해당 금액을 홀드하는 단계
• 매입(Capture): 홀드된 금액을 실제로 청구 확정하는 단계 (해당 시점에 출금)

결제 요청 → 승인(홀드) → 매입 요청 → 매입(출금 확정) → 정산

핵심은 이 승인과 매입 사이에 시차를 둘 수 있고, 그 시점을 정책에 따라 직접 설계할 수 있다는 점입니다. 저희는 카드 지정매입을 배송 이벤트로 트리거하도록 설계했습니다. 배송이 시작되는 시점에 매입을 확정하는 구조인데, 이렇게 맞춰두면 배송 전 취소는 아직 매입되지 않은 상태이므로 승인만 무효화하면 끝나고, 정식 환불 절차를 거칠 필요가 없습니다.

이 구조를 짜려면 승인/매입 시점을 정확히 알아야 배송 상태와 결제 상태를 맞물릴 수 있었습니다. 승인과 매입을 분리해서 본다는 것 자체는 단순한 개념이지만, 이걸 배송 이벤트와 연결하는 순간 정책 설계 전체의 기준점이 된다는 걸 이번에 좀 더 명확하게 인지하고 배웠습니다.

한국엔 없는 결제 수단, 편의점 결제

저희 MVP 결제 수단(신용카드, PayPay, 편의점)에 낯선 게 하나 있었습니다. 편의점 결제입니다.

1. 온라인 주문 시 편의점 결제 선택 → 결제 번호 발급
2. 고객이 편의점 카운터에서 현금 납부 → 결제 완료

일본은 현금 결제 비중이 여전히 높고 카드가 없는 고객층도 있어 이 방식이 자리잡았습니다. 편의점 결제는 기획 전반에 파장을 일으켰습니다.

• 주문 상태 증가: 입금 대기 → 결제 완료 → 납부 기한 초과 상태값을 새로 정의
• 입금 기한: 미납 시 자동 취소, 안내 문구와 처리 정책 별도 필요
• 미입금 취소는 환불이 아님: 들어온 돈이 없으므로 주문 무효화 로직 별도 필요
• 환불이 가장 까다로움: 환불 API가 없어 계좌 정보를 수집해 직접 송금해야 함. 접수 → 백오피스 입력 → 뱅킹 송금 → 완료 처리의 4단계를 설계했습니다.

카드 브랜드 룰과 정책의 영향

정책정의서까지 정리해 둔 시점에 SBPS로부터 “카드 브랜드 룰 개정으로 부분 매입·부분 환불이 폐지되고, 금액변경요구 방식으로 대응해야 한다”는 연락을 받았습니다. Visa·Mastercard·JCB 같은 카드 브랜드는 룰을 주기적으로 업데이트하고 이게 언제 바뀔지는 예측할 수 없습니다.

매입 전후 분기로 짜둔 정책을 전면 재설계해야 했습니다. PG 연동에서 정책은 “한 번 정하면 끝”이 아니고 PG사와 정기적으로 소통하며 공지를 놓치지 않는 것 자체가 PM의 역할이라는 걸 다시 한번 확인했습니다.

환불 정책, 상품 선택만으로는 부족했다

처음 설계는 상품 선택 여부로 자동 분기하는 방식이었습니다. 상품을 선택하면 부분 환불(주문 상세 단위로 처리), 선택하지 않으면 금액만 환불(상품 목록은 건드리지 않고 금액만 차감)로 처리됐습니다. 이때는 “전체 환불”이라는 유형 자체가 따로 없었습니다.

문제는 “상품을 선택하지 않은” 요청이 실제로는 서로 다른 두 의도를 담고 있었다는 점입니다. 정말 주문 전체를 취소하려는 경우도, 단순히 일부 금액만 조정하려는 경우도 시스템 입장에서는 똑같이 “상품 미선택”으로 들어왔고, 그래서 둘 다 금액만 환불로 처리됐습니다. 금액만 환불은 주문 전체 금액만 바꾸고 상품별 항목은 그대로 남겨두는 방식이라, 정말 전체 취소를 의도한 주문도 상품 항목은 취소되지 않은 채로 남았습니다. 그 결과 주문 전체 취소 금액과 상품별 취소 금액 합계가 서로 어긋나는 상황이 생겼고, 배송·재고 처리 로직에서는 이 주문이 여전히 살아있는 것으로 인식되는 문제가 있었습니다.

그래서 “전체 환불”이라는 유형을 새로 추가하고, 전체/부분/금액만 환불 세 가지를 UI에서 라디오버튼으로 명시적으로 선택하게 바꿨습니다. 유형별로 호출되는 API도 분리해서, 이번 요청이 어떤 성격인지 시스템이 처음부터 알 수 있게 했습니다. 여기에 배송 상태별 처리 정책, 에러 코드 12종 매핑까지 더해졌습니다.

편의점 환불에는 본인 확인 절차(이메일·성명 자동 대조 + 예금주명 운영자 체크)를 추가했습니다. 수동 송금 구조라 확인이 잘못되면 엉뚱한 계좌로 돈이 나가는 리스크가 있기 때문입니다. 주문 상세에는 변경 이력 탭도 별도로 설계해 환불 분쟁 시 “언제·어떤 상태로·어느 계좌로” 처리했는지 추적할 수 있게 했습니다.

PG사와의 소통, 정책과 개발 사이의 간극

SBPS 담당자와는 한국어→일본어 번역 슬랙 메시지로 소통합니다. 번역보다 어려운 건 응답 속도였습니다(기본 답변만 몇 시간, 조치는 며칠). 결국 저희 쪽에서 빠르게 대응하고 꼼꼼히 파악해 왕복 횟수를 줄이는 수밖에 없었습니다.

더 큰 어려움은 정책 문서와 실제 개발의 간극이었습니다. 스펙을 읽고 정책을 정리해도 실제 API 동작이 다른 경우가 반복됐고 그때마다 아래 루프를 결제 수단별로 돌렸습니다.

정책 파악 → 기획/설계 → 개발 중 동작 확인 → 예상과 다른 동작 발견 → PG사 재확인 → 정책 수정 → 재설계

정책은 가정이 아니라 실제 스펙·코드 기반으로 확정하고 확인 안 된 건 PENDING으로 명시해두는 태도가 결제 도메인에서는 특히 중요했습니다.

마치며

결제는 버튼 하나로 끝나는 것처럼 보이지만 그 뒤엔 승인·매입·환불·심사·법규까지 정의해야 할 게 쌓여 있고 해외 결제는 여기에 현지 법규·생태계·커뮤니케이션이라는 레이어가 하나 더 붙는다는 걸 배웠습니다.

해외 PG 연동을 준비하고 있는 분들께 조금이라도 도움이 됐으면 합니다.

긴 글 읽어주셔서 감사합니다.