> "결제는 솔루션이 아니라 인프라다. 인프라는 9년에 한 번 바뀐다." — Patrick Collison, Stripe Co-founder, Sessions 2024 키노트

2026년 5월 현재, 결제 API 생태계는 단일 글로벌 표준이 아닌 **글로벌(Stripe) + 지역 강자(Adyen, Toss Payments, Razorpay, GMO PG) + 빌링 전용(Lago, Orb, Metronome) + 빌더 도구(Bolt, Tier)** 네 진영으로 굳어졌습니다. 한 SaaS가 글로벌과 한국, 일본을 동시에 지원하려면 최소 3개 결제 게이트웨이를 운영해야 하고, 거기에 소비 기반 가격(consumption pricing)까지 더해지면 빌링 엔진이 별도 레이어로 들어옵니다.

이 글은 한 번에 18개 결제 제품의 포지션, API 표면적, 가격, 한계, 그리고 "누가 무엇을 골라야 하는가"를 다룹니다. 한국 개발자가 글로벌 출시할 때, 일본 개발자가 한국 진출할 때, B2B SaaS가 사용량 과금을 도입할 때 모두 참고하실 수 있도록 실전 코드 패턴까지 포함했습니다.

1. 2026년 결제 API 지도 — Stripe / 지역 강자 / 빌링 / 빌더 4 진영

결제 API는 "카드 한 번 긁기"가 아닙니다. 2026년에 한 결제 제품이 다루는 표면적은 다음과 같습니다.

| 레이어 | 역할 | 대표 제품 |

|---|---|---|

| Acquirer / PSP | 카드사·은행과 직접 연결, 거래 처리 | Stripe, Adyen, Worldpay, Fiserv |

| Aggregator | PSP를 묶어 통합 API 제공 | Toss Payments, PortOne, Razorpay, KOMOJU |

| Orchestration | 여러 PSP 간 라우팅·재시도·실패 복구 | Spreedly, Primer, Gr4vy |

| Billing / Invoicing | 구독·미터링·인보이스 생성 | Stripe Billing, Lago, Orb, Metronome, Maxio |

| Tax / Compliance | 세금 계산·신고, KYC | Stripe Tax, Avalara, TaxJar, Sovos |

| Identity / KYC | 본인 확인, 사업자 등록 | Stripe Identity, Persona, Onfido, Sumsub |

| Issuing | 카드·계좌 발급 | Stripe Issuing, Marqeta, Adyen Issuing |

2026년 시장 지형은 다음 4 진영으로 요약됩니다.

- **글로벌 표준(Stripe)**: 매출 1위, API 표준 사실상 정의, 미국·유럽·일본·싱가포르·홍콩 등 47개국 지원. Atlas + Tax + Identity + Issuing으로 "회사를 처음부터 만들 수 있는" 플랫폼으로 확장.

- **지역 강자**: 한국은 Toss Payments + PortOne, 유럽 엔터프라이즈는 Adyen, 인도는 Razorpay, 일본은 GMO PG + PAY.JP, 동남아는 Xendit. 현지 카드사·간편결제 연결과 정산 정확도가 강점.

- **빌링 전용**: Stripe Billing이 표준이지만, 사용량 과금이 복잡해지면서 Lago(오픈소스), Orb, Metronome, OpenMeter 같은 빌링 엔진이 별도 시장을 형성. PSP와 디커플링이 핵심.

- **빌더 도구**: Bolt(원클릭 체크아웃), Tier(소비 가격 SDK) 같은 "결제 위의 결제" 레이어가 신생.

선택의 첫 번째 분기점은 항상 **"어느 시장을 노리는가"** 입니다. 글로벌 SaaS면 Stripe가 거의 자동 선택이고, 한국 매출이 30% 이상이면 Toss Payments나 PortOne을 반드시 병행해야 하며, 일본은 별도 게이트웨이가 필요합니다.

2. Stripe — Atlas + Tax + Identity + Issuing 확장

Stripe는 2010년 7줄 코드 결제 API로 시작해, 2026년 현재 **단순 PSP를 넘어 회사 운영 전체를 다루는 플랫폼**으로 확장했습니다. 2024년 IPO 루머가 무성했으나 결국 비상장 유지를 선택했고, 2025년 평가액은 약 950억 달러로 회복.

핵심 제품 라인업:

- **Payments**: 카드·간편결제·은행이체 등 100개 이상 결제 수단, 47개국, `2.9% + $0.30` (미국 기준)

- **Billing**: 구독, 사용량 과금, 인보이스 생성. 2025년 `usage_records` API가 `Meter Events`로 재설계됨

- **Tax**: 자동 세금 계산·신고, 50개국 지원, 2025년 한국·일본 추가

- **Atlas**: 미국 법인 설립(델라웨어 C-corp) + EIN + 은행 계좌 + 주식 발행을 한 화면에서. `$500`

- **Identity**: KYC/KYB, 30개국 신분증·셀카 검증, `$1.50` per check

- **Issuing**: Visa/Mastercard 카드 발급, 가상 카드·물리 카드, B2B 비용 관리(Brex, Ramp가 이걸로 만들어짐)

- **Capital**: 매출 기반 대출, AI 기반 한도 산정

- **Climate**: 매출의 일부를 탄소 제거에 자동 기부

- **Connect**: 마켓플레이스(eBay, Shopify, Lyft) 정산

기본 결제 흐름 (PaymentIntents API, 2026 표준):

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {

apiVersion: '2026-01-15',

})

// 1) 서버에서 PaymentIntent 생성

const intent = await stripe.paymentIntents.create({

amount: 1999, // $19.99 (센트 단위)

currency: 'usd',

automatic_payment_methods: { enabled: true }, // 카드+간편결제 자동 표시

metadata: { order_id: 'ord_abc123' },

})

// 2) 클라이언트는 client_secret으로 결제 UI 마운트

// <Elements options={{ clientSecret: intent.client_secret }}>

// <PaymentElement />

// </Elements>

// 3) 결제 완료 후 웹훅 처리

export async function POST(req: Request) {

const sig = req.headers.get('stripe-signature')!

const body = await req.text()

const event = stripe.webhooks.constructEvent(

body,

sig,

process.env.STRIPE_WEBHOOK_SECRET!

)

if (event.type === 'payment_intent.succeeded') {

await fulfillOrder(event.data.object)

}

return new Response('ok')

}

2026년 주목할 변화 세 가지:

1. **Stripe Tax가 한국·일본 추가** — 2025년 11월부로 한국 부가가치세(VAT) 자동 신고, 일본 소비세 자동 계산 지원. 글로벌 SaaS가 동아시아 세무를 외부 위탁 없이 처리 가능.

2. **Stripe Issuing이 EU·UK 정식 출시** — Brex·Ramp 같은 비용 관리 스타트업을 유럽에서 만들 수 있게 됨.

3. **Agent Commerce Protocol(ACP) 베타** — AI 에이전트가 사용자 대신 결제할 때를 위한 새로운 인증 흐름. Anthropic, OpenAI와 협업.

Stripe의 약점: 한국 카드사 연결이 약함(국내 카드는 PayPal 우회 또는 Toss 병행 필요), 일본도 PayPay·LINE Pay 미지원, 가격이 비싸다(엔터프라이즈는 Adyen이 더 저렴한 경우 많음).

3. Adyen — 유럽 엔터프라이즈의 표준

Adyen은 2006년 네덜란드에서 출발한 PSP로, 글로벌 엔터프라이즈 시장에서 Stripe의 가장 강력한 경쟁자입니다. Uber, Spotify, McDonald's, eBay, Microsoft, Booking.com이 모두 Adyen으로 결제를 처리합니다.

Adyen의 차별점:

- **단일 플랫폼**: 카드 인수(Acquiring), 결제 처리(Processing), 정산(Settlement), 리스크 관리를 한 회사에서 처리 — Stripe는 카드 인수를 일부 위탁하는 모델

- **저렴한 인터체인지++ 가격**: 거래 금액이 크면 (`$10M`/년 이상) Stripe보다 10–30% 저렴

- **오프라인 + 온라인 통합**: 매장 POS와 온라인 결제를 같은 콘솔에서 관리 — McDonald's 글로벌 도입의 핵심

- **로컬 결제 수단 광범위 지원**: iDEAL(네덜란드), Bancontact(벨기에), MB Way(포르투갈), Klarna(BNPL), 그리고 한국 카드 일부 지원

API는 RESTful이지만 Stripe보다 학습 곡선이 가파릅니다. `paymentMethods.json` → `payments.json` → `payments/details.json` 3단계가 표준 흐름이며, 모든 요청은 JSON이고 응답에는 `pspReference`라는 거래 ID가 붙습니다.

// Adyen Checkout API 기본 흐름

const client = new Client({ apiKey: process.env.ADYEN_API_KEY!, environment: 'TEST' })

const checkout = new CheckoutAPI(client)

// 1) 사용 가능한 결제 수단 조회

const methods = await checkout.PaymentsApi.paymentMethods({

merchantAccount: 'YourMerchantAccount',

amount: { value: 1999, currency: 'USD' },

countryCode: 'US',

shopperLocale: 'en-US',

})

// 2) 결제 요청

const result = await checkout.PaymentsApi.payments({

merchantAccount: 'YourMerchantAccount',

amount: { value: 1999, currency: 'USD' },

reference: 'order-abc-123',

paymentMethod: { type: 'scheme', encryptedCardNumber: '...' },

returnUrl: 'https://your-site.com/checkout/result',

})

// 3) 3DS 챌린지가 필요하면 result.action 처리

if (result.resultCode === 'IdentifyShopper') {

// 클라이언트에서 3DS 챌린지 수행

}

Adyen은 **거래량이 월 1만 건 이상**, **여러 국가에서 동시 운영**, **오프라인 매장과 온라인을 통합**해야 한다면 Stripe보다 좋은 선택입니다. 거꾸로 거래량이 작거나 빠른 셀프 서비스 가입이 필요하면 Stripe가 압도적으로 유리합니다.

4. Toss Payments — 한국의 표준

토스(Viva Republica)가 LG U+의 결제 사업을 2020년 인수해 만든 Toss Payments는 2026년 현재 **한국 SaaS·이커머스의 디폴트 선택**입니다. 신생 스타트업의 80% 이상이 Toss Payments를 우선 검토합니다.

강점:

- **개발자 경험이 한국에서 압도적**: 한글 문서, 코드 예제, Postman 컬렉션, 그리고 카카오톡 채널 지원

- **카카오페이·네이버페이·삼성페이·토스페이를 한 SDK로** — 별도 계약 없이 토글 한 번

- **테스트 환경 무료**: 실제 카드 없이 모든 시나리오 재현 가능

- **수수료**: 일반 카드 약 2.5–3.3%, 간편결제 2.2–3.0%, 페이코·카카오페이 추가 0.1–0.5%

- **빠른 정산**: D+1 (영업일 기준 다음날), 일부 프로모션은 D+0

기본 결제 흐름 (Toss Payments JavaScript SDK):

// 클라이언트 측

const tossPayments = await loadTossPayments(

'live_ck_xxx' // 클라이언트 키

)

await tossPayments.requestPayment('카드', {

amount: 50000,

orderId: 'order_abc_123',

orderName: '프리미엄 구독 1개월',

customerName: '홍길동',

successUrl: 'https://example.com/success',

failUrl: 'https://example.com/fail',

})

// 서버 측 — successUrl에서 결제 승인

const response = await fetch('https://api.tosspayments.com/v1/payments/confirm', {

method: 'POST',

headers: {

Authorization: `Basic ${btoa(process.env.TOSS_SECRET_KEY + ':')}`,

'Content-Type': 'application/json',

},

body: JSON.stringify({

paymentKey,

orderId,

amount: 50000,

}),

})

웹훅 서명 검증은 2024년부터 의무화됐고, `TossPayments-Signature` 헤더를 `signing_key`로 HMAC-SHA256 검증합니다. 멱등성을 위해 `Idempotency-Key` 헤더를 모든 결제 승인 요청에 권장합니다.

Toss Payments의 약점: 글로벌(미국·유럽) 카드 발급 결제는 지원하지만 환전·정산은 별도 절차가 필요하며, 매출이 글로벌 위주면 Stripe와 병행해야 합니다. 또한 일부 산업(성인, 도박, 일부 핀테크)은 가맹점 심사가 까다롭습니다.

5. PortOne (구 아임포트) — 한국 결제 통합 게이트웨이

PortOne(구 아임포트, 2024년 리브랜딩)은 한국의 모든 PSP를 단일 SDK로 묶어주는 **결제 어그리게이터**입니다. 한 번의 통합으로 토스, KCP, 이니시스, 다날, 카카오페이, 네이버페이, 페이코, 스마일페이, 신용카드, 가상계좌, 휴대폰 결제, 해외 결제(Stripe, PayPal 우회)까지 모두 사용 가능합니다.

PortOne을 쓰는 이유:

- **PSP를 바꿔도 코드는 그대로**: 토스 → KCP 전환이 환경변수 한 줄

- **다중 PSP 라우팅**: A PSP가 다운되면 B PSP로 자동 폴백

- **통합 대시보드**: 여러 PSP 거래를 한 화면에서 조회·환불

- **수수료**: PortOne 자체 수수료는 거래당 약 30–50원, PSP 수수료는 별도

- **2024년 V2 API**: TypeScript 기반 SDK, OpenAPI 자동 생성

// PortOne V2 SDK 예시

const response = await PortOne.requestPayment({

storeId: 'store-xxx',

channelKey: 'channel-xxx', // 채널이 PSP를 결정 (토스/KCP/이니시스 등)

paymentId: `payment-${crypto.randomUUID()}`,

orderName: '프리미엄 구독',

totalAmount: 50000,

currency: 'CURRENCY_KRW',

payMethod: 'CARD',

})

// 서버에서 결제 검증

const verification = await fetch(

`https://api.portone.io/payments/${response.paymentId}`,

{ headers: { Authorization: `PortOne ${process.env.PORTONE_API_SECRET}` } }

)

PortOne의 매력은 **여러 PSP 협상력**입니다. 거래량이 늘어나면 PSP A에 협상해 수수료를 낮추고 일부 거래를 그쪽으로 라우팅할 수 있습니다. 거꾸로 단일 PSP만 쓸 거면 PortOne 레이어가 오히려 비용입니다.

2026년 PortOne은 일본 KOMOJU, 인도네시아 Xendit과의 통합을 추가해 동남아 확장 SaaS의 디폴트로 자리잡고 있습니다.

6. KCP / 이니시스 / 다날 — 한국 클래식 PSP

토스 이전 한국 결제 시장의 3대 강자였습니다.

- **KCP (한국사이버결제)**: 1999년 설립, NHN의 자회사. 카드·계좌이체·휴대폰·상품권 전 영역 지원. 대기업 도입 비율 높음(신세계, 11번가, 쿠팡 일부)

- **이니시스 (KG이니시스)**: 1998년 설립, KG그룹. 가장 오래된 PSP 중 하나, 보수적 산업(공공·교육·금융) 강세

- **다날 (Danal)**: 1997년 설립, 휴대폰 결제 1위. 본인인증 서비스로도 유명

API 표면적은 2010년대 초반 설계가 많이 남아 있어, KEY 발급·암호화·콜백 URL 설정이 복잡합니다. JSP/PHP 예제가 여전히 표준 문서이고, 모던 TypeScript SDK는 부족합니다.

이니시스 결제 결과 콜백 검증 예시 (개념)

가맹점은 P_MID, P_OID, P_AMT, P_TID 같은 필드를 KCP와 공유 키로 HMAC 검증

거의 모든 한국 클래식 PSP는 EUC-KR 인코딩 잔재가 있어 UTF-8 변환 주의

**KCP / 이니시스 / 다날을 직접 통합할 때**:

- 신규 프로젝트라면 PortOne을 통해 간접 통합하는 게 거의 항상 유리합니다

- 직접 통합은 대기업 가맹점 정책상 필요한 경우(메인넷 키 직접 보유 요구)에 한정

- 환불·부분취소 API가 PSP마다 미묘하게 달라 추상화 레이어가 필수

2026년에는 이 세 PSP 모두 RESTful 모던 API로 리뉴얼 중이지만, 마이그레이션 속도가 느려 PortOne 같은 어그리게이터의 가치가 여전히 큽니다.

7. Square + Cash App — Block 생태계

Square는 2009년 Jack Dorsey가 만든 모바일 카드 결제기로 시작해, 2021년 모회사를 Block으로 리브랜딩하면서 **결제 + 송금(Cash App) + 비트코인** 통합 핀테크 그룹으로 확장했습니다.

**Square (B2B 결제)**:

- **물리 단말기(POS) 강점**: 미국·캐나다·영국·호주·일본의 식당·소매점 80만 곳에서 사용

- **Square Online**: 온라인 스토어 빌더(Shopify 경쟁자) 무료 제공

- **Square Reader**: 신용카드 단말기를 `$10–49`로 판매, 거래 수수료로 수익

- **API**: REST + GraphQL, OAuth 2.0, Subscriptions/Catalog/Inventory/Orders 통합

- **수수료**: 카드 단말기 2.6% + 10센트, 온라인 2.9% + 30센트

**Cash App (P2P 송금 + B2C)**:

- 미국 5천5백만 활성 사용자

- **Cash App Pay**: 체크아웃에서 사용자가 휴대폰으로 QR 스캔해 결제 (Venmo와 유사)

- 비트코인 매수·매도·송금 가능

- B2B에는 직접 노출 안 됨, Square 가맹점이 옵션으로 활성화

// Square Payments API 예시

const client = new Client({

accessToken: process.env.SQUARE_ACCESS_TOKEN,

environment: Environment.Production,

})

const response = await client.paymentsApi.createPayment({

sourceId: 'cnon:card-nonce-from-web-sdk',

idempotencyKey: crypto.randomUUID(),

amountMoney: { amount: 1999n, currency: 'USD' },

locationId: 'L1234567890',

})

Square는 **오프라인 매장이 있는 비즈니스**에 강하고, Stripe는 **소프트웨어 회사**에 강합니다. 둘이 직접 경쟁하는 영역은 좁고, 같이 쓰는 경우(매장은 Square, 웹 결제는 Stripe)도 흔합니다.

8. Mollie / Checkout.com / Braintree — 유럽 + PayPal 계열

**Mollie (네덜란드, 2004년 설립)**:

- 유럽 SMB 시장의 강자, 35개국 지원

- iDEAL, Bancontact, SOFORT, Klarna, Apple Pay, Google Pay 등 유럽 결제 수단 풍부

- 수수료가 명확하고 저렴 (iDEAL `€0.29`/거래)

- API는 RESTful, 매우 깔끔 (Stripe 다음으로 개발자 경험 좋음 평가)

- 2024년 Adyen에 인수설 있었으나 독립 유지

**Checkout.com (영국, 2012년 설립)**:

- 엔터프라이즈 시장 집중, Klarna·Wise·Sony의 결제 처리

- 인터체인지++ 가격 모델, 거래량 크면 매우 저렴

- 150개 통화, 글로벌 인수 라이선스 보유

- 2022년 평가액 `$40B`로 정점, 2024년 `$11B`로 조정

- API 표면적 풍부하지만 셀프 서비스 가입 어려움 (영업 컨택 필수)

**Braintree (PayPal 자회사, 2007년 → 2013년 PayPal 인수)**:

- PayPal·Venmo·카드를 통합 SDK로 제공

- Drop-in UI로 빠른 통합 가능

- 미국 SaaS·이커머스에서 PayPal 사용자를 잡고 싶을 때 표준 선택

- 수수료 2.59% + 49센트 (미국 카드)

- 단점: API가 2010년대 초반 설계, GraphQL은 베타 상태에서 발전 멈춤

// Mollie Payments 예시 (가장 깔끔한 유럽 API)

const mollie = createMollieClient({ apiKey: process.env.MOLLIE_API_KEY! })

const payment = await mollie.payments.create({

amount: { currency: 'EUR', value: '19.99' },

description: '프리미엄 구독',

redirectUrl: 'https://example.com/return',

webhookUrl: 'https://example.com/webhook',

metadata: { orderId: 'order-abc-123' },

})

// 사용자를 payment.getCheckoutUrl()로 리다이렉트

세 제품의 위치: **Mollie는 유럽 SMB**, **Checkout.com은 유럽·중동 엔터프라이즈**, **Braintree는 미국·PayPal 친화 시장**. 한국에서 이 세 제품을 메인으로 쓸 일은 거의 없고, 글로벌 결제 옵션 중 하나로 활성화하는 경우가 대부분입니다.

9. Razorpay — 인도 결제 표준

Razorpay는 2014년 IIT 출신 창업자가 만든 인도의 Stripe 격입니다. 2026년 현재 인도 결제 시장의 약 40%를 점유.

특이점:

- **UPI(Unified Payments Interface)** 가 인도의 디폴트: QR 스캔으로 즉시 송금, 수수료 거의 0

- **GST(인도 부가가치세) 자동 처리**: 인보이스에 GST 자동 부착

- **Razorpay Capital**: 매출 기반 대출, 인도 스타트업의 주요 자금 조달 경로 중 하나

- **수수료**: UPI 무료(`< ₹2,000`), 카드 2%, 국제 카드 3%

- **API는 Stripe와 매우 유사**: Razorpay 창업자가 공개적으로 Stripe API를 모델로 했다고 인정

const razorpay = new Razorpay({

key_id: process.env.RAZORPAY_KEY_ID!,

key_secret: process.env.RAZORPAY_KEY_SECRET!,

})

// 주문 생성

const order = await razorpay.orders.create({

amount: 50000, // 500 INR (paise 단위)

currency: 'INR',

receipt: 'order_rcptid_11',

})

// 클라이언트에서 Razorpay Checkout 호출

// 결제 후 razorpay_payment_id, razorpay_signature 받아서 검증

한국 SaaS가 인도 진출할 때 Stripe만으로는 UPI 결제를 잡을 수 없고, Razorpay 통합이 거의 필수입니다. 인도 결제의 70% 이상이 UPI이기 때문입니다.

10. 일본 — GMO Payment Gateway / PAY.JP / KOMOJU / PayPay / LINE Pay

일본은 한국과 완전히 다른 결제 생태계를 갖습니다.

**GMO Payment Gateway**:

- 일본 최대 PSP, 도쿄 증시 상장(`4784`)

- 대기업(닌텐도, 라쿠텐, 메루카리)의 핵심 결제 인프라

- API는 보수적, 일본어 문서 중심, 영문 문서 빈약

- 수수료 협상 가능 (대형 가맹점은 카드 수수료 1.5%까지 내려감)

**PAY.JP**:

- BASE(일본 대표 이커머스 빌더)가 만든 PSP, "일본의 Stripe"를 표방

- API가 Stripe와 의도적으로 유사, JavaScript SDK 잘 정리됨

- 카드 결제만 깔끔, 간편결제는 약함

- 수수료 3.6% (일률)

**KOMOJU**:

- 외국 SaaS의 일본 결제 진입 표준 (Patreon, itch.io, Discord 등이 사용)

- 일본 신용카드 + 편의점 결제(コンビニ決済) + 은행 송금(銀行振込) + PayPay + LINE Pay 통합

- 영문 문서 완비, 한국 PortOne처럼 어그리게이터 역할

- 본사는 도쿄, Degica가 운영

**PayPay**:

- 소프트뱅크가 만든 QR 결제, 일본 활성 사용자 6천만

- 직접 API 통합은 어렵고, 보통 KOMOJU·GMO PG를 통해 수용

**LINE Pay**:

- LINE 계정에 결제 연결, 한국 LINE Pay와는 별개 운영

- 2024년 일본 사업 일부 축소, 매장 결제는 PayPay에 통합 중

// KOMOJU API 예시 — 외국 SaaS가 일본 결제 수용할 때 가장 깔끔

const komoju = new KomojuApi({

secretKey: process.env.KOMOJU_SECRET_KEY!,

})

const session = await komoju.sessions.create({

amount: 1980, // 1,980엔

currency: 'JPY',

email: 'customer@example.jp',

return_url: 'https://example.com/return',

payment_types: ['credit_card', 'konbini', 'paypay', 'linepay'],

})

// session.session_url로 사용자 리다이렉트

한국 → 일본 진출 SaaS에 추천 조합: **KOMOJU(소액·외국인 친화) + GMO PG(대규모 거래)** 병행. 일본 카드는 3DS 강제가 늘어나고 있어 3DS2 SDK 통합이 점점 중요해집니다.

11. 빌링 — Stripe Billing vs Lago vs OpenMeter vs Orb vs Metronome

SaaS 비즈니스의 빌링(구독 + 사용량)은 결제(payment)와 분리된 별도 도메인입니다. 2026년 빌링 시장은 6개 제품으로 굳어졌습니다.

| 제품 | 운영 모델 | 강점 | 약점 |

|---|---|---|---|

| Stripe Billing | SaaS, Stripe 종속 | 결제 통합 매끄러움, 구독 표준 | 사용량 미터링이 복잡한 경우 약함 |

| Lago | 오픈소스 + Cloud | 자체 호스팅 가능, 무료 시작 | 신생, 일부 기능 부족 |

| OpenMeter | 오픈소스, CNCF | 사용량 미터링 전용, Kafka 기반 | 빌링 자체는 별도 도구 필요 |

| Orb | SaaS | 복잡한 사용량 모델 강점, AI 회사 사용 | 비쌈 |

| Metronome | SaaS | OpenAI·Anthropic·Databricks 사용 | 엔터프라이즈만 |

| Maxio (구 Chargify + SaaSOptics) | SaaS | B2B 전용, MRR/ARR 리포팅 강 | 모던 사용량 모델 약함 |

**Stripe Billing의 기본 구독 모델**:

// 1) 가격(Price) 등록 (한 번)

const price = await stripe.prices.create({

product: 'prod_premium',

unit_amount: 1999,

currency: 'usd',

recurring: { interval: 'month' },

})

// 2) 구독 생성

const subscription = await stripe.subscriptions.create({

customer: 'cus_xxx',

items: [{ price: price.id }],

payment_behavior: 'default_incomplete',

expand: ['latest_invoice.payment_intent'],

})

// 3) 사용량 기반 가격 — 2025년 Meter Events API로 재설계

await stripe.billing.meterEvents.create({

event_name: 'api_request',

payload: { stripe_customer_id: 'cus_xxx', value: '1' },

})

**Lago의 매력 (오픈소스)**:

Docker Compose 한 줄로 자체 호스팅 가능

https://github.com/getlago/lago

services:

api:

image: getlago/api:v1.x

environment:

DATABASE_URL: postgres://...

REDIS_URL: redis://...

Lago는 **결제 처리는 Stripe·Adyen에 위임**하고, 사용량 미터링·인보이스 생성·구독 관리만 담당합니다. 결제 PSP를 바꾸기 쉽고, 데이터 주권이 필요한 EU·한국 회사가 자체 호스팅하기 좋습니다.

**Orb / Metronome의 위치**:

- 둘 다 "사용량 기반 가격이 복잡한 회사" 전용

- OpenAI는 Metronome으로 토큰 단위 과금 처리 (월 수십억 이벤트)

- Anthropic도 비슷한 규모로 Orb·Metronome 평가

- 단가는 비쌈 (월 `$2,000–$10,000`+) 하지만 사용량 모델이 복잡하면 자체 구축 대비 압도적 ROI

12. 소비 기반 가격 (consumption pricing) — Tier / Stripe Billing

2023–2026년 SaaS 가격 모델의 가장 큰 변화는 **구독(seat-based)에서 소비(consumption-based)로의 이동**입니다. OpenAI(토큰), Snowflake(컴퓨트), Vercel(빌드 분), Cloudflare(요청)가 표준화한 모델이 2026년에는 거의 모든 인프라 SaaS의 기본이 되었습니다.

소비 모델의 구현 난점:

1. **정확한 미터링**: 1초당 수만 이벤트를 잃지 않고 집계

2. **지연된 인보이스**: 청구 시점에 한 달치 이벤트를 집계 → 빌링 시스템에 부하

3. **예산 알림**: 사용자가 예상치 못한 큰 청구를 받지 않게 80%, 100% 알림

4. **선불 크레딧 + 후불 청구 혼합**: OpenAI 모델이 대표적

5. **여러 단위 통합**: API 호출 + 저장 GB + 데이터 전송 GB를 한 인보이스에

**Tier (오픈소스)** 는 소비 가격을 SDK 한 줄로 추가하게 해주는 도구입니다.

// Tier SDK 예시 (개념)

const tier = new Tier()

// 사용량 보고

await tier.report('org:acme', 'feature:api-calls', 100)

// 가격 모델은 YAML로 선언

// plans:

// premium:

// features:

// api-calls:

// tiers:

// - upto: 10000

// price: 0

// - upto: 100000

// price: 0.001

// - upto: inf

// price: 0.0005

**Stripe Billing의 Meter Events** (2025년 출시)는 같은 문제를 Stripe 내부에서 해결합니다.

// 매 API 호출마다 미터 이벤트 발사

await stripe.billing.meterEvents.create({

event_name: 'api_calls',

payload: {

stripe_customer_id: 'cus_xxx',

value: '1',

},

})

// Stripe가 자동으로 집계해 월말 인보이스 생성

소비 가격의 핵심은 **이벤트 수집 인프라가 빌링과 디커플링되어야 한다**는 점입니다. OpenMeter, Tinybird, ClickHouse 같은 분석 DB에 먼저 이벤트를 쌓고, 빌링 시스템(Stripe/Lago/Orb)이 그걸 읽어가는 패턴이 표준이 되었습니다.

13. 보안 — 웹훅 검증 / 멱등 키 / SCA / 3DS2

결제 통합의 80%는 "기본 거래 흐름", 나머지 20%가 보안·신뢰성이지만, 그 20%가 사고의 99%를 차지합니다.

**웹훅 서명 검증** (Stripe 예시):

export async function POST(req: Request) {

const sig = (await headers()).get('stripe-signature')!

const body = await req.text() // raw body, JSON.parse 전에

let event

try {

event = stripe.webhooks.constructEvent(

body,

sig,

process.env.STRIPE_WEBHOOK_SECRET!

)

} catch (err) {

return new Response('Invalid signature', { status: 400 })

}

// 이제 event는 검증됨, 처리 진행

}

`stripe-signature` 헤더는 `t=timestamp,v1=signature` 형식이고, Stripe SDK가 다음을 자동 검증합니다.

1. 타임스탬프가 5분 이내인가 (재전송 공격 방지)

2. HMAC-SHA256(body, secret)이 signature와 일치하는가

3. timing-safe compare 사용

**멱등 키 (Idempotency-Key)**:

같은 요청을 두 번 보내도 같은 결과가 나오게 보장합니다. Stripe·Square·Razorpay·Toss Payments 모두 지원.

const intent = await stripe.paymentIntents.create(

{ amount: 1999, currency: 'usd' },

{ idempotencyKey: `order-${orderId}-${attempt}` }

)

핵심: **멱등 키는 24시간 동안 유효**하고, **같은 키로 다른 페이로드를 보내면 에러**가 납니다. UUID 한 번 생성해서 재시도마다 같은 값을 쓰는 게 표준 패턴.

**SCA (Strong Customer Authentication)**:

EU PSD2의 요구사항으로 2021년부터 의무화. 거의 모든 EU 거래에서 다음 중 2개 인증이 필요합니다.

- 알고 있는 것 (비밀번호, PIN)

- 가지고 있는 것 (휴대폰, 보안 토큰)

- 자체 (생체 인증)

실무에서는 **3DS2(3D Secure 2.x)** 가 표준 구현 방식이고, 카드사가 위험 점수를 평가해 일부 거래는 자동 통과(frictionless), 일부는 OTP/생체 인증(challenge)을 요구합니다.

// PaymentIntent 생성 시 자동으로 SCA 흐름 트리거

const intent = await stripe.paymentIntents.create({

amount: 1999,

currency: 'eur',

payment_method_types: ['card'],

// automatic_payment_methods가 SCA 자동 처리

})

// 클라이언트에서 PaymentElement가 3DS 챌린지 모달 표시

한국에서는 SCA 대신 **본인인증(휴대폰/공인인증)** 이 일부 거래에 의무이고, Toss Payments·PortOne이 SDK 한 줄로 처리합니다. 일본은 2025년부터 3DS2 단계적 의무화 시작 (대형 가맹점부터 적용).

14. 누가 무엇을 골라야 하나 — 글로벌 / 한국 / 일본 / B2B SaaS / 마켓플레이스

마지막으로 시나리오별 추천을 정리합니다.

| 시나리오 | 1차 선택 | 2차 / 보조 | 빌링 |

|---|---|---|---|

| 글로벌 SaaS (영어권) | Stripe | Adyen (엔터프라이즈) | Stripe Billing |

| 한국 중심 SaaS | Toss Payments 또는 PortOne | Stripe (해외 카드) | Stripe Billing or Lago |

| 한국 + 일본 동시 출시 | PortOne (한국) + KOMOJU (일본) | Stripe (서구) | Lago (디커플링) |

| 일본 중심 | GMO PG + KOMOJU | Stripe (서구) | Stripe Billing |

| 인도 진출 | Razorpay | Stripe (국제 카드) | Stripe Billing |

| 유럽 SMB | Mollie | Stripe | Stripe Billing |

| 유럽 엔터프라이즈 | Adyen | Checkout.com | Stripe Billing or Orb |

| AI 사용량 과금 | Stripe (결제) | — | Metronome or Orb |

| 오픈소스/자체 호스팅 필요 | Stripe + Lago | — | Lago |

| 오프라인 매장 + 온라인 | Square (US) / Adyen | Stripe (웹 부분만) | Stripe Billing |

| 마켓플레이스 (Uber, Etsy 형) | Stripe Connect | Adyen for Platforms | Stripe Billing |

| B2B 청구서 발행 위주 | Stripe Billing | Maxio | Maxio |

| 원클릭 체크아웃 강조 | Bolt + Stripe | PayPal + Braintree | Stripe Billing |

**의사 결정 휴리스틱**:

1. **첫 번째 질문**: 매출의 50% 이상이 어느 국가인가? 그 국가의 표준 PSP가 1차 선택

2. **두 번째 질문**: 사용량 과금이 비즈니스의 핵심인가? Yes면 빌링을 PSP와 분리(Lago/Orb)

3. **세 번째 질문**: 거래량이 월 1만 건 미만인가? Yes면 셀프 서비스 가능한 Stripe/Toss로 시작

4. **네 번째 질문**: 해외 진출 12개월 내 계획? Yes면 처음부터 Stripe 병행 설계

**가장 흔한 실수**:

- 처음부터 여러 PSP를 직접 통합 → PortOne·KOMOJU 같은 어그리게이터로 시작하고 거래량 늘면 협상해서 직접 통합으로 옮기는 게 정답

- Stripe Billing으로 사용량 과금을 시작 → 모델이 복잡해지면 마이그레이션 고통이 큼. 사용량이 핵심이면 처음부터 Lago/Orb 검토

- 웹훅 검증을 미루기 → 프로덕션 사고의 1위 원인. 첫 통합부터 서명 검증 필수

- 멱등 키 미사용 → 네트워크 재시도로 중복 결제. 모든 결제 API는 멱등 키 지원, 무조건 사용

결제는 인프라이고, 인프라는 한 번 잘못 깔면 마이그레이션 비용이 매출의 1–3%에 달합니다. 위 표에서 시나리오 매칭만 잘 해도 절반은 성공입니다. 나머지 절반은 웹훅·멱등성·3DS2를 처음부터 옳게 다루는 것입니다.

15. 참고 / References

- Stripe Documentation — `https://docs.stripe.com/`

- Stripe API Reference — `https://docs.stripe.com/api`

- Stripe Atlas — `https://stripe.com/atlas`

- Stripe Tax — `https://stripe.com/tax`

- Stripe Identity — `https://stripe.com/identity`

- Stripe Issuing — `https://stripe.com/issuing`

- Stripe Billing Meter Events — `https://docs.stripe.com/billing/subscriptions/usage-based`

- Adyen Documentation — `https://docs.adyen.com/`

- Adyen API Explorer — `https://docs.adyen.com/api-explorer/`

- Toss Payments Developers — `https://docs.tosspayments.com/`

- Toss Payments GitHub — `https://github.com/tosspayments`

- PortOne Documentation — `https://developers.portone.io/`

- PortOne V2 API — `https://developers.portone.io/api/rest-v2`

- KCP 한국사이버결제 — `https://developers.kcp.co.kr/`

- KG 이니시스 개발자센터 — `https://manual.inicis.com/`

- 다날 결제 — `https://www.danalpay.com/`

- Square Developer — `https://developer.squareup.com/`

- Cash App Pay — `https://developers.cash.app/`

- Mollie Documentation — `https://docs.mollie.com/`

- Checkout.com Documentation — `https://www.checkout.com/docs`

- Braintree Documentation — `https://developer.paypal.com/braintree/docs`

- Razorpay Documentation — `https://razorpay.com/docs/`

- GMO Payment Gateway — `https://www.gmo-pg.com/service/`

- PAY.JP Documentation — `https://pay.jp/docs/`

- KOMOJU Documentation — `https://docs.komoju.com/`

- PayPay for Developers — `https://developer.paypay.ne.jp/`

- LINE Pay Developers — `https://pay.line.me/developers/apis/onlineApis`

- Lago Open Source — `https://github.com/getlago/lago`

- Lago Documentation — `https://doc.getlago.com/`

- OpenMeter — `https://openmeter.io/`

- Orb — `https://www.withorb.com/`

- Metronome — `https://metronome.com/`

- Maxio (Chargify + SaaSOptics) — `https://www.maxio.com/`

- Tier — `https://www.tier.run/`

- Bolt — `https://www.bolt.com/`

- Standard Webhooks — `https://www.standardwebhooks.com/`

- PCI DSS — `https://www.pcisecuritystandards.org/`

- PSD2 / SCA — `https://www.ecb.europa.eu/paym/intro/mip-online/2018/html/1803_revisedpsd.en.html`

- 3D Secure 2 Spec — `https://www.emvco.com/emv-technologies/3d-secure/`