스프링 결제

김파란·2024년 7월 22일

API

목록 보기
2/2

1. 결제 이해하기

1). PG와 온라인 결제

  • 구매자는 온라인으로 구매할 때 카드, 가상계좌, 상품권등 다양한 결제수단을 사용
  • 상점에서 직접 여러 카드사, 은행 등 결제기관과 계약하고 결제연동을 개발하려면 큰 비용과 시간
  • 이런 번거러움을 해결하기 위해 PG사는 여러 결제기관과 데이터를 안정적으로 주고받을 수 있는 시스템 제공
  • 상점 입장에서는 PG사 한곳만 계약해도 여러 결제기관에서 계약한 효과를 누릴수 있다
  • 우리가 보는 대부분의 온라인 상점은 PG를 통해 구매자에게 결제를 받는다
  • 구매자가 지불한 전체금액에서 PG수수료, 부가세 등 기타 비용을 제외한 정산 금액을 상점에게 전달

(1). 정산프로세스 (토스기준)

  1. 구매고객이 결제하면
  2. 상점에서 PG사에 결제 승인을 요청
  3. PG사는 카드사 등 결제기관에 결제승인 및 대금 지급을 요청
  4. 결제 기관 -> 토스페이먼츠로 지급하는 정산 금액 입금
  5. 토스페이먼츠 -> 상점으로 대금 지급

2). 온라인 결제 과정

  1. 구매자가 결제 요청
  2. 카드사가 결제 정보를 인증
  3. 인증된 결제의 승인을 요청

(1). 카드결제

  • 카드결제는 인증, 승인, 매입순으로 이루어진다
인증
  • 결제할 카드정보와 카드 소유자 정보가 맞는지 확인하는 과정
  • 카드사 인증 창이나 앱카드가 뜨는 시점
  • 카드소유자를 인증해야 결제단계로 넘어갈 수 있다
승인
  • 인증된 카드정보, 고객정보, 주문정보를 가진 결제를 승인하는 단계
  • 인증정보를 가지고 PG사는 VAN을 통해 카드사에 승인을 요청
  • 카드사에서 승인 결과를 전송하면 PG사 -> 상점에게 알려준다
  • 고객입장에서는 결제 영수증이 발급되고 상점으로부터 서비스 또는 상품을 받는다
매입
  • 승인된 결제 정보를 카드사에 알리는 과정
  • 카드번호, 금액, 승인 번호, 할부기간 같은 매입 데이터만 카드사에 넘기면 된다
  • 결제가 승인된 후 PG사에서 상점의 카드 결제 건을 모아 VAN을 거쳐 카드사에 매입을 요청
  • 매입을 안하면 거래가 승인상태에 머물러 있어서 카드사에서 돈을 받을 없다
수동 매입
  • 상점이 카드 결제 대금을 청구하는 세 번째 과정을 매입이라고 하고
  • 매입에 이어지는 네 번째 과정이 정산이다
  • 카드사는 매입 요청을 정산해서 대금을 지급
  • 상점은 매입-정산 과정을 자동으로 할지 수동으로할지 선택할 수 있다
  • 일정기간동안 쌓인 결제 기록 중 특정 건을 상점에서 선택해서 이 결제건만 대금 지급해줘 방식
자동 매입
  • 카드 결제가 승인되면 추가적인 처리 없이 모든 결제 건을 자동으로 매입하는 정산 방식
  • 상점입장에서는 승인과 함께 자동으로 매입과 정산을 요청한 것과 같다

(2). 결제 흐름 이해하기

  1. 결제요청: 구매자는 주문서의 상품정보, 결제 금액을 확인하고 결제하기버튼을 클릭
  2. 구매자 정보 인증: 구매자를 카드 소유자로 인증
  3. 인증 결과 확인: 인증에 성공하면 성공 URL로 리다이렉트, 성공 URL의 쿼리파라미터에는 결제키, 주문번호 등 결제 정보가 있다.
  4. 결제 승인
  • 인증된 결제를 승인해야 결제가 마무리
  • 성공 URL의 쿼리 파라미터값을 토스페이먼츠 결제 승인 API의 요청응답으로 추가하고 API 호출

(3). 결제 요청 전에 결제 정보 검증

  • 구매자의 결제 정보는 결제 요청 전에 저장해야 한다.
  • 결제 요청 전후의 데이터가 바뀌지 않았는지 확인하기 위함
  • 주문서 페이지에서 적립금이나 쿠폰을 적용했다면 최종 결제 금액을 서버에 저장하는 작업도 필요
  • 구매자에게 적립금이나 쿠폰이 없는데 요청과 승인사이에 악의적으로 결제 금액을 수정할 수도 있음
  • orderId(주문번호)와 amount(최종 결제금액)을 클라이언트에서 서버로 보내 임시로 저장
  1. 구매자가 주문서에서 결제하기 버튼을 클릭해 결제를 요청
  2. 주문번호와 최종 결제 금액을 서버 세션이나 데이터베이스에 임시로 저장
  3. 결제 정보가 잘 저장되었다면 결제를 요청

(4). 결제 승인전에 승인할 데이터 검증

  • 승인 요청을 하기전에 정보를 검증,
  • 앞서 요청할 때 저장해둔 정보와 인증결과로 돌아온 정보가 같은지 검증하는 과정
  1. 인증완료시 파라미터에 있는paymentKey,orderId,amount,paymentType를 확인
  2. orderId로 결제 요청 전에 저장해둔 임시 정보를 불러온다
  3. 적립금 및 쿠폰을 적용한 최종 결제금액이 성공 리다이렉트 URL로 받은 금액과 같은지 확인
  4. 문제가 없다면 돌아온 데이터를 사용해 결제 승인을 요청

2. 토스 결제

1). 인증 및 기타 헤더 설정

  • Basic인증에 시크릿을 사용
  • 비밀번호가 없다는걸 알리기 위해 시크릿 키 뒤에 콜론(:)을 추가해야 한다
  • Authorization: Basic (base64(시크릿 키:))

(1). 멱등키 헤더

  • 멱등성은 여러 번 요청하더라도 결과가 달라지지 않는 성질을 뜻함
  • 멱등키를 사용하면 같은 요청을 여러 번 처리되지 않아 안전
  • 요청 본문, URL 쿼리 매개변수, 헤더 중 하나에 멱등키를 포함해서 보내면 된다
  • IETF에서는 헤더에 포함하는 방법을 표준으로 제안하고 있다
  • API 키, API 주소, Http 메서드 종합이 같은 요청이 있는지 확인해서 멱등성을 보장
  • Idempotency-key: [IDEMPOTENCY_KEY]

0개의 댓글