SWIFT Pay Later API로 보는 BNPL 정산 표준화 구조

가맹점마다, BNPL 제공자마다 연동 사양이 제각각이라는 점이 지연 결제(BNPL, Buy Now Pay Later) 확장의 발목을 잡아왔다. SWIFT(Society for Worldwide Interbank Financial Telecommunication)의 Pay Later API는 가맹점·BNPL 사업자·은행 사이의 이 지연 결제 프로세스를 API로 표준화하는 접근이다. ISO 20022라는 글로벌 메시징 표준과 SWIFT 네트워크를 결합해 적격성 심사, 오퍼 생성, 승인·정산을 일관되게 자동화하는 게 목적이며, 상세 사양은 변동 가능성이 있어 최신 정보를 확인해야 한다.

API가 감싸는 것: 적격성부터 정산까지

Pay Later API는 소비자의 즉시 구매·후불 결제를 위해 적격성(Eligibility) 심사, 오퍼(Offer) 생성·수락, 캡처·정산(Capture/Settlement), 취소·환불을 API로 제공하는 인터페이스 집합이다. SWIFT는 금융기관 간 메시징 표준(ISO 20022)과 공인 PKI·mTLS·신뢰 네트워크 같은 보안 연결을 제공해 은행·대출기관과 BNPL 제공자의 상호운용성을 보장한다. 참여자는 가맹점/PSP, BNPL 제공자/핀테크, 은행/대출기관, 소비자로 나뉘고, 각 주체의 권한과 책임은 트랜잭션 단계별로 분리된다.

ISO 20022 정합성이 만드는 특징

오퍼·승인·정산 이벤트를 ISO 20022 메시지에 매핑하면 데이터 의미론이 일관돼 크로스보더, 다통화, 다양한 은행 코어와의 상호운용성이 높아진다. 오케스트레이션 계층은 적격성 → 오퍼 → 수락 → 캡처 → 정산으로 이어지는 전체 여정을 API로 조율하며, 실패·부분승인·부분캡처 같은 예외 경로는 명시적 상태머신으로 관리한다.

위험·적격성 심사는 신용 영향을 최소화하는 소프트 체크, 한도 산정, 부정거래 탐지 신호를 조합한 실시간 결정으로 이뤄지고 컨센트(Consent)·데이터 최소화 원칙에 맞춰 입력 스키마를 설계한다. 보안·컴플라이언스는 OAuth 2.0 + mTLS, JWS 서명, 키 롤오버 정책을 적용하고 SWIFT CSP, PCI DSS, GDPR 같은 준수 프레임워크와 정합성을 맞춘다. 정산·대사는 다회 캡처·부분 환불·취소를 커버하는 정산 이벤트 스트림과 리콘(reconciliation) 키·상관관계 ID로 장부 일치성을 확보하는 일이다.

누가, 왜 이 API를 쓰는가

가맹점·PSP는 체크아웃 단계에서 BNPL 옵션을 제공한다. Eligibility는 300~700ms 내 응답을 목표로 하고 승인 시 주문 생성과 동기화하며, 해외 매출에서는 환율·수수료 표시를 자동화한다. 은행·대출기관은 자체 리스크 엔진을 SWIFT API로 노출해 국내외 가맹점으로 확장하고, 기존 코어·LMS를 ISO 20022 어댑터로 연계한다.

BNPL 핀테크는 국가별 파트너 은행을 SWIFT 네트워크로 온보딩해 하나의 API로 여러 은행을 연결하고 정산·대사를 통합한다. ERP와 연계하는 기업은 오더-결제-정산 이벤트를 일치시켜 월말 대사를 자동화하고 회계 계정을 처리한다.

열세 단계로 보는 결제 흐름

⤢✕

입력은 고객 컨센트, 장바구니 금액·통화, 위험 신호(디바이스, IP, 주소)다. 처리는 Eligibility 결정, 오퍼 생성·수락, 캡처·정산, 예외 재시도로 이어지고, 출력은 오퍼 조건, 승인/거절, 정산 이벤트, 회계 대사 결과다.

직통 연동과 비교하면

항목	SWIFT Pay Later API	개별 BNPL 직통 연동
성능	네트워크 홉 증가로 레이턴시 소폭 증가 가능, 글로벌 캐시·프리밸리데이션으로 보완	파트너 근접 배치 시 단일 홉로 저지연 가능
확장성	ISO 20022·표준 API로 다국가/다은행 확장 용이	파트너별 사양 상이, 확장 비용 증가
일관성	데이터 의미론 일치, 상태머신 기반 트랜잭션 일관성	이벤트 명세 상이, 일관성 관리 비용 증가
안정성	SWIFT 네트워크 신뢰성·가시성, 단일 관문 의존 리스크 존재	파트너 다변화로 분산 리스크, 운영 복잡도 증가
운영 편의	통합 모니터링·대사 자동화, 온보딩 표준화	파트너별 관측·대사 파이프라인 개별 구축 필요

엔드포인트는 이렇게 나뉜다

버전·헤더는 Accept: application/json;version=1, Idempotency-Key: UUID v4, X-Correlation-ID: 추적용 UUID를 쓰고 인증은 OAuth 2.0 client_credentials + mTLS다.

핵심 엔드포인트는 다음과 같다.

POST /v1/pay-later/eligibility — 입력은 customer_reference, merchant_id, amount, currency, country, consent, risk_signals. 출력은 eligible, reason_code, offer_preview(apr, max_amount, tenure_options), decision_id다.
POST /v1/pay-later/offers — 입력은 decision_id 또는 사전 계산 파라미터, customer_auth(SCA), kyc_status. 출력은 offer_id, terms(apr, schedule), expiration_at, status다.
POST /v1/pay-later/captures — 입력은 offer_id, transaction_id, amount, partial_capture 허용 여부. 출력은 capture_id, status(pending/settled/failed), settlement_forecast다.
POST /v1/pay-later/refunds — 입력은 capture_id, amount, reason. 출력은 refund_id, status다.
Webhooks — 이벤트는 offer.accepted, offer.declined, capture.settled, capture.failed, refund.settled이며 HMAC-SHA256 서명 헤더와 재전송 방지 토큰(Replay nonce)으로 보호한다.

Eligibility 요청 예시는 다음과 같다.

{
  "customer_reference": "cust_12345",
  "merchant_id": "mrc_9001",
  "amount": "150.00",
  "currency": "EUR",
  "country": "DE",
  "consent": {
    "soft_credit_check": true,
    "timestamp": "2025-12-05T09:15:00Z"
  },
  "risk_signals": {
    "device_id": "dev_f84c",
    "ip": "203.0.113.10"
  }
}

응답은 다음과 같다.

{
  "eligible": true,
  "reason_code": null,
  "offer_preview": {
    "apr": "12.9",
    "max_amount": "500.00",
    "tenure_options": [3, 6, 12]
  },
  "decision_id": "dcsn_7a2c",
  "expires_at": "2025-12-05T09:20:00Z"
}

보안은 겹겹이, 대신 트레이드오프도 겹겹이

인증·암호화는 mTLS + OAuth 2.0(CC) 이중 보호에 JWS 본문 서명을 더한다. 키 롤오버는 90일 이하 주기로, 시간 동기화는 ±30초 스큐까지 허용하는데, 이만큼 키 관리 복잡성은 늘어난다.

데이터 최소화·보존 정책은 PII 토큰화, 카드 데이터 미보유, 목적 제한을 원칙으로 한다. 다만 보존 기간을 단축하면 사후 분쟁 분석용 데이터가 부족해질 수 있다. 웹훅 보안은 HMAC 서명 검증, 재전송 시 멱등 처리, IP 허용 목록으로 지키는데 검증을 강하게 할수록 지연이 늘어난다. 리스크·규제 측면에서는 AML/KYC와 소비자 보호 규정, 지역별 BNPL 규제를 반영해야 하고, 규제 변경에 대응하려면 정책 엔진을 외부화하는 편이 좋다.

SLO와 대사, 숫자로 정한다

Eligibility는 p95 700ms 미만, Capture는 p95 1.5초 미만을 목표로 하며 타임아웃은 3초, 지수 백오프는 0.5초·1초·2초로 설정한다. 멱등키로 중복을 막고 일시 실패 시 최대 3회까지 재시도한다.

관측 가능성은 X-Correlation-ID 기반 분산 트레이싱, 구조적 로그(JSON), 승인율·거절 사유·정산 불일치율 같은 핵심 KPI로 확보하고 DLQ와 재처리 파이프라인을 운영한다. 대사·정산은 일/월말 정산 리포트와 장부-이벤트 대조 자동화로 이뤄지며, 부분 캡처·부분 환불 규칙은 문서화해둬야 한다.

mTLS로 토큰부터 받아보기

전제조건은 OpenSSL로 준비한 클라이언트 인증서·키(client.crt, client.key)와 CA 번들(ca.pem), OAuth 토큰 엔드포인트와 Pay Later API 베이스 URL, 그리고 샌드박스 환경이다.

토큰 발급은 다음과 같다.

curl -s --cert client.crt --key client.key --cacert ca.pem \
  -u "client_id:client_secret" \
  -d "grant_type=client_credentials" \
  https://auth.example.swift.net/oauth2/token

Eligibility 호출은 다음과 같다.

curl -s --cert client.crt --key client.key --cacert ca.pem \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 7b7a6f1e-2a93-4f66-9b3b-0ae6b3b9f1d2" \
  -H "X-Correlation-ID: 6e4f2a5b-1c0d-4e2a-97f0-3a5b7f1c9e21" \
  -d @eligibility.json \
  https://api.example.swift.net/v1/pay-later/eligibility

도입 전 체크리스트

기술적으로는 ISO 20022 매핑, 멱등·상태머신, 웹훅 검증 모듈을 준비해야 한다. 보안 측면에서는 mTLS·OAuth 키 관리, 비밀 주기 교체, 데이터 최소화 정책을 갖춰야 한다. 운영 측면에서는 SLO·알림·DLQ, 대사 자동화, 규제별 제품 파라미터화가 필요하고, 계약 측면에서는 은행/BNPL 파트너 온보딩과 샌드박스 → 파일럿 → 상용 단계 게이트를 거쳐야 한다.

효과와 함께 남는 불확실성

사전 적격성 심사로 불필요한 카드 거절이 줄어 체크아웃 전환율이 1.5~~3.0%p 개선된 사례가 보고되지만, 환경에 따라 달라지므로 최신 정보를 확인해야 한다. 파트너별 커스텀 연동을 제거하면 API 유지보수 공수가 30~~50% 줄고, 실시간 컨텍스트 신호를 반영하면 부정거래 손실률이 상대적으로 10~20% 개선될 수 있다. 국가·은행을 추가할 때 온보딩 주기가 짧아져 시장 출시 기간(TTM)도 단축된다.

SWIFT Pay Later API는 지연 결제 여정을 표준화·보안·상호운용성 측면에서 강화하는 수단이다. ISO 20022 기반 오케스트레이션은 글로벌 확장성과 운영 일관성을 확보해주지만, 세부 사양은 바뀔 수 있으므로 최신 공식 문서를 확인하며 단계적으로 도입하는 편이 안전하다.