決済ゲートウェイ
※ Stripeのドキュメントをベースにしているため、日本の決済慣習からすると違和感のあるものが混じっているかもしれません
決済プロセスの基本用語
Authorization（オーソリゼーション / 与信承認）
カード発行銀行（Issuer）が、購入者の利用可能枠・残高を確認し、取引金額分を一時的に確保（ホールド）するプロセス。この時点では加盟店への支払いは発生せず、購入者の利用可能額が減算される。承認コードが返却されることで、加盟店は「支払いが保証された」状態となる。有効期限は通常7～30日（業種により異なる）。
Capture（売上確定）
Authorizationで確保した金額を売上として確定させるプロセス。出荷完了・サービス提供完了時に実施される。この時点で購入者への課金が確定し、清算プロセスが開始される。Authorizationの有効期限内に実施しないと自動的にキャンセルされる。
Settlement（清算・入金）
確定した売上金額が、カードネットワーク・PSP（決済サービスプロバイダ）を経由して加盟店・店舗の口座に着金するプロセス。通常T+1～T+3（取引日から1～3営業日後）で入金される。業種・契約形態・決済手段により入金サイクルが異なる。
/icons/hr.icon
決済ゲートウェイ統合パターン
※ 4, 5は直交した概念で、1〜3と合わせて使うこともある。
1. ホスト型決済ページ（HPP / Redirect）
決済ゲートウェイベンダがホストする決済画面にリダイレクトする。UIは限定的だが規制要件を肩代わりする。
メリット
PCI DSS負担が小さい（多くはSAQ A相当）
多手段（3DS/現地決済/コンビニ等）を一括吸収できる
実装がミニマルですむ
デメリット
完全なUI一貫性は取りづらい
細かな入力制御は制限される
代表的なゲートウェイ/機能
Stripe Checkout
Checkout.com Hosted Payments Page
Authorize.Net Accept Hosted
2. Hosted Fields / Elements（埋め込みカード入力）
カード入力欄のみをiFrameなどで提供する。
メリット
自社UIとブランド統一が可能
PCI DSS範囲が小さい（多くはSAQ AまたはA-EP）
デメリット
実装はHPPよりは多くなる
代表的なゲートウェイ/機能
Stripe Elements
Braintree Hosted Fields（SAQ A狙いのiFrame）
Authorize.Net Accept.js（自前フォーム+JSでトークン化
3. Direct API Integration
自サイトでカードデータを受け取り、決済APIをコールする。
メリット
UX・フロー制御の自由度が最大。複雑な与信/捕捉/分配に柔軟
デメリット
カード番号を受け取るので、PCI負担が最大（通常SAQ D/A-EP）。
代表的なゲートウェイ/機能
Stripe Payment Intents
Adyen Checkout API
Authorize.Net Payment Transactions API
4. Network Tokenization / Wallets
デバイス/ネットワーク側でPANをトークン化する。
メリット
PAN曝露を避けられる。SCA/3DS相当のUX改善。失効やカード更新に強い
デメリット
ドメイン登録/商用証明書など導入要件。対応ネットワークはゲートウェイ依存
代表的なゲートウェイ/機能
Apple Pay
Google Pay
PayPal Checkout
5. 非同期手段＋Webhook駆動
即時確定しない手段は、ゲートウェイ側から非同期でWebhookで通知をもらい状態を遷移させる。
メリット
在庫・出荷と整合する堅牢な状態遷移を実装できる。
デメリット
Webhook処理・再送耐性・冪等性の設計が不可欠。
代表的なゲートウェイ/機能
Stripe Webhooks
Adyen Webhooks
Webhookの役割と設計原則
非同期手段の確定通知コンビニ決済、銀行振込、ACH、iDEALなど、即時に結果が返らない手段では、顧客が実際に支払いを完了した時点でゲートウェイがWebhookを送信する。アプリケーション側はこの通知を受けて注文ステータスを更新し、出荷や商品提供を開始する。
Capture完了の通知Auth/Captureパターンでは、Capture APIを呼び出した後、実際の清算処理が完了するまでに数秒～数分かかる場合がある。この完了タイミングをWebhookで通知することで、在庫確定や会計システムへの連携を確実に行える。
Chargeback・Dispute通知顧客が異議申立てを行った場合、ゲートウェイはWebhookで加盟店に通知する。これにより、加盟店は証拠資料を準備し、チャージバック防御を行うことができる。
冪等性と再送耐性Webhookは再送される可能性がある（ネットワークエラー、タイムアウト等）。受信側はイベントIDやトランザクションIDをキーに冪等処理を実装し、同じ通知を複数回処理しても状態が壊れないようにする必要がある。
署名検証とセキュリティWebhookエンドポイントは公開URLであるため、HMAC署名検証（Stripe: Stripe-Signature ヘッダ、Adyen: HMAC検証）を必ず実装し、正当なゲートウェイからの通知であることを確認する。
リトライポリシーとフェイルオーバーWebhook受信側が一時的に応答できない場合、ゲートウェイは指数バックオフでリトライする（例: Stripeは最大3日間リトライ）。受信側はHTTP 2xx を速やかに返し、後続処理はキューやバックグラウンドジョブで非同期に行うのがベストプラクティス。
決済フローのパターン
① Sale（Immediate Capture｜即時売上）
別名
Purchase
Charge Immediately
基本ステップ構造
Authorization + Capture を一括で実施する。
API単一呼出で売上確定する。
主な用途／シナリオ
デジタルコンテンツ、サブスクリプション初回決済、小額即時提供。
メリット
実装が単純。UXが速い。失敗時の在庫巻き戻し不要。
デメリット
出荷前に決済が確定するため返品・返金リスクが高い。
対応ゲートウェイ例
Stripe: confirm=true 即時確定
② Auth/Capture（与信→売上確定分離）
基本ステップ構造
Authorizationで与信枠確保、出荷時にCaptureで確定。
主な用途／シナリオ
物理商品の出荷連動、宿泊・レンタカー、分割納品。
メリット
出荷確定まで課金を遅延できる
部分捕捉・在庫連携が容易
デメリット
有効期限切れやキャンセル処理が複雑。
対応ゲートウェイ例
Stripe: PaymentIntent with separate capture
Adyen: /payments + /captures
Braintree: authorize() + submitForSettlement()
③ Incremental / Partial Capture（部分・追加確定）
基本ステップ構造
初回Auth後に複数回Captureする
追加Captureも許容する
主な用途／シナリオ
予約金＋追加請求
ホテル・レンタカー・出前アプリ
メリット
顧客体験の柔軟性
部分出荷に対応できる
デメリット
対応ブランド・PSPが限定される。
残高管理が複雑。
対応ゲートウェイ例
Adyen: "Incremental Authorization"
Stripe: "Multiple capture for the same authorization"
④ Delayed Capture（売上遅延確定）
基本ステップ構造
Authを保持し、一定時間後（出荷確定時）に自動または手動Captureする。
主な用途／シナリオ
倉庫出荷バッチ処理
在庫確認後課金
メリット
顧客トラブル時の対応柔軟
デメリット
Capture遅延で与信失効リスクがある
対応ゲートウェイ例
Stripe: capture_method=manual + 自動期限設定
Adyen: captureDelayHours オプション
⑤ Pre-Authorization Only（仮押さえ）
基本ステップ構造
与信のみ実施し、Captureせず最終確定を別取引で行う
主な用途／シナリオ
レストランやホテル等、予約時には利用額未確定の業態
メリット
顧客残高確保できる
金額変更に対応できる
デメリット
未使用の与信枠解放漏れに注意必要
⑥ Refund（返金）／Partial Refund
基本ステップ構造
完了済トランザクションの部分または全額返金する
主な用途／シナリオ
返品、過剰請求修正
キャンセル
メリット
不正防止
デメリット
リアルタイムでない（清算後処理）
対応ゲートウェイ例
Stripe: /refunds API
Adyen: /refund request
⑦ Reversal / Void（取消）
基本ステップ構造
Capture前のAuthを取り消し（売上未確定）
主な用途／シナリオ
在庫切れ
注文キャンセル
メリット
顧客残高を即時解放
デメリット
Capture済後は不可
対応ゲートウェイ例
Stripe: cancel PaymentIntent
Adyen: /cancels API
⑧ Retry / Soft Decline再試行
基本ステップ構造
Auth失敗時、SCAやリスク判断により再認証を誘発
主な用途／シナリオ
PSD2/SCA対応のリスクベース認証
メリット
UX改善（摩擦削減）
Cons
実装が煩雑、再試行管理が必要
対応ゲートウェイ例
Stripe: requires_action 状態→3DS2再試行
Adyen: "Challenge Shopper"フロー
⑨ Asynchronous Confirmation（非同期確定）
基本ステップ構造
即時完了しない決済（振込、ACH、コンビニ、iDEAL）をWebhookで確定する
主な用途／シナリオ
振込・ACH・銀行送金・QR決済など
メリット
多様な手段を扱える
再送耐性が高い
デメリット
状態遷移設計が複雑になる
対応ゲートウェイ例
Stripe: Konbini, ACH Debit
Adyen: iDEAL, Sofort
⑩ Recurring / Subscription（継続課金）
基本ステップ構造
初回与信後、スケジュールに基づき自動Capture
主な用途／シナリオ
サブスクリプション、会費制、SaaS
メリット
LTV向上
デメリット
失効カード処理・更新管理が必要
対応ゲートウェイ例
Stripe Billing
Adyen Recurring
Braintree Subscription
⑪ Split Settlement（分配精算）
基本ステップ構造
Capture後に複数受益者へ分配（または留保・再配分）する
主な用途／シナリオ
マーケットプレイス
プラットフォーム型EC。
メリット
会計・税務を自動化可能
デメリット
規制・資金決済法対応が複雑
対応ゲートウェイ例
Adyen for Platforms
PayPal for Partners
⑫ Chargeback / Dispute Handling
基本ステップ構造：**顧客が異議申立てを行い、カード会社が調査・返金を指示。
主な用途／シナリオ
不正利用
返品トラブル
決済方法の分類
カード系
Visa / Mastercard / American Express / JCB / Diners / Discover
Auth（与信）：〇
Capture（売上確定）：〇
Settlement（清算）：〇（T+1〜T+3）
特徴：標準的な二段階モデル。Authで利用枠ホールド→Captureで売上確定→ネットワーク清算。
ブランドデビットカード（Visaデビットなど）
Auth（与信）：〇
Capture（売上確定）：〇
Settlement（清算）：〇（即時〜翌日）
特徴：デビット残高の即時差引→売上確定。JCBデビットでは「利用情報（即時引落）→売上確定データ」の二段階を明示。JCBデビットの仕組み プリペイドカード / ギフトカード
Auth（与信）：〇
Capture（売上確定）：〇
Settlement（清算）：〇
特徴：残高差引型。Authで仮押さえ→Captureで減算確定
ウォレット系
Apple Pay / Google Pay / Link by Stripe / PayPal (via Stripe Connect)
Auth（与信）：〇
Capture（売上確定）：〇
Settlement（清算）：〇（カード清算に準拠）
特徴：カードネットワークを利用するだけのペイメントゲートウェイに過ぎない。トークン化によりPANを扱わない。
Alipay / WeChat Pay / PayPay / GrabPay / PayNow / Kakao Pay
Auth（与信）：×
Capture（売上確定）：△
Settlement（清算）：〇（T+1〜T+3）
口座引落系（Bank Debit）
ACH Debit（米国） / BECS（豪） / SEPA Direct Debit（欧州）
Auth（与信）：−
Capture（売上確定）：−
Settlement（清算）：〇（T+2〜T+5 バッチ清算）
特徴：事前同意（マンダート）に基づく口座振替。Auth/Captureの概念は原則なし。リターン期間がある（非同期確定）。
Japan J‑Debit（国内オンラインデビット）
Auth（与信）：（利用情報で即時残高確保）
Capture（売上確定）：（売上確定データで確定）
Settlement（清算）：〇（即時）
銀行送金／リアルタイム送金（Bank Transfer）
Bank Transfer（日本・EU・UKなど）
Auth（与信）：×
Capture（売上確定）：×
Settlement（清算）：〇（T+1〜T+2）
特徴：顧客ごとに仮想口座を発行、入金確認で確定。Webhook必須。
SEPA Credit Transfer / Faster Payments / CHAPS
Auth（与信）：×
Capture（売上確定）：×
Settlement（清算）：〇（即時〜翌日）
特徴：プッシュ送金型。Auth/Captureなし。
RTP / Pix（ブラジル） / UPI（インド）
Auth（与信）：×
Capture（売上確定）：×
Settlement（清算）：〇（即時最終性）
特徴：即時清算。入金即確定。リバーサル不可。
バウチャ／現金代替系（Vouchers）
コンビニ支払い（Konbini Payments – Japan）
Auth（与信）：×
Capture（売上確定）：×
Settlement（清算）：〇（入金時確定、T+N清算）
特徴：バウチャ番号発行→店頭現金払い→Webhookで確定（例: Stripe Konbini）。
OXXO（メキシコ） / Boleto Bancário（ブラジル） / Multibanco（ポルトガル）
Auth（与信）：×
Capture（売上確定）：×
Settlement（清算）：〇（入金時確定）
特徴：バウチャ型現金決済。非同期。
現金決済（POS現金取扱い連携）
Auth（与信）：×
Capture（売上確定）：×
Settlement（清算）：〇（即時）
特徴：Stripe Terminal 等で現金入力を記録可能（POSレベル）。
ギフトカード（Stripe Issuing / Prepaid Card Program）
Auth（与信）：〇
Capture（売上確定）：〇
Settlement（清算）：〇
特徴：自社ブランドのプリペイド/ギフト発行が可能（実装上はカード型）。
後払い／分割（Buy Now Pay Later）
Klarna / Affirm / Afterpay (Clearpay) / Paidy（日本）
Auth（与信）：△（信用枠審査）
Capture（売上確定）：〇
Settlement（清算）：〇（PSPが加盟店へ即支払い、顧客から後日回収）
特徴：Authは信用審査、Captureで加盟店売上確定。
エスクロー／条件付預託（Escrow）
AliExpress / Stripe Connect Escrow（Custom Accounts 等）
Auth（与信）：△
Capture（売上確定）：△
Settlement（清算）：〇（条件達成後リリース）
交通系
交通系IC（Suica / PASMO オンライン決済）
Auth（与信）：×
Capture（売上確定）：〇
Settlement（清算）：〇（即時〜T+1）
特徴：残高差引（プリペイド）型。Authなし。
後払い交通系 PiTaPa（日本）
Auth（与信）：△
Capture（売上確定）：×
Settlement（清算）：〇（月次口座引落）
特徴：与信契約あり。月次一括清算。
通信キャリア決済（DCB）
d払い / auかんたん決済 / ソフトバンクまとめて支払い / Boku 等
Auth（与信）：×（カード与信なし）
Capture（売上確定）：〇（即時確定相当）
Settlement（清算）：〇（キャリア経由の締め支払い。T+Nの契約依存）
特徴：カード・銀行網に非依存。年齢・限度額・商材カテゴリ制限あり。高承認率。返金はキャリア経由の調整フロー。
マーケットプレイス分配／プラットフォーム型
Stripe Connect（Standard / Express / Custom）
Auth（与信）：〇
Capture（売上確定）：〇
Settlement（清算）：〇（Transfer/Payout段階で最終）
特徴：基底決済完了後、分配先アカウントへのPayoutでSettlement完了。
まとめると…
Authあり・Captureあり・Settlement後行：カード／BNPL／ウォレット（カード準拠）
Authなし・Capture即・Settlement即：リアルタイム送金／QRウォレット
Authなし・Captureなし・非同期Settlement：バウチャ／コンビニ／銀行振込
Auth相当あり・Capture遅延・Settlement遅延：後払い・エスクロー・交通系後払い