ソフトウェア プログラミング 公開日 2026.05.15 更新日 2026.05.20

Stripe とは何か?オンライン決済の事実上の標準 API と Checkout / Payment Intents / Subscriptions の使い分け

Stripe はオンライン決済の事実上の標準 SaaS で、「Checkout(できあいの決済画面)」 「Payment Intents(柔軟な決済 API)」 「Subscriptions(サブスク管理)」 「Connect(プラットフォーム / マーケットプレイス)」 を統合的に提供します。何を選ぶべきか、Webhook の使い方、PCI DSS 対応の考え方まで実務目線で整理します。

先に要点

  • Stripe は世界中の SaaS / EC / マーケットプレイスで使われる オンライン決済 SaaS。「カード決済 / 銀行振込 / 各種ローカル決済方法 / サブスクリプション / プラットフォーム手数料」 をまとめて扱える。
  • 主要 APICheckout(できあいの決済画面)」 「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 セキュア画面に遷移、終わったら戻ってくる」 までライブラリ側で処理。

SPA との相性

React / Vue / Svelte などの SPA に綺麗に組み込める。「画面遷移なしで決済完了」 を実現できる。

「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.webhooks.constructEvent」 で署名を検証。「Webhook シークレット」 を環境変数で持ち、悪意のあるリクエストを弾く。

冪等性

「 Stripe は同じイベントを複数回送る可能性がある」。「event.id」 を DB に記録して 「すでに処理済みかチェック」 する設計が必須。

ローカル開発

「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 を必ず実装するのが鉄則

冪等性

「 同じイベントが何度も来る」 ことを想定しないと、「同じ注文を 2 回処理する」 系のバグが起きる。「event.id」 を一意キーとして DB に記録する設計を最初から組む。

③ テストモードと本番

「 テストモードのキーで本番動かす」 / 「本番キーをテストで使う」 のような事故が起きやすい。「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 の全体像が掴めます。

参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。