Skip to content

필사 모드: 決済 API & 開発者フィンテック 2026 — Stripe / Adyen / Toss Payments / PortOne / Square / Mollie / Lago 徹底比較

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.
원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「決済はソリューションではなくインフラだ。インフラは 9 年に 1 度だけ変わる」— Patrick Collison, Stripe 共同創業者, Sessions 2024 基調講演

2026 年 5 月時点で、決済 API エコシステムは単一のグローバル標準ではなく、**グローバル(Stripe)+ 地域王者(Adyen, Toss Payments, Razorpay, GMO PG)+ 課金専業(Lago, Orb, Metronome)+ ビルダーツール(Bolt, Tier)** の 4 つの陣営に固まりました。米国・韓国・日本を同時に展開するには最低 3 つの決済ゲートウェイが必要で、さらに従量課金(consumption pricing)が加わると課金エンジンが別レイヤとして入ってきます。

本記事では 18 個の決済プロダクトについて、ポジション・API 表面積・価格・限界、そして「誰が何を選ぶべきか」を一気に整理します。韓国開発者がグローバル展開する時、日本開発者が韓国進出する時、B2B SaaS が従量課金を導入する時、いずれにも参照できるよう実コードパターンも含めました。

1. 2026 年の決済 API 地図 — Stripe / 地域王者 / 課金 / ビルダーの 4 陣営

決済 API は「カードを 1 回切るだけ」ではありません。2026 年に 1 つの決済プロダクトが扱う表面積は次のとおりです。

| レイヤ | 役割 | 代表プロダクト |

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

| Acquirer / PSP | カードネットワーク・銀行と直接接続、トランザクション処理 | Stripe, Adyen, Worldpay, Fiserv |

| Aggregator | 複数 PSP を 1 つの 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(OSS)、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 + 銀行口座 + 株式発行を 1 画面で。`$500`

- **Identity**: 30 か国の KYC/KYB、身分証 + セルフィー検証、`$1.50`/チェック

- **Issuing**: Visa/Mastercard カード発行(仮想・物理)、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 年に注目すべき変化 3 点:

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)、リスク管理を 1 社で完結。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 — 韓国の標準

Toss(Viva Republica)が 2020 年に LG U+ の決済事業を買収して設立した Toss Payments は、2026 年現在 **韓国 SaaS・EC のデフォルト** です。新興スタートアップの 80% 以上が最初に Toss Payments を検討します。

強み:

- **韓国における開発者体験は圧倒的**: ハングルドキュメント、コード例、Postman コレクション、さらに KakaoTalk チャンネルでのサポート

- **カカオペイ・ネイバーペイ・サムスンペイ・トスペイを 1 つの SDK で** — 別契約なしでトグル切替

- **無料テスト環境**: 実カードなしで全シナリオを再現可能

- **手数料**: 通常カード 2.5–3.3%、ウォレット 2.2–3.0%、PayCo・カカオペイ +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(旧 Iamport)— 韓国の決済アグリゲータ

PortOne(旧 Iamport、2024 年リブランド)は韓国のあらゆる PSP を 1 つの SDK にまとめる **決済アグリゲータ** です。1 回の統合でトス、KCP、イニシス、ダナル、カカオペイ、ネイバーペイ、PayCo、スマイルペイ、クレジットカード、仮想口座、キャリア決済、海外決済(Stripe / PayPal パススルー)まですべて利用可能。

PortOne を使う理由:

- **PSP を変えてもコードは同じ**: トス → KCP 移行は環境変数 1 行

- **マルチ PSP ルーティング**: PSP A がダウンしたら PSP B に自動フォールバック

- **統合ダッシュボード**: 複数 PSP の取引を 1 画面で照会・返金

- **手数料**: 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 1 社しか使わないなら PortOne レイヤはむしろコスト増になります。

2026 年、PortOne は日本の KOMOJU、インドネシアの Xendit との統合を追加し、東南アジア展開 SaaS のデフォルトとして地位を固めつつあります。

6. KCP / イニシス / ダナル — 韓国クラシック PSP

トス以前の韓国決済市場の 3 強です。

- **KCP(韓国サイバー決済)**: 1999 年設立、NHN の子会社。カード・口座振替・キャリア決済・商品券など全領域対応。大企業導入率が高い(新世界、11 番街、Coupang の一部)

- **イニシス(KG イニシス)**: 1998 年設立、KG グループ。最古参 PSP の 1 つ、保守的業界(公共、教育、金融)で強い

- **ダナル**: 1997 年設立、キャリア決済 1 位。本人認証サービスでも有名

API 表面は 2010 年代初期の設計が多く残っており、キー発行・暗号化・コールバック 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 年、この 3 PSP は RESTful なモダン API へリニューアル中ですが、マイグレーション速度が遅く、PortOne のようなアグリゲータの価値は依然として大きいです。

7. Square + Cash App — Block エコシステム

Square は 2009 年に Jack Dorsey が作ったモバイルカードリーダーから始まり、2021 年に親会社を Block にリブランドして **決済 + 送金(Cash App)+ ビットコイン** 統合フィンテックグループになりました。

**Square(B2B 決済)**:

- **物理端末(POS)が強み**: 米国・カナダ・英国・豪州・日本の飲食店・小売店 80 万店で利用

- **Square Online**: 無料の EC ストアビルダー(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,500 万アクティブユーザ

- **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、Web 決済は 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・EC で 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() にリダイレクト

3 プロダクトのポジション: **Mollie は欧州 SMB**、**Checkout.com は欧州・中東エンタープライズ**、**Braintree は米国・PayPal 親和市場**。韓国でメインに使うケースはほぼなく、グローバル決済オプションの 1 つとして有効化する場合が大半です。

9. Razorpay — インドの決済標準

Razorpay は 2014 年に IIT 卒業生が創業したインド版 Stripe です。2026 年現在、インド決済市場の約 40% を占有。

特徴:

- **UPI(Unified Payments Interface)** がインドのデフォルト: QR スキャンで即時送金、手数料ほぼゼロ

- **GST(インド付加価値税)の自動処理**: 請求書に GST を自動付与

- **Razorpay Capital**: 売上ベースの融資、インドスタートアップの主要資金調達経路の 1 つ

- **手数料**: UPI 無料(`< ₹2,000`)、カード 2%、国際カード 3%

- **API は Stripe に非常に類似**: 創業者が公にモデルにしたと認めている

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(日本最大の EC ビルダー)が作った PSP、「日本の Stripe」を標榜

- API が意図的に Stripe に類似、JavaScript SDK もよく整理されている

- カード決済はクリーン、ウォレットは弱い

- 手数料 3.6%(一律)

**KOMOJU**:

- 外国 SaaS の日本決済進出の標準(Patreon、itch.io、Discord などが利用)

- 日本のクレジットカード + コンビニ決済 + 銀行振込 + PayPay + LINE Pay を統合

- 英語ドキュメント完備、韓国の PortOne のようなアグリゲータ役

- 本社は東京、Degica が運営

**PayPay**:

- ソフトバンク発の QR 決済、日本のアクティブユーザ 6,000 万

- 直接 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 | OSS + Cloud | セルフホスト可能、無料で開始 | 新興、一部機能はまだ発展途上 |

| OpenMeter | OSS、CNCF | 従量メータリング専業、Kafka ベース | 課金自体は別ツールが必要 |

| Orb | SaaS | 複雑な従量モデルに強い、AI 企業御用達 | 高価 |

| Metronome | SaaS | OpenAI、Anthropic、Databricks 採用 | エンタープライズ専用 |

| Maxio(旧 Chargify + SaaSOptics) | SaaS | B2B 特化、MRR/ARR レポーティング強い | モダンな従量モデルは弱い |

**Stripe Billing の基本サブスクリプションモデル**:

// 1) Price 登録(1 回)

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 の魅力(OSS)**:

Docker Compose 1 行でセルフホスト可能

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 価格モデル最大の変化は **シートベース購読から従量ベースへの移行** です。OpenAI(トークン)、Snowflake(コンピュート)、Vercel(ビルド分)、Cloudflare(リクエスト)が標準化し、2026 年にはほぼすべてのインフラ SaaS のデフォルトに。

従量モデルの実装難点:

1. **正確なメータリング**: 毎秒数万イベントを欠損なく集計

2. **遅延請求**: 課金時点で 1 か月分のイベントを集計 → 課金システムに負荷

3. **予算アラート**: ユーザに予想外の高額請求が来ないよう 80%、100% アラート

4. **前払いクレジット + 後払い請求のミックス**: OpenAI モデルが典型例

5. **複数単位の統合**: API 呼び出し + ストレージ GB + 転送 GB を 1 つの請求書に

**Tier(OSS)** は従量課金を SDK 1 行で追加できるツールです。

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

同じリクエストを 2 回送っても同じ結果になるよう保証します。Stripe・Square・Razorpay・Toss Payments すべてサポート。

const intent = await stripe.paymentIntents.create(

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

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

)

要点: **冪等性キーは 24 時間有効**、**同じキーで違うペイロードを送るとエラー**。UUID を 1 回生成してリトライ間で同じ値を使うのが標準パターン。

**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 1 行で処理します。日本は 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 |

| OSS / セルフホスト必須 | Stripe + Lago | — | Lago |

| 店舗 + オンライン | Square(US)/ Adyen | Stripe(Web 部分のみ) | Stripe Billing |

| マーケットプレイス(Uber、Etsy 型) | Stripe Connect | Adyen for Platforms | Stripe Billing |

| B2B 請求書発行重視 | Stripe Billing | Maxio | Maxio |

| ワンクリックチェックアウト重視 | Bolt + Stripe | PayPal + Braintree | Stripe Billing |

**意思決定ヒューリスティック**:

1. **第 1 の質問**: 売上の 50% 以上はどの国か? その国の標準 PSP が第 1 選択

2. **第 2 の質問**: 従量課金はビジネスの中核か? Yes なら課金を PSP と分離(Lago/Orb)

3. **第 3 の質問**: 取引量が月 1 万件未満か? Yes ならセルフサービス可能な Stripe/Toss で開始

4. **第 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/`

현재 단락 (1/456)

2026 年 5 月時点で、決済 API エコシステムは単一のグローバル標準ではなく、**グローバル(Stripe)+ 地域王者(Adyen, Toss Payments, Razorpay, GMO...

작성 글자: 0원문 글자: 19,061작성 단락: 0/456