토스페이먼츠 결제 연동은 쇼핑몰이나 홈페이지에서 신용카드, 계좌이체, 간편결제 등을 처리할 수 있도록 결제대행사(PG)의 시스템을 웹사이트나 앱에 붙이는 작업을 가리킨다. 이 글은 결제 연동이 왜 필요한지, 어떤 방식들이 있는지, 실제 작업에서 어디서 막히는지를 차례로 정리한다.
온라인에서 물건을 팔거나 서비스 이용료를 받으려면 카드사·은행과 직접 계약을 맺는 대신 결제대행사를 거치는 것이 일반적이다. 결제대행사는 여러 카드사와 은행, 간편결제사와 미리 계약을 맺어 두고, 가맹점에는 하나의 창구만 열어 준다. 그 창구 역할을 하는 것이 결제 연동에서 쓰는 API와 결제창이다. 토스페이먼츠, 카카오페이, 이니시스 같은 국내 서비스와 스트라이프(Stripe) 같은 해외 서비스가 모두 이 역할을 한다.
결제 연동의 기본 구조
결제 연동은 크게 세 단계로 이루어진다. 먼저 가맹점이 결제대행사와 계약을 맺고 심사를 거쳐 가맹점 키를 발급받는다. 다음으로 홈페이지나 앱에 결제창을 띄우는 코드를 넣고, 결제가 끝나면 그 결과를 서버로 전달받아 주문 상태를 바꾸는 로직을 만든다. 마지막으로 결제 취소나 환불, 정기결제 같은 부가 기능을 필요에 따라 추가한다. 결제창 자체는 대행사가 만들어 둔 화면을 그대로 불러오는 방식이 많아서, 카드 번호 같은 민감한 정보가 가맹점 서버를 거치지 않고 바로 대행사 쪽으로 전달되는 구조가 흔하다.
이런 구조를 쓰는 이유는 보안과 책임 문제 때문이다. 카드 정보를 가맹점이 직접 저장하거나 처리하면 지켜야 할 보안 기준이 훨씬 까다로워진다. 결제창 방식을 쓰면 그 부담의 상당 부분을 결제대행사 쪽으로 넘길 수 있다. 그래서 결제 연동 API 문서를 보면 결제창을 띄우는 방법과, 결제 결과를 안전하게 확인하는 방법을 따로 설명해 두는 경우가 많다.
결제 연동 서비스는 한 가지 방식만 있지 않다
결제 연동 서비스를 고를 때는 몇 가지 축으로 나눠 볼 수 있다. 하나는 취급하는 결제수단의 범위다. 신용카드 위주인 곳도 있고, 계좌이체·가상계좌·휴대폰 결제·간편결제를 폭넓게 묶어 제공하는 곳도 있다. 또 하나는 정산 주기와 수수료 체계인데, 이 부분은 업종과 매출 규모에 따라 계약 조건이 달라지므로 특정 숫자를 미리 단정하기 어렵다. 마지막으로 개발 문서와 테스트 환경이 얼마나 잘 갖춰져 있는지도 실무에서는 중요한 차이를 만든다.
국내 PG 서비스들은 대체로 비슷한 큰 흐름을 따르지만 API 형태나 용어는 저마다 다르다. 해외의 경우 스트라이프처럼 여러 나라에서 카드 결제를 처리하는 서비스가 있는데, 이런 해외 서비스는 결제망과 규제 체계가 국내와 다르게 짜여 있다. 국내에서만 서비스하는 쇼핑몰이라면 국내 결제수단을 지원하는 국내 PG를 쓰는 것이 자연스럽고, 해외 결제나 해외 카드 결제 비중이 큰 서비스라면 해외 PG를 함께 검토하게 되는데, 이 경우 정산 통화나 세금 처리 방식까지 국내 제도와는 별도로 확인해야 한다.
실제 연동 과정에서 막히는 지점
결제 연동을 처음 진행할 때 자주 걸리는 부분은 테스트 환경과 실제 운영 환경을 구분하는 지점이다. 대부분의 PG는 개발 단계에서 쓰는 테스트키와 실제 결제가 이루어지는 운영키를 따로 발급하는데, 이 둘을 헷갈려서 테스트 결제가 실제 결제로 이어지거나 반대로 실제 서비스에서 결제가 막히는 실수가 종종 나온다. 또 하나는 결제가 끝난 뒤 그 결과를 서버가 다시 확인하는 절차인데, 결제창에서 성공 화면이 떴다고 해서 곧바로 주문을 확정 처리하면 위험하다. 서버 쪽에서 결제 승인 정보를 다시 조회하거나 대행사가 보내 주는 알림을 받아 최종 확인을 거치는 절차가 함께 필요하다.
쇼핑몰 규모가 크지 않은 경우 직접 API를 처음부터 끝까지 구현하는 대신, 이미 만들어진 쇼핑몰 솔루션이나 웹사이트 제작 도구에 내장된 결제 연동 기능을 쓰는 경우도 많다. 이런 도구는 PG사와의 계약과 키 발급만 가맹점이 직접 진행하고, 나머지 화면 구성이나 결과 처리는 도구가 대신 맡아 주는 구조가 일반적이다. 반대로 결제 흐름을 세밀하게 통제하려는 서비스라면 API를 직접 다루는 방식을 선택하게 된다.
연동 전에 확인해야 할 순서
결제 연동을 준비할 때는 사업자 형태와 판매하는 상품·서비스의 성격부터 정리해 두는 것이 순서에 맞다. 이에 따라 심사 조건이나 필요한 서류가 달라지기 때문이다. 그다음 어떤 결제수단을 제공할지, 정기결제처럼 반복 결제가 필요한지를 정하고, 이를 지원하는 PG 서비스를 비교해 본다. 마지막으로 개발 인력이 직접 API를 다룰 수 있는지, 아니면 완성된 솔루션을 활용할지를 정해야 실제 작업 범위와 일정이 분명해진다. 수수료나 정산 주기 같은 구체적인 조건은 계약 시점의 공식 안내를 통해 확인하는 것이 정확하다.
| 구분 | 확인할 내용 |
|---|---|
| 결제수단 범위 | 카드, 계좌이체, 간편결제, 정기결제 지원 여부 |
| 연동 방식 | 결제창 호출형인지, 직접 API 구현형인지 |
| 환경 구분 | 테스트키와 운영키를 분리해 관리하는지 |
| 결과 확인 | 서버 쪽에서 결제 승인 정보를 재확인하는 절차가 있는지 |
| 대상 범위 | 국내 결제만 다루는지, 해외 결제까지 포함하는지 |
결제 연동은 한 번 붙이고 끝나는 작업이 아니라, 서비스가 커지면서 결제수단이나 정산 조건을 계속 손보게 되는 영역이다. 처음 검토할 때는 지금 당장 필요한 결제수단뿐 아니라 앞으로 늘어날 가능성이 있는 부분까지 함께 살펴보는 것이 좋다. 구체적인 수수료, 심사 기준, 지원 결제수단은 이용하려는 PG사의 공식 홈페이지와 개발 문서에서 최신 안내를 확인하면 된다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.