Checkout Sessions API を使用した Payment Element へ移行する
1 つの Element で多くの決済手段を受け付けながら、税金、配送料、割引、通貨換算なども管理できます。
以前は、各決済手段 (カード、iDEAL など) に個別の Element が必要でした。Payment Element に移行すると、1 つの Element で多くの決済方法を受け付けられます。Payment Intents から Checkout Sessions に移行することで、追加機能を使用できます。これにより、実装でサブスクリプション、割引、配送、通貨換算を管理できるようになります。
Card Element を PaymentIntents または SetupIntents と併用していて、Payment Element への移行のみを行う場合は、Payment Element に移行するをご覧ください。ユースケースに合わない場合は、他の決済実装を比較することもできます。
PaymentIntents と SetupIntents には、それぞれ独自の移行ガイドラインがあります。サンプルコードを含む、実装パスの適切なガイドを参照してください。
既存の実装で今後の決済に Payment Intents API を使用している場合は、1 回限りの決済を作成・追跡するか、決済中にカードの詳細を保存します。以下の手順に従って、Payment Element と Checkout Sessions 使用します。
支払い方法を有効にする
注意
この導入パスは、Automated Clearing Settlement System (ACSS) を使用する BLIK またはプレオーソリデビットに対応していません。
決済手段の設定を表示して、対応する予定の決済手段を有効にします。Checkout セッションを作成するには、決済手段を 1 つ以上有効にする必要があります。
多くの顧客から決済を受け付けられるよう、Stripe では、カードやその他一般的な決済手段がデフォルトで有効になっていますが、ビジネスや顧客に適した追加の決済手段を有効にすることをお勧めします。プロダクトと決済手段のサポートについては決済手段のサポートを、手数料については料金体系ページをご覧ください。
PaymentIntent 作成コールを移行するサーバー側
2025-03-31.
API バージョン以降を使用するよう SDK を設定します。
Payment Element では複数の決済手段を受け付けられるため、Checkout Session に payment_
を渡さないと自動的に有効になる dynamic payment メソッドを使用することをお勧めします。これを有効にすると、Stripe は通貨、決済手段の制限、その他のパラメーターを評価して、顧客が利用できる決済手段のリストを決定します。購入完了率が高く、顧客の通貨と場所に最も関連性の高い決済手段を優先します。
代わりに、PaymentIntent 作成コールを更新して Checkout Session を作成します。Checkout Sessions インスタンスでは、以下を渡します。
line_
:注文の内容を表しますitems ui_
: 埋め込みコンポーネントを使用していることを示しますmode: custom mode: payment
:Checkout Session の 1 回限りの支払いを受け付けることを示しますreturn_
顧客が決済手段のアプリまたはサイトで決済を認証またはキャンセルした後にリダイレクトされる URL を表します。url
さらに、Checkout Session の client_secret をクライアント側に返して、後で使用するようにします。
各 Checkout Session は、確認時に PaymentIntent を生成します。PaymentIntent の作成時に現在の実装から追加のパラメータを保持する場合は、payment_intent_data で使用可能なオプションを参照してください。
オプションCheckout Session の追加オプションサーバー側
Checkout Sessions は、決済の回収に影響する追加オプションを受け入れます。
プロパティ | タイプ | 説明 | 必要 |
---|---|---|---|
mode |
| Payment Element が PaymentIntent、SetupIntent、または Subscription のいずれで使用されるかを示します。 | あり |
line_ |
| 顧客が購入しているアイテムのリスト。設定可能なパラメーターの詳細をご覧ください。 | はい payment モードと subscription モードの場合) |
automatic_ |
| このパラメーターを有効にすると、Checkout は税金の計算に必要な請求先住所情報を収集します。 | なし |
allow_ |
| ユーザーが引き換え可能なプロモーションコードを有効にします。 | なし |
billing_ |
| Checkout が顧客の請求先住所を収集するかどうかを指定します。既定値は auto です。 | なし |
payment_ |
| この Checkout Session で受け付けられる決済手段 (カードなど) のタイプのリスト。動的な決済手段を使用している場合、これは必要ありません。 | なし |
phone_ |
| セッションの電話番号収集設定を制御します。payment モードと subscription モードで設定できます。 | なし |
shipping_ |
| 設定すると、Checkout が顧客から配送先住所を収集するための設定が提供されます。 | なし |
shipping_ |
| このセッションに適用する配送料オプション。最大 5 つ。 | なし |
customer_ |
| セッションにまだ渡されていない Customer が Checkout Session で作成されるかどうかを制御します。このオプションは、payment モードと setup モードで設定できます。 | なし |
顧客のメールアドレスを収集するクライアント側
埋め込みコンポーネントに移行するには、顧客のメールを収集する追加の手順が必要です。
Payment Element を追加するクライアント側
Card Element と個々の payment メソッドの Element を Payment Element に置き換えることができるようになりました。Payment Element は、決済手段と国に基づいて入力フィールドを収集するように自動的に調整されるため (たとえば、SEPA ダイレクトデビットの全請求先住所の収集)、カスタマイズされた入力フィールドを維持する必要がなくなります。
次の例では、CardElement
を PaymentElement
に置き換えます。
送信ハンドラを更新するクライアント側
stripe.
や stripe.
などの個別の確認方法を使用する代わりに、checkout.confirm を使用して決済情報を収集し、Stripeに送信します。
Checkout Session を確定するには、個々の confirm メソッドの代わりに checkout.
を使用するように送信ハンドラを更新します。
呼び出されると、checkout.
は、3DS ダイアログを表示したり、銀行のオーソリページにリダイレクトしたりするなど、必要なアクションの完了を試みます。確認が完了すると、顧客は設定したreturn_
にリダイレクトされます。これは通常、決済のステータスを提供するウェブサイトのページに対応します。
カード決済で同じ決済フローを維持し、リダイレクトベースの決済手段でのみリダイレクトする場合は、redirect を if_
に設定できます。
次のコード例では、stripe.
を checkout.
に置き換えています。
// Create the PaymentIntent and obtain clientSecret const res = await fetch("/create-intent", { method: "POST", headers: {"Content-Type": "application/json"}, }); const {client_secret: clientSecret} = await res.json(); const handleSubmit = async (event) => { event.preventDefault(); if (!stripe) { // Stripe.js hasn't yet loaded. // Make sure to disable form submission until Stripe.js has loaded. return; } setLoading(true); const {error} = await stripe.confirmCardPayment(clientSecret, { payment_method: { card: elements.getElement(CardElement) } }); if (error) { handleError(error); } };
const handleSubmit = async (event) => { event.preventDefault(); if (!stripe) { // Stripe.js hasn't yet loaded. // Make sure to disable form submission until Stripe.js has loaded. return; } setLoading(true); const {error} = await checkout.confirm(); if (error) { handleError(error); } };
オプション決済フロー中に支払い情報を保存する
既存の実装で決済中に決済の詳細も保存される場合は、Checkout Session の作成時に stripe.
を使用して決済の確認ステージで setup_
を渡す代わりに、saved_payment_method_options.payment_method_save パラメーターを使用します。
決済手段を保存するには、Customer が必要です。既存の Customer を渡すか、または新しい Customer を作成するために Checkout Session の customer_creation を always
に設定します。
また、Checkout Session を確定する際に savePaymentMethod の値を渡して、決済手段が保存されているかどうかを確認する必要があります。
支払い後のイベントを処理するサーバー側
支払いが完了すると、Stripe は checkout.session.completed イベントを送信します。ダッシュボード Webhook ツールを使用して、または Webhook ガイドに従って、これらのイベントを受信し、顧客への注文確認メールの送信、データベースへの販売の記録、配送ワークフローの開始などのアクションを実行します。
クライアントからのコールバックを待たずにこれらのイベントをリッスンします。クライアント側では、コールバックが実行される前に顧客がブラウザーのウィンドウを閉じたり、アプリを終了したりする可能性があるだけでなく、不正なクライアントによってレスポンスが操作される可能性もあります。非同期型のイベントをリッスンするよう実装を設定すると、単一の実装で異なるタイプの支払い方法を受け付けできるようになります。
Payment Element を使用して支払いを収集する場合は、checkout.
イベントの他にこれらのイベントを処理することをお勧めします。
イベント | 説明 | アクション |
---|---|---|
checkout.session.completed | 顧客が正常に決済を完了したときに送信されます。 | 顧客に注文の確定を送信し、顧客の注文のフルフィルメントを実行します。 |
checkout_session.async_payment_succeeded | 遅延した決済手段を使用した顧客による決済が最終的に成功したときに送信されます。 | 顧客に注文の確定を送信し、顧客の注文のフルフィルメントを実行します。 |
checkout.session.async_payment_failed | 顧客が支払いを試みたが、支払いに失敗した場合に送信されます。 | 決済は async_ から変わり、もう一度決済を試す機会が顧客に提供されます。 |
checkout.session.expired | 顧客の決済セッションの有効期限が切れたとき (24 時間後) に送信されます。 | 決済は expired から payment_ に変わり、決済ページの再読み込みを試し新しい決済セッションを作成する機会が顧客に提供されます。 |
組み込みをテストする
- 決済ページに移動します。
- 次の表の決済手段を使用して、支払いの詳細を入力します。カード支払いの場合:
- カードの有効期限として任意の将来の日付を入力します。
- 任意の 3 桁のセキュリティコードを入力します。
- 請求先の任意の郵便番号を入力します。
- Stripe に決済を送信します。
- ダッシュボードに移動し、取引ページで決済を探します。決済が成功していると、そのリストに表示されます。
- 決済をクリックすると、請求先情報や購入したアイテムのリストなどの詳細が表示されます。この情報を使用して注文のフルフィルメントを実行できます。
実装内容をテストするためのその他の情報については、テストをご覧ください。