先に要点
- Stripe は世界中の SaaS / EC / マーケットプレイスで使われる オンライン決済 SaaS。「カード決済 / 銀行振込 / 各種ローカル決済方法 / サブスクリプション / プラットフォーム手数料」 をまとめて扱える。
- 主要 API は Checkout(できあいの決済画面)」 「Payment Intents(柔軟な決済 API)」 「Subscriptions(サブスク管理)」 `Connect(プラットフォーム向け / 出品者への支払い) の4本柱。「どれを使うか」 で実装が大きく変わる。
- 状態の最終確認は Webhook で行う。「クライアントの戻り URL」 ではなく 「サーバが Stripe から受け取る Webhook」 を信頼するのが鉄則。
- PCI DSS は カード番号を自社で保持しない設計 にすれば Stripe 側が大半をカバーする。「Stripe.js / Elements / Checkout / Hosted Page」 を使えば、カード番号は自社サーバを通らない。
Stripe って結局何ができるの? Checkout と Payment Intents、どっち使えばいいの? 「Webhook って何が大事?」 ── SaaS / EC / マーケットプレイスを作るなら必ず通る道が Stripe です。
ざっくり言うと、Stripe は オンライン決済まわりの面倒な仕組み(カード処理 / 各国対応 / 不正検知 / 課金管理)を、API として提供する SaaS です。 「自分で決済処理を実装すると、PCI DSS / 各カードブランド対応 / 不正検知 / 各国の決済方法 …」 という膨大な作業が必要になりますが、Stripe を使うとそれを API を呼ぶだけ に圧縮できます。
この記事では、2026 年 5 月時点の Stripe をベースに、主要 API・どれを選ぶか・Webhook・PCI DSS 対応・採用判断軸 を整理します。 仕様は活発に変化しているので、最終確認は 公式ドキュメント を見るのが安全です。
Stripe の主要 API — 4 本柱
Stripe が提供する API は数多いですが、まず 4つの主要グループ を押さえると全体像が見えます。
| 機能 | 用途 | 主な選び所 |
|---|---|---|
| Checkout | 「 できあいの決済画面」 をホスト | 「 最速で決済を導入したい」 |
| Payment Intents + Elements | 自分のサイトに決済 UI を埋め込む | UX をカスタムしたい / SPA |
| Subscriptions | 定期課金の管理 | SaaS のサブスクリプション |
| Connect | プラットフォームの出品者へ支払い | マーケットプレイス / フリーランス案件サイト |
「サイトの種類 = どの API を使うか」 が決まる、と言える構造です。
Checkout — 最速の決済導入
「 Stripe で決済を始めたい」 ときに、まず候補に挙がるのが Checkout です。
// サーバ側(Next.js Route Handler / Express / Hono など)
const session = await stripe.checkout.sessions.create({
mode: 'payment',
line_items: [
{ price: 'price_xxx', quantity: 1 },
],
success_url: 'https://example.com/success?session_id={CHECKOUT_SESSION_ID}',
cancel_url: 'https://example.com/cancel',
});
return Response.redirect(session.url);
これだけで Stripe がホストする決済画面に飛ばす が完成します。「カード番号入力 UI / 3D セキュア / 国別決済方法」 すべて Stripe 側で持ってくれます。
利点
① 数十行で決済導入、② カード番号が自社サーバを一切通らない、③ デザインは Stripe 側で自動最適化、④ 多通貨 / 多決済方法を勝手に対応。
制約
「 別画面に遷移する」 のがユーザー体験として浮く場面がある。「自社サイト内で完結したい」 ニーズには Payment Intents + Elements が向く。
embed モード
「 Checkout を自社サイトに埋め込む」 モードも存在し、「完全別画面と完全自前 UI の中間」 として選べる。
サブスクとの組み合わせ
「 mode: 'subscription'」 にすれば、Checkout でサブスク開始までを完結できる。「SaaS の最速の課金実装」 として人気。
「まず Checkout で動かす → 必要なら Payment Intents に切り替える」 が、Stripe 導入の標準的なルートです。
Payment Intents + Elements — 柔軟な決済 UI
「 自社サイト内で決済 UI を完結したい」 場合、Payment Intents + Stripe Elements を使います。
// サーバ側で PaymentIntent を作成
const intent = await stripe.paymentIntents.create({
amount: 5000,
currency: 'jpy',
automatic_payment_methods: { enabled: true },
});
return Response.json({ clientSecret: intent.client_secret });
// クライアント側(Stripe Elements)
import { Elements, PaymentElement } from '@stripe/react-stripe-js';
<Elements stripe={stripePromise} options={{ clientSecret }}>
<form onSubmit={handleSubmit}>
<PaymentElement />
<button>決済</button>
</form>
</Elements>
Payment Intents とは
「 決済の意図」 を表すサーバ側のオブジェクト。「いくらを、誰から、どの方法で取るか」 を最初に作成して、「client_secret」 をクライアントに渡す。
Stripe Elements
「 クライアントで使える決済 UI コンポーネント」。「PaymentElement」 を貼るだけで、カード / Apple Pay / 各種決済方法に対応した UI が出る。
3D セキュア
3D セキュア(SCA)対応も自動。「カードが要求すれば 3D セキュア画面に遷移、終わったら戻ってくる」 までライブラリ側で処理。
「Checkout で物足りない / カスタム UI が欲しい」 ようになったら、Payment Intents + Elements に移行する、というのが現実的な流れです。
Subscriptions — サブスクリプション管理
SaaS の中心機能 「定期課金」 を扱う API です。
Product / Price モデル
「 Product(商品)」 と 「Price(価格)」 を分けて管理。「Pro プラン(Product)を月 $20 / 年 $200(Price)」 のような構造。
Subscription オブジェクト
「 どのユーザーが、どの Price を契約しているか」 を表すオブジェクト。「status: active / past_due / canceled」 のような状態遷移がある。
Trial / Coupon / Tax
「 無料トライアル」 「割引クーポン」 「自動税計算(Stripe Tax)」 が標準サポート。「SaaS の課金まわりで欲しいもの一通り」 が揃う。
Customer Portal
「 Stripe ホストの顧客ポータル」 を 「1 リンク発行」 で提供。「プラン変更 / 支払い方法更新 / 領収書ダウンロード / 解約」 を自社実装せずに済む。
「SaaS のサブスク機能を自前で書くと数週間」 という作業を、Stripe + Customer Portal で 数時間に圧縮 できるのが大きな価値です。
Webhook — 真実の通知
Stripe で最重要なのが Webhook です。
// app/api/webhooks/stripe/route.ts
export async function POST(req: Request) {
const sig = req.headers.get('stripe-signature')!;
const body = await req.text();
let event;
try {
event = stripe.webhooks.constructEvent(body, sig, WEBHOOK_SECRET);
} catch {
return new Response('invalid signature', { status: 400 });
}
switch (event.type) {
case 'checkout.session.completed':
// ここで 「本当の決済完了」 を確認 → DB 更新
break;
case 'invoice.payment_failed':
// 支払い失敗の処理
break;
case 'customer.subscription.deleted':
// 解約処理
break;
}
return new Response('ok');
}
なぜ Webhook が必要か
「 Checkout が成功したと思ったら、後で銀行から拒否される」 「クライアントが success URL を改ざんする」 などのリスクがある。本物の最終決済結果は Stripe サーバが Webhook で知らせる。
ローカル開発
「stripe-cli」 の 「stripe listen --forward-to localhost:3000/api/webhooks/stripe」 で ローカルに Webhook を転送 できる。「本番でしかテストできない」 を解消。
「Webhook を信頼することが Stripe を本番運用するうえで一番大事なルール」 と言えるくらいの重要度です。
Connect — マーケットプレイス
「複数の出品者がいて、買い手から受け取った金額を出品者に分配する」 タイプのサービス向け API です。
Connect とは
「 プラットフォーム」 と 「出品者(Connected Accounts)」 をつなぐ仕組み。「Airbnb / Uber / Etsy / Lyft」 のような構造を、Stripe の API で実現できる。
Express / Standard / Custom
「 出品者のオンボーディング」 を Stripe 側でホストするか自前で作るかで3種類。「Express」 は 「Stripe がホスト」 で最も簡単。
手数料
「 プラットフォーム手数料」 を 「application_fee_amount」 で取れる。「売上の 10% をプラットフォームが取って、残りを出品者に」 のような設計が API レベルで完結。
本人確認 / KYC
「 出品者の本人確認 / 銀行口座登録」 を Stripe が代行。「AML / KYC 規制対応」 を自前で構築するコストを圧縮できる。
「普通の SaaS には不要」 ですが、「マーケット型サービス」 では事実上必須レベルです。
いつ Stripe を使うか
採用判断の目安を整理します。
向いている
① SaaS のサブスク課金、② 単発の EC 決済、③ プラットフォーム / マーケット型サービス、④ グローバル展開予定、⑤ 開発者中心のチーム。
他選択肢
「 日本国内中心 / 銀行振込重視」 なら GMO / Paypay 経由、「物販 EC」 なら Shopify 統合、「既存 PayPal アカウントが大量」 なら PayPal Subscriptions も検討。
対応国
「 Stripe は世界 40+ ヵ国対応」。日本でも普通に使える(2016 年から正式対応)。「日本円・日本のカード・日本の銀行振込(Pay-easy)」 が利用可能。
料金感
「 決済1件あたり 3.6%」(2026 年現在、国際カードはやや高め)。「月額の固定料金はない」、「使った分だけ」 の従量。`SaaS の事業計画では 「手数料 4%」 程度で見積もる」 のが安全側。
「グローバル / 開発者向け / 柔軟さ」 が必要なら、Stripe 一択に近い状況です。
どこで詰まりやすいか
便利な反面、現場で踏みやすい注意点も整理します。
①Webhook の処理漏れ
「 Webhook を実装しないで Stripe を使う」 = 重大バグの温床。「success_url で完了扱いにする」 と、ユーザーが改ざんしたり、後から決済が失敗したときに気づけない。Webhook を必ず実装するのが鉄則。
③ テストモードと本番
「 テストモードのキーで本番動かす」 / 「本番キーをテストで使う」 のような事故が起きやすい。「Vercel の Production / Preview / Development」 のように環境別に Stripe キーを分けるのが基本。
④ 税(Tax)
「 各国 / 各州の税計算は複雑」。「Stripe Tax」 を使うか、「自前で計算」 かの判断が必要。日本国内中心なら 「消費税のみ」 で済むが、海外展開すると 「VAT / GST / Sales Tax」 が絡んでくる。
「決済は失敗できない領域」 なので、「Webhook + 冪等性 + テスト環境分離」 の3点は絶対に手を抜けません。
PCI DSS の考え方
「カード決済を扱う = PCI DSS 対応が要る」 と聞いてビビる人が多いですが、Stripe を使う前提では大きく軽減されます。
基本ルール
自社のサーバを経由してカード番号を扱わない 設計にすれば、PCI DSS の対象範囲は最小限になる。
Stripe.js / Elements
「 クライアント側の Stripe.js から直接 Stripe サーバに送る」 ので、自社サーバはカード番号を受け取らない。これだけで 「SAQ A」 という最も簡易な PCI DSS レベルに収まる。
Checkout / Customer Portal
Stripe がホストする画面でカード入力 → さらに分離度が高い。「SAQ A-EP / A」 で済む。
自前で受け取る場合
「 独自フォームでカード番号を自社サーバに送る」 設計を取ると、「SAQ D」 という最も厳しい監査が必要になる。「Stripe を使う限り、絶対にこれは避ける」。
「Stripe.js / Elements / Checkout を使う限り、PCI DSS の負担はほぼゼロに近い」 のが、Stripe を選ぶ大きな理由のひとつです。
AI 時代の Stripe
AI 連携で Stripe の役割も拡大しています。
AI SaaS の課金
「 AI 利用量に応じた課金(Usage-based billing)」 を Stripe Meters で実装できる。「AI 1 リクエストごとに $0.01」 のような従量モデルを綺麗に組める。
AI エージェントの決済
「 AI エージェントが代理で決済する」 という未来形の用途で、「Stripe Identity」 などの本人確認 API が活躍する見込み。
Atlas + AI スタートアップ
「 Stripe Atlas」 で米国法人を立てて、「AI スタートアップを Stripe + Vercel + Supabase で運用」 する流れが定着。
Customer Portal × AI チャット
「 AI サポートが Customer Portal を案内 → 自動で支払い方法更新 / プラン変更」 のようなフローが組みやすくなっている。
「AI プロダクトの収益化基盤」 として、Stripe は今後も中心的な役割を担います。
Stripe に関するよくある質問
Q. Stripe は日本で使えますか?
A. 使えます。2016 年から日本で正式サービスを提供しており、「日本円・日本のカード・銀行振込(Pay-easy)・コンビニ決済の一部」 をサポートしています。日本の法人で 「Stripe Japan」 と契約する形になります。
Q. Checkout と Payment Intents、最初はどっちにすべき?
A. まず Checkout で動かすのが王道です。「数時間で決済が動く」 体験を最初に作り、「UX をもっと自社サイト内で完結したい」 になった段階で Payment Intents に切り替えるのが現実的です。
Q. Webhook を使わずに success_url で完了扱いにできますか?
A. 技術的には可能ですが、本番では絶対に避けるべきです。「success_url の URL を改ざん」 「決済が後から失敗した」 などのケースで、「お金は払われていないのに商品を渡してしまう」 事故が起きえます。Webhook の実装は事実上必須です。
Q. Stripe Atlas とは?
A. 米国法人(Delaware C-Corp)を立てる支援サービスです。「Stripe アカウント + 米国法人 + 米銀行口座 + EIN 番号」 がパッケージで $500 程度で取得できます。スタートアップの海外展開で人気です。
Q. 月額の固定料金はかかりますか?
A. ありません(2026 年現在)。「決済1件ごとの手数料(国内 3.6%、国際 4.0% 前後)」 だけが基本のコスト。「Stripe Tax」 「Stripe Identity」 などのオプション機能は追加料金で利用できます。
Q. Stripe.js を使えば PCI DSS は不要ですか?
A. 不要ではなく 「軽くなる」です。「SAQ A」 という簡易自己申告でほぼ済むようになり、「大手企業以外の SAQ D」 のような重い対応は回避できます。「カード情報を直接扱わない」 のが Stripe を選ぶ大きな利点です。
Q. Stripe を学ぶ最短ルートは?
A. ① テストモードで 「Checkout で 1 件だけ決済」、② Webhook を実装して 「checkout.session.completed」 を DB に記録、③ サブスクを作って Customer Portal を試す、④ Stripe CLI でローカル開発、の4ステップが王道です。「Checkout を動かして Webhook を受ける」 ところまでで、Stripe の全体像が掴めます。