빌링키 기반 정기결제의 기본 구조

정기결제(자동결제)를 구현하는 핵심 개념은 빌링키입니다. 빌링키는 발급한 PG사 내에서만 유효하며, PG사마다 규격과 관리 방식이 다릅니다. 카드 자동 결제는 카드 유효정보를 보내 빌링키를 취득한 후, 원하는 결제 시점에 API로 빌링키와 결제금액을 보내 결제하는 방식으로 작동합니다. 즉 한 번 빌링키를 발급받아두면, 이후에는 카드 정보를 다시 요구하지 않고도 그 빌링키만으로 반복적인 과금이 가능해집니다.

클라이언트와 서버사이드의 역할 분리

정기결제 흐름에서 빌링키 발급 과정만 클라이언트 작업이 필요하며, 해당 빌링키로 결제를 요청·예약·취소하는 작업은 서버사이드에서 이루어집니다. 이 구조를 이해하는 것이 인프라 설계의 출발점입니다 — 유저가 앱이나 웹에서 카드 정보를 입력하는 순간은 딱 한 번(또는 카드를 변경할 때)이고, 그 이후의 매달 자동 과금은 사람이 개입하지 않고 서버의 스케줄러가 주기적으로 빌링키를 호출하는 방식으로 처리됩니다. 이 자동화 로직을 설계할 때는 결제 시점을 언제로 잡을지(가입일 기준 매월 같은 날), 실패 시 재시도를 몇 번·며칠 간격으로 할지 등을 사전에 정책으로 확정해두어야 합니다.

왜 카드정보가 가맹점 서버를 거치지 않아야 하는가

PG사가 제공하는 일반 결제창에 고객이 카드정보를 입력하여 빌링키를 발급받는 방식에서는, 카드정보가 서버를 거치지 않고 직접 PG사로 전달되기 때문에 보안상 이점이 있습니다. 가맹점(서비스 운영사) 서버가 카드번호 원본을 직접 다루지 않는 구조는 PCI-DSS 같은 카드 정보 보안 규정 준수 부담을 크게 줄여줍니다. 자체적으로 카드 입력 UI를 만들어 카드번호를 서버로 전송받는 방식은 보안 인증 부담이 훨씬 커지므로, 특별한 이유가 없다면 PG사가 제공하는 표준 결제창을 그대로 활용하는 것이 실무적으로 안전합니다.

PG사 선정 시 고려해야 할 전환 비용

빌링키가 PG사 종속적이라, PG사를 교체하면 기존 고객의 빌링키를 그대로 이전할 수 없어 전 고객에게 카드 재등록을 요청해야 하는 경우가 많습니다. 이는 구독 서비스 특성상 매우 치명적인 문제가 될 수 있습니다 — PG사를 바꾸는 순간 기존 구독자 상당수가 카드를 다시 등록하는 번거로움 때문에 이탈할 위험이 있기 때문입니다. 이런 이유로 PG사 선정은 단순히 수수료율만 비교할 것이 아니라, 장기적으로 이 PG사를 계속 쓸 수 있는지(안정성, 지원 범위, 확장성)까지 함께 고려해 신중하게 결정해야 합니다.

API 연동 시 확인해야 할 데이터 요건

정기결제 API를 연동할 때는 빌링키 발급, 반복결제 등록, 즉시결제 요청, 결제 취소 같은 기본 기능 외에도, 결제 실패 시 콜백으로 전달되는 실패 사유 코드, 결제 성공·실패 알림을 받는 웹훅(Webhook) 설정, 구독 상태(활성·일시정지·해지) 변경 이력을 저장할 데이터 구조까지 미리 설계해야 합니다. 구체적인 데이터 요건은 각 PG사별로 상이하므로, 연동하려는 PG사의 개발자 문서를 직접 참조해 정확한 API 명세를 확인하는 절차가 필수입니다.

정기결제 시스템 설계에서 놓치기 쉬운 시나리오

결제 성공 시나리오만 설계하고 실패·예외 시나리오를 소홀히 하면 나중에 큰 장애로 이어질 수 있습니다. 카드가 만료됐거나 한도가 초과된 경우의 재시도 정책, 여러 번 재시도해도 실패하면 구독을 자동으로 일시정지할지 여부, 결제 실패를 유저에게 어떻게 알릴지(레슨 6에서 다룰 해지 방어와도 연결됨) 같은 예외 상황을 사전에 설계해두지 않으면, 실제 운영 중 결제 실패가 발생했을 때 대응이 뒤늦어질 수 있습니다.

특약 조건이란 무엇이고 왜 확인해야 하는가

정기결제를 취급하려면 PG사와 일반 결제 계약 외에 '정기결제 특약' 또는 이에 준하는 별도 심사·계약을 거치는 경우가 대부분입니다. 이는 정기결제가 일회성 결제보다 소비자 분쟁(부당 청구, 해지 거부 민원)의 소지가 크기 때문에, PG사가 가맹점의 서비스 내용·해지 절차·환불 정책을 심사한 뒤에만 정기결제 기능을 활성화해주는 경우가 많습니다. 이 심사 과정에서 서비스 약관, 해지 방법 안내 페이지, 가격 정책 등을 제출해야 할 수 있으므로, 정기결제 인프라 개발과 별도로 이 심사 절차의 소요 기간을 프로젝트 일정에 미리 반영해야 합니다.

여러 PG사를 함께 쓰는 멀티 PG 전략

서비스 규모가 커지면 하나의 PG사에만 의존하는 대신, 여러 PG사를 함께 연동해 장애 발생 시 다른 PG사로 자동 전환하거나 결제수단별로 유리한 PG사를 선택하는 멀티 PG 전략을 고려하는 경우가 있습니다. 다만 이 전략은 앞서 다룬 PG사 종속적 빌링키 문제를 그대로 안고 있어, 여러 PG사의 빌링키를 유저 계정과 함께 관리하는 복잡한 데이터 구조가 필요합니다. 초기 단계의 서비스라면 하나의 안정적인 PG사로 시작하고, 결제 실패율이나 트래픽 규모가 실제로 멀티 PG를 정당화할 만큼 커졌을 때 확장을 검토하는 것이 현실적인 접근입니다.