결제 시스템 흐름 정리
회사 플랫폼을 구축하면서 포트원을 이용한 결제 시스템을 도입하고 있습니다. 장바구니에 담겨있는 제품을 결제하는 CSR 과정의 예시가 많지 않았기 때문에 많이 고전했습니다. 반면 SSR의 예시 블로그는 정말 많이 있었습니다.
대한민국 결제 흐름
포트원의 결제 흐름을 이해하기 전에 대한민국의 결제 흐름 이해가 필요합니다. 왜냐하면 대한민국에서는 카드정보를 저장할 수 없도록 규정되어 있습니다. 따라서 카드정보가 가맹점 서버, PG사 서버를 직접 거쳐가지 않도록 구성하고 있습니다.
- 구매자 브라우저 → 카드정보 → 카드사 서버
- 카드사 서버 → 인증결과회신 → 구매자 브라우저
- 구매자 브라우저 → 결제요청 → 가맹점 서버
- 가맹점 서버 → 결제요청 → 계약한 PG사 서버
- PG사 서버 → 결제 승인 요청 → 카드사 서버
- 카드사 서버 → 결제 승인 요청 응답 → PG사
- PG사 → 결제 결과 응답 → 가맹점 서버
- 가맹점 서버 → 결제 요청 결과 → 구매자 브라우저
포트원 결제 흐름
자세한 내용은 포트원의 공식문서를 보면 알 수 있습니다. 아래 2개는 동일한 결제 흐름도 입니다.
2개의 흐름도를 보면 결제를 포트원과 PG사 그리고 카드사에서 처리합니다.
- 포트원 → PG결제요청 → PG
- PG → 카드사결제요청 → 카드사
- 카드사 → 카드사결제결과 → PG
- PG → PG결제결과 → 포트원
최종으로는 가맹점이 결제 내역을 검증하는 역할만 하면 됩니다. 따라서 가맹점은 결제 결과를 받고 사후 검증을 체크하면 되는 것입니다. 만약 사후 검증 후, 통과하면 웹 훅으로 이메일 또는 카카오톡과 같은 수단으로 결제결과를 알릴 수도 있습니다.
- 포트원 → 결제결과(Webhook) → 가맹점(결제창)
Webhook
특정 이벤트가 발생하였을 때 타 서비스나 응용프로그램으로 알림을 보내는 기능입니다. Webhook 프로바이더는 해당 이벤트가 발행하면 HTTP POST 요청을 생성하여 callback URL(endpoint)로 이벤트 정보을 보냅니다.
주기적으로 데이터를 폴링(polling)하지 않고 원하는 이벤트에 대한 정보만 수신할 수 있어서 webhook은 리소스나 통신 측면에서 훨씬 더 효율적입니다. Webhook을 활용하면 커스텀 기능이나 다른 애플리케이션과 연동하여 기능을 확장할 수 있습니다.
포트원에서는 결제 완료 등 이벤트가 발생했을 때 고객사의 서버에 전송하고 있습니다. 이벤트가 발생하면 포트원 콘솔에 등록된 웹훅 URL로 HTTP POST 요청을 보냅니다. 고객사에서는 이 요청을 받아 최신 결제 정보로 동기화하도록 구현해야 합니다.
장점
- 실시간으로 데이터를 전달할 수 있어 효율적입니다.
- 별도의 요청 없이 자동으로 이벤트를 전달받을 수 있습니다.
- API 호출 비용을 절감할 수 있습니다.
단점
- 수신 서버의 신뢰성 : 웹훅을 수신하는 서버가 항상 가동 중이어야 합니다. 그렇지 않으면 데이터가 유실될 수 있습니다.
- 보안 문제 : 웹훅 URL이 노출되면 보안 위험이 발생할 수 있습니다. 이를 방지하기 위해 토큰이나 API 키 같은 보안 인증이 자주 사용됩니다.