결제 연동할 때, 이런 의문 가져보신 적 없으세요? 결제창을 띄워서 결제 요청에 성공했는데, 여기서 끝난 게 아니라 ‘승인 요청’까지 해야 결제 완료라고 하네요. 결제 요청과 승인은 어떻게 다르고, 왜 따로 처리해줘야 하는 걸까요?
결제 요청 과정 쪼개보기: 요청-인증-승인
PG사 입장에서 결제 요청은 구매자가 사려는 상품 정보, 구매자 정보 등을 전달해 결제창을 띄우고 이 정보를 제출하는 과정까지에요. 토스페이먼츠 결제창으로 생각해보면, 카드사를 선택하고 ”다음” 버튼을 선택해 카드사 창이 뜰 때 결제 요청이 된다고 볼 수 있죠.
요청 후에는 두 가지 과정이 차례로 진행되어야 하는데요. 카드사의 결제 인증 처리, 그리고 가맹점의 결제 승인 요청이에요. 각 단계에 대해 자세히 알아볼게요.
1-1. 결제 요청
구매자 & 가맹점 Client
구매자가 상품 또는 서비스를 구매하기 위해 결제를 요청하는 과정입니다. 띄워진 결제창에는 주문서에 이미 입력된 결제 요청 정보(상품 정보, 결제 금액 등)가 토스페이먼츠 결제창에 전달되어 보이네요. 구매자는 결제 수단(예: 삼성카드, 애플페이 등)을 선택하는 등 결제 정보를 추가합니다.
1-2. 결제 요청에 대한 인증
카드사
이제 요청된 결제에 대한 인증을 해야해요. 인증은 카드 회사가 고객의 신용카드 정보와 결제 금액을 확인해서 이 거래가 유효하며 결제를 허용해도 되는지 확인하는 과정이에요. 덕분에 카드 회사는 구매자와 가맹점을 둘 다 보호하고, 부정거래나 사기 등을 방지할 수 있습니다.
인증은 구매자가 선택한 결제 수단, 즉 카드사에서 진행합니다. 카드 결제를 할 때 카드 번호, 만료일, CVC 등의 정보를 입력하고 카드 발급사에서 발급한 OTP(One-Time Password) 등의 인증 정보를 입력해 본 적이 있을 거에요. 요즘은 앱카드로 편리하게 인증하죠. 이런 창이 나오면 바로 인증 과정의 시작이에요.
인증을 성공적으로 마쳤다면 토스페이먼츠에서 가맹점이 설정한 성공 URL로 리다이렉트 시켜줍니다. 결제 승인에 필요한 파라미터가 아래 예시 화면처럼 성공 리다이렉트 URL에 포함되어 있습니다. 이 파라미터를 가지고 개발자가 할 일이 생깁니다.
이렇게 결제 요청을 마치면 구매자 입장에서는 모든 과정이 끝난 것처럼 보여요. 하지만 개발자 입장에서 요청만 마친 거에요. 실제로 구매자의 결제를 마무리 하려면 아직 할 일이 남아있어요.
2. 결제 승인
가맹점 Server
바로 인증된 결제를 카드사에 승인해달라고 요청하는 과정인데요. 승인이 성공해야 가맹점은 구매자에게 상품이나 서비스를 제공하고, 카드사나 은행은 결제 금액을 구매자에게 청구하기 때문에 실제로 결제가 마무리 되는 단계라고 볼 수 있죠.
토스페이먼츠에서 제공하는 결제 승인 API를 사용한다고 가정해볼게요. 결제 요청-인증 뒤에 이동한 성공 리다이렉트 URL의 쿼리 파라미터로 받은 정보를 이용해 승인 API를 호출해요. 실제로 카드사에 결제를 승인해달라는 요청이 가고, 결제 승인 응답이 성공으로 돌아오면 결제가 완료돼요. 구매자와 판매자에게 결제 완료 메시지가 전달되고 개발자는 결제 성공 응답을 확인할 수 있죠.
결제 요청과 승인을 따로 하는 이유
결제 연동 방식에는 이렇게 요청과 승인을 따로 하는 방법 뿐만 아니라 한 번에 하는 방식도 있는데요.
한 번에 처리하는 방식은 결제 요청을 하면 바로 승인 결과까지 받을 수 있어 간편하게 느껴져요. 다만 언제 승인 결과가 돌아올 지 알 수 없기 때문에 가맹점 서버에서 승인 결과를 받으려면 반드시 웹훅을 연동해야 합니다. 그런데 웹훅을 연동했더라도 만약 사용자가 결제창을 닫아 버렸거나, 가맹점 서버에 트래픽이 몰려 웹훅으로 승인 완료 결과를 처리하지 못하는 상황이 생기면 문제가 되겠죠. 웹훅이 여러 번 재전송 되더라도 가맹점 서버가 받아줄 수 있는 상태가 아니면 가맹점에서는 결제 실패로, PG에는 결제 완료 상태로 남아 데이터가 어긋나기 때문이에요. 이렇게 요청-승인을 한 번에 처리하면 승인 데이터 정합성 보장을 위해 가맹점에서 여러 작업을 해야 합니다.
그래서 토스페이먼츠는 결제 요청과 승인을 따로 하는 방식으로 데이터 정합성을 보장하고, 가맹점에서 해야 할 일을 줄이고자 했습니다. 요청-승인을 따로 하면 위와 같이 결제창을 닫아버리거나 가맹점 서버 이슈 때문에 승인 데이터 정합성에 문제가 생길 가능성은 거의 없어요. 결제 요청 후 가맹점이 승인을 요청하는 과정은 추가되지만 성공 리다이렉트 URL을 보내주니 서버에서 계속 응답 결과를 확인할 필요도 없고요. 토스페이먼츠 서버에서 리다이렉트 URL로 돌려준 정보를 가맹점에서 직접 받아 그 정보로 승인을 요청하기 때문이예요.
포트원, 부트페이 같이 다양한 PG사와 계약하여 각 PG사에서 제공하는 결제 수단들을 일괄적으로 제공해주는 국내 서비스들은 사실상 PG사의 가맹점 역할을 해요. 따라서 가맹점 개발자가 해야 하는 결제 인증 결과 처리 로직이나 결제 정보 검증을 내부적으로 구현한 서비스를 제공할 수 있습니다. 그래서 가맹점에서는 직접 인증 결과를 처리하는 단계가 없는 것처럼 느껴질 수 있죠. 이 부분을 구현해주는 역할을 서비스가 대신하기 때문이지 실제 로직이 없는 것은 아닙니다.
직접 결제 정보 검증하기
토스페이먼츠를 사용할 때 요청과 승인 과정 사이에서 직접 결제 정보 검증을 구현하는 흐름을 알려드릴게요.
결제 요청 전에: 결제할 데이터 저장하기
구매자의 결제 정보는 결제 요청 전에 저장해야 합니다. 결제 요청 전후의 데이터가 바뀌지 않았는지 확인하기 위함이에요. 또, 주문서 페이지에서 적립금이나 쿠폰이 적용된 최종 결제 금액을 서버에 저장하는 등의 작업도 필요합니다. 구매자에게 적립금이나 쿠폰이 없는데 요청과 승인 사이에 적립금을 사용한다고 악의적으로 수정할 수 있기 때문이죠. 아래 과정을 따라해보세요.
- 구매자가 주문서에서 “결제하기” 버튼을 클릭해 결제를 요청합니다.
- 주문서에 있던 결제 정보를 서버에 임시로 저장해주세요.
- 결제 정보가 잘 저장되었다면 결제를 요청하세요.
결제 승인 전에: 승인할 데이터 검증
결제 요청, 인증에 성공했다면 승인 요청을 하기 전에 정보를 검증해요. 위에서 요청할 때 저장해 둔 금액과 요청 결과로 돌아온 결제 금액과 값이 같은지 검증하는 방식입니다. 클라이언트에서 결제 금액을 조작해 승인하는 행위를 방지할 수 있어요.
- 결제 인증이 완료되면 성공 리다이렉트 URL에 들어온 값을 확인합니다.
- 주문 ID로 결제 요청 전에 저장해 둔 임시 정보를 불러옵니다.
- 적립금 및 쿠폰을 사용할 수 있는지, 적립금과 쿠폰을 적용한 최종 결제 금액이 토스페이먼츠에서 돌아온 성공 리다이렉트 URL을 통해 받은 값과 같은지 확인해보세요.
- 문제가 없다면 돌아온 데이터를 사용해서 결제 승인을 요청하세요.
토스페이먼츠 Twitter를 팔로우하시면 더욱 빠르게 블로그 업데이트 소식을 만나보실 수 있어요.
