일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 레디스 동시성
- spring event
- gRPC
- 셀러리
- 완전탐색
- 알람 시스템
- 좋은 코드 나쁜 코드
- AWS
- 구현
- docker
- prg 패턴
- jwt 표준
- 결제서비스
- 누적합
- 수신자 대상 다르게
- piplining
- 디버깅
- 깊게 생각해보기
- BFS
- branch 전략
- 프로그래머스
- 백준
- 객체지향패러다임
- 트랜잭샨
- 숫자 블록
- 카카오
- 이분탐색
- 검색어 추천
- 쿠키
- 코드 계약
- Today
- Total
코딩관계론
결제서비스 - Checkout 서비스 구현 [#50] 본문
서론
이 글에서는 쿠팡의 결제 서비스에서 Checkout 프로세스를 어떻게 처리하고 있는지 분석하고, 특히 Checkout ID의 보안 및 관리에 대해 논의하고자 합니다. Checkout ID는 결제 프로세스의 핵심 요소로, 올바르게 관리되지 않으면 보안 취약점이 발생할 수 있습니다. 따라서 이 글에서는 Checkout ID의 생성, 저장, 그리고 만료 처리 방법에 대해 심도 있게 다루고자 합니다.
Checkout Response 분석
이 Response에서 주목할 부분은 checkoutId와 checkoutUrl입니다. 이들이 외부에 노출되거나 변조될 경우, 결제 과정에 보안 문제가 발생할 수 있습니다. 따라서 쿠팡에서는 어떻게 이러한 문제를 해결했는지에 대해서 알아보겠습니다.
https://checkout.coupang.com/order
{
"success": true,
"resultTypeCode": "SUCCESS",
"data": {
"status": "GOOD",
"code": 0,
"object": {
"paymentToken": "8a24d9ce61ad41cf9309c61e0888133a",
"payServiceId": "COUPANG",
"orderId": 8100067101369,
"checkoutId": "1725209996060",
"payType": "ROCKET_CARD",
"successReturnUrl": "https://checkout.coupang.com/paymentResult?checkoutId=1725209996060&thankYouPageUrl=https%3A%2F%2Fmc.coupang.com%2Fdesktop%2Fthank-you%3ForderId%3D8100067101369%26price%3D34200%26retailPrice%3D34200%26payType%3DROCKET_CARD%26checkoutId%3D1725209996060%26hasCoupangGlobal%3Dfalse%26agentType%3DWEB%26isDirectOrder%3Dfalse%26checkoutType%3DDEFAULT",
"failReturnUrl": "https://checkout.coupang.com/paymentResult?checkoutId=1725209996060",
"checkoutUrl": "https://checkout.coupang.com/cart/checkout/1725209996060?paymentFailed=true",
}
}
}
Checkout ID의 변조에 대한 대응 방안
Checkout ID를 변조하여 결제 요청을 시도할 경우, 쿠팡 서버는 유효하지 않은 checkoutId에 대해 500 Internal Server Error를 반환하고, 사용자를 홈 페이지로 리다이렉션 합니다. 이는 변조된 checkout ID에 대한 접근을 차단하기 위한 기본적인 보안 메커니즘입니다.
다만, 정말 해당 Checkout ID가 없어서 그런지는 추가적으로 확인이 필요합니다. 그 이유는 보통 권한이 없으면 403으로 응답을 하기 때문입니다.
다중 Checkout ID 생성 시의 처리
사용자가 여러 개의 Checkout ID를 생성할 수 있는 상황, 예를 들어 다중 장바구니 생성 후 각각의 결제를 시도하는 경우, 각 결제 프로세스마다 고유한 Checkout ID가 부여됩니다. 쿠팡에서는 각 결제 흐름을 독립적으로 관리하여, 동시에 여러 결제 프로세스가 충돌하지 않도록 보장합니다.
아래의 그림에서 "필터월드", "오브젝트" 책을 각각 구매하게 되면 다른 Checkout ID가 부여됩니다.
Checkout ID는 어디에 저장하는 것이 맞을까?
Checkout ID는 전역적으로 고유해야 하며, 결제 관리를 위한 중요한 필드임으로 다음과 같은 두 가지 이유로 데이터베이스에 저장하는 것이 맞습니다.
- 레디스는 휘발성이기 때문에 서버가 꺼지게 된다면 고객의 신뢰를 잃어버리게 된다
- 전역성을 보장하기 위해서는 데이터베이스 접근이 필수이다.
따라서 최종적인 순서도는 다음과 같습니다.
Checkout ID 삭제 전략
Checkout ID는 결제 프로세스에서 중요한 역할을 합니다. 적절한 시점에 이를 삭제하지 않으면, 불필요한 데이터가 축적되거나 보안 취약점이 발생할 수 있습니다.
1. Order의 시작 여부 기반 삭제
Order가 생성된 후 결제 프로세스가 시작되지 않은 상태라면, 일정 시간이 지난 후 Checkout ID를 삭제할 수 있습니다. 예를 들어, Order가 생성된 후 24시간이 경과했지만 "Not Started" 상태라면, 해당 Checkout ID를 안전하게 삭제할 수 있습니다
'개발 > Hot-Stock' 카테고리의 다른 글
메시지 발행과 데이터베이스의 트랜잭션을 어떻게 원자적으로 처리할까? (Transactional Outbox Pattern) (0) | 2024.09.10 |
---|---|
결제서비스 - 결제 승인 시스템 구조와 Retry 전략[#52] (0) | 2024.09.03 |
결제 서비스 개발기 (0) | 2024.09.02 |
Spring Interceptor를 이용한 JWT 개발 - 2탄 (0) | 2024.08.05 |
JWT를 사용한 인증 개발기 (0) | 2024.08.05 |