Express Checkout Element に移行する
支払いリクエストボタン Element を利用する既存の連携を、Express Checkout Element の利用に移行します。
Payment Request Button Element では、Apple Pay、Google Pay、または Link を使用したカード支払いのみを受け付けることができます。Express Checkout Element に移行すると、PayPal などの 1 つ以上の支払いボタンでカードやウォレットによる決済を受け付けることができます。詳細については、比較ガイドをご覧ください。
既存のシステムで使用している機能 | 手順 |
---|---|
Payment Intents API を決済の作成と追跡や決済時のカード詳細の保存に使用 | Express Checkout Element を使用するにはこのガイドの手順に従います。 |
Charges API (トークンを使用) | 先に進む前に Payment Intents API に移行します。 |
Elements インスタンスを更新するクライアント側
次に、モード (決済)、金額、通貨を渡すようにクライアント側のコードを更新します。これらの値により、顧客に表示する支払い方法が決定されます。
たとえば、PaymentIntent
で eur
通貨を渡し、ダッシュボードで OXXO を有効にしても、OXXO は eur
の決済をサポートしないため、顧客に表示されません。
Stripe は、通貨、支払い方法の制限、その他のパラメーターを評価して、対応可能な支払い方法のリストを決定します。コンバージョン率上昇につながり、使用通貨と顧客の所在地に最も適した支払い方法が優先的に表示されます。
PaymentIntent 作成コールを更新するサーバー側
PaymentIntent
には購入時に買い手に表示される支払い方法が含まれます。支払い方法はダッシュボードで管理できます。Stripe は取引額、通貨、決済フローなどの要素に基づいて、適切な支払い方法が返されるように処理します。
既存の実装が複数の支払い方法に対応している場合や、カード以外の支払い方法を受け付ける必要がある場合は、ダッシュボードで有効にする支払い方法を追加することができます。
Express Checkout Element を追加するクライアント側
支払いリクエストボタン Element を Express Checkout Element に置き換えます。PaymentRequestButtonElement
を ExpressCheckoutElement
に置き換える方法の例を以下に示します。
paymentRequest
オブジェクトを作成する必要はなくなりました。代わりに、click
イベントでプロパティを 1 回渡します。
支払いの確定方法を更新するクライアント側
confirm イベントをリッスンして、確定を処理します。決済情報を収集して Stripe に送信するには、stripe.
などの個別の確定メソッドではなく、stripe.confirmPayment を使用します。
stripe.
は、PaymentMethod ID ではなく、Express Checkout Element の Elements インスタンスと、作成した PaymentIntent
の client secret を使用します。
stripe.
は、呼び出されると、3DS ダイアログを表示するか、または銀行の承認ページへ顧客をリダイレクトして顧客認証を行うなどして、必要なアクションを実行しようとします。確認が完了すると、ユーザーは、構成されている return_url に移動します。これは、決済のステータスを表示するウェブサイトのページに対応しています。
カード支払いの決済フローで、必要な場合にのみリダイレクトを行うようにする場合、redirect に if_
を設定できます。これは、Express Checkout Element には適用されません。
stripe.
を stripe.
に置き換える例を以下に示します。
支払い後のイベントを処理するサーバー側
支払いが完了すると、Stripe は payment_intent.succeeded イベントを送信します。ダッシュボードの Webhook ツールを使用するか Webhook のガイドに従ってこれらのイベントを受信し、顧客への注文確認メールの送信、データベースでの売上の記録、配送ワークフローの開始などのアクションを実行します。
クライアントからのコールバックを待つのではなく、これらのイベントをリッスンします。クライアントでは、コールバックが実行される前に顧客がブラウザーのウィンドウを閉じたり、アプリを終了する場合、また悪意を持つクライアントがレスポンスを不正操作する場合もあります。非同期型のイベントをリッスンするよう組み込みを設定すると、単一の組み込みで複数の異なるタイプの支払い方法を受け付けることができます。
Payment Element を使用して支払いを回収する場合は、payment_
イベントのほかにこれらのイベントを処理することをお勧めします。
イベント | 説明 | アクション |
---|---|---|
payment_intent.succeeded | 顧客が正常に支払いを完了したときに送信されます。 | 顧客に注文の確定を送信し、顧客の注文のフルフィルメントを実行します。 |
payment_intent.processing | 顧客が正常に支払いを開始したが、支払いがまだ完了していない場合に送信されます。このイベントは、多くの場合、顧客が口座引き落としを開始するときに送信されます。その後、payment_ イベント、また、失敗の場合は payment_ イベントが送信されます。 | 顧客に注文確認メールを送信し、支払いが保留中であることを示します。デジタル商品では、支払いの完了を待たずに注文のフルフィルメントを行うことが必要になる場合があります。 |
payment_intent.payment_failed | 顧客が支払いを試みたが、支払いに失敗する場合に送信されます。 | 支払いが processing から payment_ に変わった場合は、顧客に再度支払いを試すように促します。 |