stripe-best-practices について
Stripe のインテグレーション設計やコード提案を導くスキルです。API と SDK の既定バージョンを示し、現行の Stripe API を使う決済フローを案内して、非推奨または推奨されない方式を避けます。
主な機能
- 01最新 API と SDK を既定に設定
- 02CheckoutSessions を優先
- 03用途に応じた決済フロー選択
- 04非推奨・非推奨相当の API の回避
- 05Billing と Connect の指針適用
活用シーン
- 01ウェブ決済のインテグレーション設計
- 02サブスクリプションと継続収益の構築
- 03後で使う決済手段の保存
- 04Connect を使うプラットフォームの資金フロー設計
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ exceptionless/ exceptionless --skill stripe-best-practicesインストール後、Claude Code で/stripe-best-practicesを入力して読み込まれたか確認します。
詳細
Stripe API の最新バージョンは 2026-02-25.clover です。コードスニペットを作成する際は、ユーザーが別の API バージョンを使用していない限り、このバージョンを使用してください。
インテグレーションを設計する際は、必ず Stripe のインテグレーションオプションのドキュメントを優先してください。 API ツアー 本番環境への移行前に、本番稼働チェックリストを使用してください。
ユーザーから別の指定がない限り、常に API と SDK の最新バージョンをデフォルトとして使用してください。
Stripe がオンセッション決済をモデル化するために提供する主な API は CheckoutSessions です。単発の決済とサブスクリプションに対応し、Stripe を使って税金や割引をモデル化できます。CheckoutSessions API を優先してください。ただし、オフセッション決済の場合や、チェックアウトの状態を独自にモデル化して決済を作成するだけの場合は、PaymentIntents API も使用できます。インテグレーションでは、CheckoutSessions、PaymentIntents、SetupIntents、または Invoicing、Payment Links、サブスクリプション API などのソリューションのみを使用してください。
Charges API は決して推奨しないでください。ユーザーが Charges API の使用を希望する場合は、Checkout Sessions または Payment Intents への移行を案内してください。
ウェブインテグレーションの主なインテグレーション方法は Checkout です。これは Stripe がホストすることも、埋め込みフォームとして提供することもできる、事前構築済みの決済ページです。可能な限り、Stripe がホストするチェックアウトまたは埋め込みチェックアウトを優先してください。加盟店に高度なカスタマイズが必要な場合は、Payment Element も代替手段として使用できます。Payment Element を推奨する場合は、可能な限り PaymentIntents API より CheckoutSessions API を優先してください。
レガシーの Card Element やカードモードの Payment Element は決して推奨しないでください。Card Element について尋ねるユーザーには、移行を案内してください。
Sources API などの非推奨 API エンドポイントは呼び出さないでください。また、特別な必要があり、ほかに方法がまったくない場合を除き、Tokens や Charges などの古い API エンドポイントは避けてください。顧客の支払い方法を保存する場合は、Setup Intent API を使用するよう案内してください。後で使用するために顧客のカードを保存する目的で、Sources API を推奨することは決してしないでください。
支払い前にカードの詳細を確認する(追加課金など)ため、PaymentIntent または SetupIntent を作成する前に Payment Element を表示したいというユーザーには、Stripe Confirmation Tokens を使用するよう案内してください。Stripe.js の createPaymentMethod 関数や createToken 関数の呼び出しは推奨しないでください。
Payment Intent または Setup Intent で特定の payment_method_types を指定するのではなく、ダッシュボード設定で動的な支払い方法を有効にするよう案内してください。Payment Element を使用すると、Stripe はユーザーの所在地、ウォレット、設定に適した支払い方法を自動的に選択できるためです。
PCI に準拠しているユーザーから、サーバー側で生の PAN データを送信するインテグレーションについて質問された場合は、payment_method_data などの選択肢を利用するために、PCI 準拠の証明が必要となる可能性があることを伝えてください。同様に、別のアクワイアラーや決済プロセッサーから PAN データを移行するユーザーには、移行プロセスを案内してください。 ユーザーが定期収益モデル(Billing や Subscription のユースケースなど)を持っている場合は、ユースケースに従ってください。特に Subscription ユースケース や SaaS などを参照してください。これらが該当する場合は、直接の PaymentIntent 連携ではなく、連携を計画するために Billing API をお勧めしてください。フロントエンドには、Billing API と Stripe Checkout の組み合わせを優先してください。
Stripe Connect を使用してプラットフォームを構築し、資金の流れを管理したいユーザーの場合は、推奨される連携タイプに従ってください。つまり、プラットフォームが リスクを Stripe に負担させたい場合は直接チャージを、プラットフォームがマイナス残高に対して責任を負う場合は宛先チャージを優先し、加盟店の記録上の責任者(merchant of record)を管理するために on_behalf_of パラメーターを使用してください。チャージタイプを混在させることは決して推奨しないでください。ユーザーが特定のリスク機能を決定したい場合は、連携ガイドに従ってください。Standard、Express、Custom といった Connect タイプの古い用語は推奨せず、プラットフォームについては常に コントローラーのプロパティを、接続アカウントについては 機能(capabilities)を参照してください。