카카오페이 저장결제 등록부터 환불까지 연결하기

카카오페이 저장결제를 추가할 때는 이미 운영하던 일회성 결제 연동을 기반으로 작업했습니다. 저장결제용 등록 기능과 데이터를 추가하고, 저장된 결제수단으로 결제한 건의 환불과 해지까지 연결해야 했습니다.

여기서 말하는 카카오페이 서비스는 카카오페이 자체가 아니라 당시 Nike 결제 시스템에서 운영한 연동 서비스입니다.

정기결제 API를 저장결제에 활용한 배경

카카오페이의 연동 용어에는 정기결제와 subscription이 사용됐지만, 우리가 필요했던 기능은 고객이 등록한 결제수단을 이후 구매에서도 다시 사용하는 저장결제였습니다. 매월 정해진 날짜에 청구하는 기능만을 뜻하지는 않았습니다.

이 용도로 사용할 수 있는지는 법무팀 검토와 벤더 확인을 거쳐 진행했습니다. API 이름만 보고 임의로 사용 범위를 정한 것은 아니었습니다. 당시 서비스에서 요구한 사용 방식과 벤더가 제공하는 연동 기능을 맞춰 봐야 했습니다.

등록 식별자와 결제 건의 구분

등록 이후의 결제에는 SID를 사용합니다. 개별 결제에는 TID가 있어, 결제수단의 등록 정보와 실제로 결제된 거래를 구분해야 합니다. 현재 카카오페이 공식 문서 에서도 SID를 발급받는 과정과 이후 결제 요청을 나눠 설명합니다.

환불은 등록된 결제수단 자체가 아니라 특정 결제 건을 취소하는 처리입니다. 따라서 SID만 저장하는 것으로 끝낼 수 없고, 내부 주문과 거래 식별자의 관계도 유지해야 합니다. 결제 취소 요청은 TID에 해당하는 거래를 기준 으로 이뤄집니다.

연동 서비스와 워커의 동시 변경

먼저 정기결제 기능과 저장결제 데이터를 추가하고, 이후 환불과 해지 경로를 연결했습니다. 결제 승인과 후속 처리를 담당하는 워커에도 변경이 필요했습니다. 연동 서비스에서 새 데이터를 만들어도 워커가 다른 식별자를 참조하면 다음 처리를 이어갈 수 없기 때문입니다.

등록 단계에서 저장할 값과 승인 요청에 전달할 값, 환불 시 찾을 거래 정보를 각 서비스가 같은 의미로 사용하도록 맞췄습니다. 등록 API 하나를 추가하는 작업보다 수정과 확인 범위가 넓었습니다.

구현보다 오래 걸린 채널 검증

백엔드 구현 이후에는 화면 반영과 UAT가 이어졌습니다. Nike.com과 SNKRS의 웹·앱을 확인해야 했고, PC와 모바일 웹, Android와 iOS에서도 동작을 봐야 했습니다. 등록 화면이 열리는 것 외에 인증 이후 복귀와 결제 재사용까지 확인해야 했습니다.

프론트엔드도 웹, 모바일 웹, Android, iOS 팀으로 나뉘어 있었고 미국 조직과 함께 일했습니다. 한 환경에서 수정이 끝나도 다른 팀의 화면 반영과 검증 일정이 남아 있었습니다. 일부 OS나 환경에서만 동작하지 않는 경우도 있어 공통 API가 정상이라는 확인만으로 출시 준비를 끝낼 수 없었습니다.

미국 팀의 테스트 환경 제약

국내 간편결제를 검증하려면 한국 계정과 사용 환경이 필요한 경우가 있었습니다. 미국 팀이 직접 재현하기 어려운 구간에서는 API 명세를 바탕으로 먼저 화면과 처리를 구현하고, 실제 결제 검증을 이어갔습니다.

그만큼 요청과 응답의 의미를 정확하게 맞추는 일이 중요했습니다. 백엔드 기능을 만드는 시간보다 각 팀과 테스트 조건을 맞추고 출시를 준비하는 시간이 더 길게 느껴졌습니다.

다음 글에서는 카카오페이와 Fiserv를 함께 지원하며 저장결제 등록 API 명세를 정리한 과정을 다룹니다.