[트러블슈팅] 토스페이먼츠 결제 승인 흐름의 안정성 확보

토스페이먼츠 결제 승인 흐름의 안정성 확보

요약
음성 회의록 자동화 및 협업 관리 서비스에서 토스페이먼츠를 연동해 단건 카드 결제로 구독 플랜을 업그레이드하는 기능을 구현했습니다. 초기에는 외부 결제 승인과 내부 상태 변경을 하나의 트랜잭션에서 처리하고 있어, 후속 처리 실패 시 결제사에는 승인이 완료됐지만 내부 DB는 롤백될 수 있는 구조였습니다.

이를 해결하기 위해 외부 승인과 내부 상태 반영의 트랜잭션 경계를 분리하고, 그 과정에서 발생한 중복 승인, 처리 중 상태 정체, 타임아웃의 불명확한 결과, 구독 반영 실패까지 복구 가능한 흐름으로 보완했습니다.

 

목차

1. 문제
2. 해결 과정
   • 01 트랜잭션 경계 분리
   • 02 중복 승인 경쟁 조건 방어
   • 03 선점 후 정체 상태 복구
   • 04 타임아웃의 불명확한 결과 처리
   • 05 구독 반영 실패 회수
3. 검증
4. 남은 한계
5. 정리

 

1. 문제

플랜에 따라 업로드 횟수와 파일 크기를 제한하는 음성 회의록 자동화 및 협업 관리 서비스를 개발했습니다. 토스페이먼츠 결제창을 연동해 단건 카드 결제로 구독 플랜을 업그레이드할 수 있도록 구현했습니다.

 

초기 결제 승인 로직에서는 검증부터 외부 결제 승인, 내부 결제 완료 처리와 구독 업그레이드까지 하나의 @Transactional 안에서 수행하고 있었습니다.

@Transactional
public Payment confirm(String email, PaymentConfirmRequest request) {
    Payment payment = getPayment(request.orderId());

    // 요청 검증
    // ...

    TossPaymentResponse tossResponse = tossPaymentClient.confirm(request);

    payment.complete(tossResponse.paymentKey());
    subscriptionService.upgrade(
            payment.getUser().getId(),
            payment.getPlanType()
    );

    return payment;
}

 

문제는 토스페이먼츠와 내부 DB가 하나의 트랜잭션으로 묶이지 않는다는 점이었습니다. 토스페이먼츠 승인이 완료된 뒤 구독 반영에서 예외가 발생하면 로컬 DB 변경은 롤백되지만 이미 완료된 외부 결제 승인은 되돌아가지 않습니다.

토스페이먼츠 승인 성공
        ↓
내부 결제 완료 처리
        ↓
구독 반영 실패
        ↓
로컬 트랜잭션 롤백

결제사 : 승인 완료
내부 DB : PENDING

 

사용자는 실제 결제를 완료했지만 내부 시스템에는 결제가 반영되지 않을 수 있는 구조였습니다. 따라서 외부 결제 승인과 내부 상태 변경을 하나의 트랜잭션으로 처리하는 대신, 각 단계의 상태를 독립적으로 확정하고 실패 이후에도 복구할 수 있도록 흐름을 재설계했습니다.

---

2. 해결 과정

01 트랜잭션 경계 분리

초기 문제
외부 API 호출과 내부 상태 변경을 하나의 트랜잭션에서 처리하고 있어, 구독 반영 실패 시 로컬 DB는 롤백되지만 결제사 승인은 이미 완료된 상태로 남을 수 있었습니다.

 

대응
검증과 승인 선점, 외부 승인, 결제 확정, 구독 반영의 경계를 분리했습니다. 외부 API 호출은 DB 트랜잭션 밖에서 수행하고, 결제 확정과 구독 반영은 각각 별도의 트랜잭션으로 처리했습니다.

[검증 · 승인 선점]
       TX
        ↓
토스페이먼츠 승인 API
    트랜잭션 없음
        ↓
   [결제 확정]
       TX
        ↓
   [구독 반영]
    독립 TX

 

이 구조에서는 구독 업그레이드가 실패하더라도 이미 확인된 결제 승인 결과는 DONE으로 유지됩니다. 실패한 구독 반영만 별도로 재처리할 수 있습니다.

DB 작업의 트랜잭션 경계를 실제로 분리하기 위해 처리 단계를 별도 Processor 빈으로 분리했고, 구독 반영은 호출 위치와 관계없이 독립적으로 실행되도록 REQUIRES_NEW를 적용했습니다.

 

02 중복 승인 경쟁 조건 방어

파생 문제
트랜잭션을 분리하자 외부 API 호출 중 동일 주문에 대한 다른 요청이 진입할 수 있게 됐습니다. 두 요청이 모두 PENDING 상태를 확인하면 같은 주문에 대한 승인 요청이 중복으로 전송될 수 있습니다.

요청 A : PENDING 확인
요청 B : PENDING 확인

요청 A : 토스 승인 요청
요청 B : 토스 승인 요청  ← 중복 가능

 

대응
애플리케이션에서는 PENDING → PROCESSING 조건부 UPDATE로 하나의 요청만 승인을 선점하도록 했습니다.

@Modifying(clearAutomatically = true, flushAutomatically = true)
@Query("""
    update Payment payment
       set payment.status = ...PaymentStatus.PROCESSING
     where payment.id = :paymentId
       and payment.status = ...PaymentStatus.PENDING
    """)
int markProcessing(@Param("paymentId") Long paymentId);

 

UPDATE된 행이 0개라면 다른 요청이 이미 선점한 상태이므로 토스페이먼츠 API를 호출하지 않습니다.

여기에 서버가 생성한 주문 ID를 Idempotency-Key로 사용해 외부 결제 API에서도 동일 주문에 대한 중복 요청을 한 번 더 방어했습니다.

비관적 락도 검토했지만, 락은 트랜잭션이 끝나면 해제되기 때문에 정작 보호해야 하는 트랜잭션 밖의 외부 API 호출 구간까지 유지할 수 없었습니다. 그래서 상태 자체를 선점의 기준으로 사용하는 조건부 UPDATE를 선택했습니다.

 

03 선점 후 정체 상태 복구

파생 문제
승인 선점 이후 서버가 종료되거나 프로세스가 중단되면 결제가 PROCESSING 상태에 남을 수 있습니다. 이 상태에서는 새로운 승인 요청도 선점 단계에서 차단되므로 결제가 계속 처리 중 상태에 머물게 됩니다.

 

대응
일정 시간 이상 PROCESSING에 머문 결제를 스케줄러가 조회하고, 내부 상태만으로 임의 복구하지 않고 토스페이먼츠의 실제 결제 상태와 대조하도록 했습니다.

정체 결제 발견
        ↓
토스페이먼츠 결제 상태 조회
        ↓
DONE
→ 내부 결제 완료 처리

승인되지 않음
→ PENDING 복구

상태 조회 실패
→ PROCESSING 유지
→ 다음 주기에 다시 확인

결제사의 상태를 확인하지 못한 경우에는 내부 상태를 임의로 변경하지 않고 다음 복구 주기까지 유지하도록 했습니다.

 

04 타임아웃의 불명확한 결과 처리

파생 문제
결제 승인 API가 타임아웃되면 단순히 성공이나 실패로 판단할 수 없습니다. 클라이언트가 응답을 받지 못했더라도 토스페이먼츠에서는 이미 승인이 완료됐을 수 있기 때문입니다.

이 상황에서 바로 PENDING으로 되돌리고 재결제를 허용하면 이미 승인된 결제를 다시 시도할 가능성이 있습니다.

 

대응
결제사가 명확한 실패 응답을 반환한 경우와, 타임아웃·네트워크 오류처럼 결과를 확인할 수 없는 경우를 분리했습니다.

구분	상황	처리
명확한 실패	결제사가 실패 응답 반환	PENDING 복구 후 재시도 허용
결과 불명확	타임아웃 · 네트워크 오류	결제사 상태 조회 후 판단

 

조회 결과가 DONE이면 내부 결제도 완료 처리하고, 승인되지 않은 것이 확인되면 PENDING으로 복구합니다.

결제 상태 조회까지 실패한 경우에는 PROCESSING을 유지하고 앞서 구성한 복구 스케줄러가 다음 주기에 다시 확인하도록 했습니다.

확인할 수 없는 결과를 임의로 성공이나 실패로 확정하지 않는다.

 

05 구독 반영 실패 회수

파생 문제
결제 확정과 구독 반영을 분리하면서 구독 업그레이드가 실패해도 결제는 DONE 상태를 유지할 수 있게 됐습니다. 하지만 사용자 입장에서는 결제가 완료됐는데 유료 플랜이 적용되지 않는 문제가 남습니다.

 

대응
구독 반영 실패 이력을 별도로 기록하고 스케줄러를 통해 재시도하도록 했습니다. 이때 실패 당시의 작업을 그대로 실행하는 대신, 재시도 직전에 현재 결제 상태를 다시 확인했습니다.

구독 반영 실패
        ↓
실패 이력 기록
        ↓
재시도 전 현재 결제 상태 확인
        ↓
DONE
→ 구독 반영 재시도

DONE이 아님
→ 재시도 중단

 

실패 이력이 기록된 이후 결제가 취소됐을 수도 있기 때문입니다. 현재 상태를 확인하지 않고 이전 작업을 그대로 재실행하면 취소된 결제에도 유료 플랜이 적용될 수 있습니다.

따라서 재시도는 단순히 과거의 실패 작업을 반복하는 것이 아니라, 현재도 해당 작업이 유효한지 확인한 뒤 실행하도록 구성했습니다.

---

3. 검증

트랜잭션 경계를 변경한 뒤 실제 결제를 수행해 결제 확정과 구독 반영이 정상적으로 완료되는지 확인했습니다.

결제 상태 : DONE
구독 상태 : PRO / ACTIVE

 

실환경에서 재현하기 어려운 실패 경로는 단위 테스트로 검증했습니다.

• 승인 선점에 실패한 요청이 토스페이먼츠 API를 호출하지 않는지
• 구독 반영에 실패해도 결제가 DONE 상태를 유지하는지
• 타임아웃 이후 결제사 조회 결과가 DONE이면 내부 결제를 확정하는지
• 결제가 승인되지 않은 것으로 확인되면 PENDING으로 복구하는지
• 구독 재시도 시 현재 결제 상태가 DONE이 아니면 재처리하지 않는지

 

주문 ID 기반 멱등키는 실제 동시 요청을 발생시키는 병렬 테스트까지 수행하지 않았기 때문에 실측 결과로 표현하지 않았습니다. 결제사의 멱등성 기능을 활용한 추가 방어 계층으로 적용했습니다.

---

4. 남은 한계

이번 개선으로 결제 승인 과정의 주요 실패 경로와 복구 흐름을 구성했지만, 외부 결제 시스템과 내부 DB의 상태 불일치를 모든 경우에 완전히 제거한 것은 아닙니다.

 

특히 토스페이먼츠에서는 승인이 완료됐지만 내부 결제 확정 트랜잭션 자체가 실패해 결과가 DB에 남지 않는 경우까지 자동으로 복구하려면, 결제사 거래 내역과 내부 DB를 주기적으로 대조하는 Reconciliation 작업이 필요합니다. 이 부분은 이번 구현 범위에는 포함하지 못했습니다.

---

5. 정리

처음에는 외부 결제 승인과 내부 상태 반영을 하나의 트랜잭션에서 처리하면서, 후속 단계의 실패가 이미 완료된 외부 승인과 로컬 DB 사이의 불일치로 이어질 수 있었습니다. 이를 해결하기 위해 트랜잭션 경계를 분리했지만, 외부 호출 구간이 생기면서 중복 승인과 처리 중 상태 정체 같은 새로운 문제가 드러났습니다.

 

이후 조건부 UPDATE와 멱등키로 중복 요청을 방어하고, 정체된 결제는 결제사 상태를 다시 조회해 복구하도록 했습니다. 타임아웃처럼 승인 결과를 알 수 없는 경우에도 실패로 단정하지 않고 실제 결제 상태를 확인한 뒤 후속 처리를 결정했습니다. 구독 반영 실패 역시 결제 상태를 유지한 채 별도의 재시도 흐름으로 분리했습니다.

 

이 과정에서 중요하게 본 기준은 외부 시스템의 상태를 로컬 트랜잭션만으로 보장하려 하지 않는 것이었습니다. 외부 결제 시스템은 내부 DB 트랜잭션에 참여하지 않고, 네트워크 오류만으로 실제 처리 결과를 판단할 수도 없습니다. 따라서 각 단계에서 확인 가능한 상태를 기준으로 처리하고, 결과를 확인할 수 없는 경우에는 임의로 확정하지 않고 복구 가능한 상태로 남기도록 설계했습니다.