결제 API & 개발자 핀테크 2026 — Stripe / Adyen / Toss Payments / PortOne / Square / Mollie / Lago 심층 비교

"결제는 솔루션이 아니라 인프라다. 인프라는 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 표준):

import Stripe from 'stripe'

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년 주목할 변화 세 가지:

Stripe Tax가 한국·일본 추가 — 2025년 11월부로 한국 부가가치세(VAT) 자동 신고, 일본 소비세 자동 계산 지원. 글로벌 SaaS가 동아시아 세무를 외부 위탁 없이 처리 가능.
Stripe Issuing이 EU·UK 정식 출시 — Brex·Ramp 같은 비용 관리 스타트업을 유럽에서 만들 수 있게 됨.
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 기본 흐름
import { Client, CheckoutAPI } from '@adyen/api-library'

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):

// 클라이언트 측
import { loadTossPayments } from '@tosspayments/payment-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 예시
import * as PortOne from '@portone/browser-sdk/v2'

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 예시
import { Client, Environment } from 'square'

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)
import { createMollieClient } from '@mollie/api-client'

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를 모델로 했다고 인정

import Razorpay from 'razorpay'

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가 일본 결제 수용할 때 가장 깔끔
import KomojuApi from 'komoju-node'

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초당 수만 이벤트를 잃지 않고 집계
지연된 인보이스: 청구 시점에 한 달치 이벤트를 집계 → 빌링 시스템에 부하
예산 알림: 사용자가 예상치 못한 큰 청구를 받지 않게 80%, 100% 알림
선불 크레딧 + 후불 청구 혼합: OpenAI 모델이 대표적
여러 단위 통합: API 호출 + 저장 GB + 데이터 전송 GB를 한 인보이스에

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

// Tier SDK 예시 (개념)
import { Tier } from 'tier'
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 예시):

import { headers } from 'next/headers'

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가 다음을 자동 검증합니다.

타임스탬프가 5분 이내인가 (재전송 공격 방지)
HMAC-SHA256(body, secret)이 signature와 일치하는가
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

의사 결정 휴리스틱:

첫 번째 질문: 매출의 50% 이상이 어느 국가인가? 그 국가의 표준 PSP가 1차 선택
두 번째 질문: 사용량 과금이 비즈니스의 핵심인가? Yes면 빌링을 PSP와 분리(Lago/Orb)
세 번째 질문: 거래량이 월 1만 건 미만인가? Yes면 셀프 서비스 가능한 Stripe/Toss로 시작
네 번째 질문: 해외 진출 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/