2026.01.02, 01.07 결제 관련 글 찾아 읽기

결제 아키텍쳐

 

웹훅에 대해

https://medium.com/@sohail_saifii/handling-payment-webhooks-reliably-idempotency-retries-validation-69b762720bf5

 

웹훅이 다운되는 경우도 있다. 웹훅이 만능은 아니다. 다만 폴링을 보완책으로 사용할 수 있다

1. 웹훅을 사용하지 않는다
2. 웹훅이 1시간 동안 동작하지 않았다. -> 알림
   폴링을 사용

여기서도 폴링과 웹훅을 언급

웹훅 vs 폴링
웹훅 대신 Stripe API를 폴링해야 하는 경우는 언제일까요?
웹훅을 다음 용도로 사용하세요:
* 백그라운드 이벤트(구독 갱신)
* 긴급 업데이트 (결제 실패)
* 예측할 수 없는 사건들(분쟁)
폴링을 사용하는 경우:
* 사용자 활동 직후 결제 상태 확인 -> 이걸 없애야
* 실행 전 핵심 작업 검증
* 웹훅 사용이 어려운 개발/테스트 환경
결합 접근법의 예:

 

+ 다른 방법으로..

딜레이 큐를 사용하는 방법도 있을 수 있겠다.

PG연동 전이나 후에 moid 기반으로 몇분뒤에 상태를 확인하는 것이다. 

 

콜백에 비즈니스 로직을 넣지마라

Stop Doing Business Logic in Webhook Endpoints. I Don't Care What Your Lead Engineer Says.

 

1. 보니, 콜백에서 비즈니스를 동기에서 처리하지 않고, 비동기로 처리하겠다는 이야기
   1. 동기는 문제가 있다. DB문제, 각종 서드파티 문제
   2. 비동기의 실패는 우리가 알아서 재시도하겠다.
   3. 수신과 처리를 혼동하지말라
2. 생각해보면. 콜백이 기본 처리(비동기), 콜백이 안오는 것은 프로세서가 확인 혹은 처리
   웹훅으로 인한 문제 상황을 언급
3. 권장 사례 (블로그에도 있음)
   1. stripe[https://docs.stripe.com/webhooks#handle-events-asynchronously]
   2. 웹훅 블로그 [https://docs.webhook.site/]
      
      
      

1주차:
1,200건의 결제
47개의 중복 웹훅 수신
12건의 중복 결제가 처리되었습니다.
8명의 고객에게 두 번씩 요금이 부과되었습니다.
환불 처리에 3시간 소요
2주차:
이메일 서비스에 일시적인 문제가 발생했습니다 (10분간 접속이 불가능했습니다).
해당 기간 동안 웹훅 타임아웃이 200건 이상 발생했습니다.
제공업체는 모든 시도를 다시 수행했습니다.
800개 이상의 중복 웹훅 영수증
데이터베이스가 폭주했어요
사이트가 20분간 다운됐습니다.
청소에 6시간 소요
4주차:
분석 서비스 유지 관리
이벤트를 추적할 수 없습니다
공급자에게 오류 반환을 시작합니다
그들은 웹훅 전송을 중단합니다.
50회 납부를 놓쳤습니다.
고객 지원 폭발적 증가
CEO가 불만스러워함
8주차:
SMS 전송량 제한에 걸렸습니다.
4주차와 동일한 패턴입니다.
또 30건의 납부 기한이 연체되었습니다.

 

 

🧩 절대 오류가 발생하지 않는 결제 및 주문 시스템 설계: 실용적인 아키텍처

https://medium.com/@sahilrohera10/designing-a-payment-order-system-that-never-fails-a-practical-architecture-544c1c5532ff

• 지금 계획하고 있는 것과 대부분 비슷하다. 웹훅을 사용한다는것 빼고
• 보면, 웹훅과 폴링을 동시에 사용한다. 폴링이 백업 방안이다. 웹훅에 완벽 통제하에 놓이는 것은 안좋다. 통제를 외부에 넘기는 것이기 때문.
• 여기서도 인증단계에서 주문을 만드는 행위를 한다.

아래의 경우가 생길 수 있고, 우리도 생겼었다. 

결제 응답을 서버에서 받기 전에 사용자의 앱종료, 튕기는 것, 

여기서는 장바구니 접속 시 pending상태인 것이 있는지 확인하라고 하네. 흠 

실제 사용자 흐름:

결제 성공
사용자가 리디렉션 없이 앱을 종료합니다
앱이 다시 시작됩니다
백엔드가 다음에 사용자 또는 장바구니를 볼 때 다음과 같은 작업을 수행해야 합니다.

기존 보류 중인 주문을 감지합니다.
결제 상태 조회
성공을 확인하고 주문을 진행하세요.
또는 실패 시 재시도를 허용합니다.
이는 다음을 방지합니다:

이중 지불
중복 주문
갇힌 카트

---

stackoverflow

[아직 덜 읽음 - 이해 X]

안정적인 결제 처리를 위한 아키텍처

Architecture for robust payment processing

 

1. 결제 시스템의 멱등성을 이용해라
2. 혹은 어플리케이션의 멱등성을 도입해라. 플래그를 사용해라
3. 망취소는 사용자 경험에 않좋을 수 있다.
4. ?
5. 이건 웹훅 혹은 망취소 여러개의 방법이 있겠다

 

결제 처리는 성공했지만 데이터베이스 업데이트에 실패했습니다.

Handling successful payment processing but database update failure

 

1. 폴링방식에 대한 언급. 로그를 이용하냐 DB를 이용하나의 차이일 뿐, 행위는 동일하다

---

---

책 요약

설계 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 요약

 

[설계] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 - 11장. 결제 시스템 ✍️(exactly-once 실

 

1. 여기서도 스케줄링을 언급한다. (종결되지 않은 주문을 모니터링하는 스케줄러, 여기서는 알림용)
2. 원장 업데이트 여부를 불리언 컬럼으로 가지고 있다. 음 비동기로 하는 것에 문제는 없겠다. 좋은 관점인 듯. 비동기 실행 여부를 플래그로 관리하는 것인데, 오 괜찮아 보인다. 내가 항상 고민했던, 스프링 내부 이벤트 발행의 보장, 재시도를 어떻게 할 것인가를 답변할 수 있다.
3. 결국 최종으로 조정이라는 단계를 통해 PG사와 결제 정보가 일치하는지 확인해야한다.
4. Timeout 시
   1. 재시도 vs 망취소
   2. 결제 문제 시 지수적 백오프 혹은 망취소할 수 있다.
5. 중복 처리
   1. 클라이언트에서 uuid를 받아서 처리한다.

 

[아직 덜 읽음]

결제 시스템 설계

 

Designing a Payment System

 

여기도 책 요약본

1.  

[아직 덜 읽음]

전자 지갑. 우리는 어떻게 보면 전자 지갑이다.

[설계] 가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 - 12장. 전자 지갑 (분산 트랜잭션 - 2PC

 

1. bnpl라는 용어도 있구나. buy now pay later

---

---

[거의 동일하다. Invoice -> paymentIntent, paymentAttempt -> Transaction]

회복력 있는 전자 결제 시스템. 선결졔와 구독 결제를 설계한다.

Spring Boot로 구축하는 회복력 있는(Resilient) 결제 시스템: 카드 결제부터 정기 결제, 장애 대응까지

 

1. 이건 내 invoice와 거의 비슷한데, 좀 다른 것이 있다.
2. 아마 토스페이먼츠에서 권장하는 방법을 좀 더 디벨롭한 것 같다. 인증 때 order정보를 저장하고, 승인때 금액을 비교하는 것을 보면 말이지.
3. 선결제와 구독은 비슷하네, 이전 상태에 따라 상태 머신을 구현했다. 연체도 이리 구현하면 될 듯.
4. 알림 지표에 대해서.. 결제 승인 API에 대한 모니터링
5. 여기서도 웹훅과 폴링에 대해서 언급한다. 두개 모두 사용하자고 이야기한다. 웹훅은 실시간, 폴링은 전체적은 불일치 찾기
6. 구독에 빌키가 있구나. 이게 맞을 듯하다.

 

 

결제 요청, 인증, 승인… 이게 다 뭔가요?

https://velog.io/@tosspayments/%EA%B2%B0%EC%A0%9C-%EC%9A%94%EC%B2%AD-%EC%9D%B8%EC%A6%9D-%EC%8A%B9%EC%9D%B8-%EC%9D%B4%EA%B2%8C-%EB%8B%A4-%EB%AD%94%EA%B0%80%EC%9A%94

토스 페이먼츠에서 결제 플로우 요약

1. 지식이 없다면 읽어도 좋다.
2. 여기서도 인증 때 미리 결제 금액을 저장하라고 한다.

 

 

[아직 덜 읽음]

레거시 결제 원장을 확장 가능한 시스템으로

레거시 결제 원장을 확장 가능한 시스템으로

 

1. 주문과 결제 수단이 1:1인 것은 기본적으로 생각할 수 있는 구조인데, 더치페이라는 새로운 결제수단, 혹은 카드와 계좌이체를 동시에 할 수 없다고 한다.
2. 처음 설계때 부터 이걸 고려하는 것이 맞는가? 위 구조를 생각하는 것이 맞을지? 혹은 부수기 쉬운 구조를 만드는 것이 맞아보인다.

 

애플리케이션에서 결제 실패 및 재시도 로직을 처리하는 방법

https://medium.com/@mallikarjunpasupuleti/how-to-handle-payment-failures-and-retry-logic-in-your-application-ab878e2d8849

 

1. 결제 실패 컨트롤에 대한 내용
2. 지수적 백오프, 구독의 경우 연체와 결제 재시도등
3.  

---

---

분산 트랜잭션

[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (8) 분산 트랜잭션 환경에서 트랜잭션 처리하기(feat. 2PC, Saga 패턴, Choreographed Saga)

[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (8) 분산 트랜잭션 환경에서 트랜잭션 처리하기(feat. 2PC

 

1. 그냥 분산 tx에 대해서, 

 

REST 기반의 간단한 분산 트랜잭션 구현 - 1편

REST 기반의 간단한 분산 트랜잭션 구현 - 1편 | Popit

 

1. TCC로 제어하는 것. 여기서도 실패에대한 것을 메시징 큐로 컨트롤한다

 

MSA 환경에서 SAGA 패턴으로 안전한 분산 트랜잭션 구현하기

MSA 환경에서 SAGA 패턴으로 안전한 분산 트랜잭션 구현하기

1. 여러 케이스에대한 처리
2. 딜레이 큐도 사용한다

 

토스 SLASH 22 - 토스뱅크의 완전히 새로운 대출 시스템

토스뱅크의 완전히 새로운 대출 시스템

1. 유량제어

 

---

코드

[아직] 원티드 프리온보딩

GitHub - kst6294/wanted-preonboarding-challenge-backend-26

 

견고한 결제 시스템 구축 (Lecture)

견고한 결제 시스템 구축 (Lecture)

 

f-lab에서 설계한 결제 아키텍쳐 코드

https://github.com/f-lab-edu/payment-system

GitHub - f-lab-edu/payment-system: 여러 pg사들과 연동한 결제 시스템

---

외부 연동 

MSA 환경에서 네트워크 예외를 잘 다루는 방법

MSA 환경에서 네트워크 예외를 잘 다루는 방법 | 카카오페이 기술 블로그

 

api 연동 시 성공, 실패, 알 수 없음에 대해 코틀린의 result를 응용해 해결하는 법.

이거에 영감받아서 코드를 작성했음. 근데 모든 api에 result를 사용해야할까 고민중.

 

인프랩 토스페이먼츠

인프랩 CTO가 말하는 결제 개발 A to Z

 

1. PG사는 각기 다른 API 스펙, 올드함
2. 롤백 시나리오.
   1. 지표가 떨어기거나
   2. Qa 때 발견하지 못한 문제

 

외부 api 연동에 대해

외부 조회 API 연동 장애 대응책

 

1. 트랜잭션에서 api분리
2. api별 스레드풀 관리

 

 

카드 부가정보

• 부가정보를 저장해야할까?