Checkout で注文のフルフィルメントを実行する
Stripe Checkout を導入するか、Stripe Payment Link を作成して顧客を支払いフォームに移動させた後は、注文の支払い後にフルフィルメントが実行可能になることを知らせる必要があります。
このガイドでは、以下の方法を説明します。
- 顧客から支払いを受けたら、イベント通知を受け取る。
- イベントを処理する。
- Stripe CLI を使用して、新しいイベントハンドラのテストを迅速化する。
- オプションで追加の支払い方法も処理する。
- 本番環境でイベントハンドラを有効にする。
Stripe CLI をインストールする
Stripe CLI を使用すると、Webhook を最も簡単にローカルで開発およびテストできます。
最初に、Stripe CLI のインストールガイドに従って作業をします。
Stripe CLI をインストールし、ログインプロセスを完了したら、次のステップに進む準備完了です。
イベントハンドラを作成するサーバ側
このセクションでは、顧客が決済フローを完了したときに Stripe からお客様に checkout.session.completed
イベントを送信できるように、小さいイベントハンドラを作成します。
最初に、イベントハンドラのルートを新たに作成します。まず、受信するイベントを出力することから開始します。次のステップで送信が機能しているかどうかを確認します。
テスト
サーバーを実行します (たとえば、localhost:4242
などで)。次に、イベントをローカルサーバーに転送するように Stripe CLI を設定して、イベントハンドラをローカルでテストできるようにします。
stripe listen --forward-to localhost:4242/webhook Ready! Your webhook signing secret is 'whsec_<REDACTED>' (^C to quit)
次に、顧客として 以下のように Checkout を実行します。
- 決済ボタンをクリックする (支払いの受け付けガイドで設定されているはずです)
- テストデータを使って支払いフォームを入力する
- カード番号として
4242 4242 4242 4242
を入力する - カードの有効期限として任意の将来の日付を入力する
- 任意の 3 桁のセキュリティコードを入力する
- 請求先の任意の郵便番号 (
90210
) を入力する
- カード番号として
- 支払うボタンをクリックする
以下を確認することができます。
stripe listen
出力内にcheckout.session.completed
があることcheckout.session.completed
イベントでの、サーバーのイベントログからの出力ステートメント
これで、イベント送信を確認できました。セキュリティを少し強化することで、イベントが Stripe からのみ送信されるようにすることができます。
イベントが Stripe から送信されていることを確認する
イベントハンドラには誰でもデータを書き込むことができます。イベントを処理する前に、必ずそのイベントが Stripe から送信され、信頼できるものであることを確認してください。公式の Stripe ライブラリには、Webhook イベントを確認するための構築済みのサポートが備わっており、イベントハンドラを以下のように更新します。
テスト
前のステップからのテストフローを実行します。ここでも、正常に出力された checkout.session.completed
イベントを確認できます。
次に、エンドポイントへの署名なしのリクエストの送信を試します。
curl -X POST \ -H "Content-Type: application/json" \ --data '{ "fake": "unsigned request" }' \ -is http://localhost:4242/webhook HTTP/1.1 400 Bad Request ... more headers
エンドポイントに署名なしのリクエストを送信しようとしたため、400 Bad Request
エラーが発生します。
これでイベントハンドラの基本の設定が終わりましたので、注文のフルフィルメントに進むことができます。
注文のフルフィルメントを実行するサーバ側
Handle the checkout.session.completed
event to fulfill the order. Depending on which payment methods you accept (for example, cards or mobile wallets), you might have some additional events to handle. This event includes the Checkout Session object, which contains details about your customer and their payment. When handling this event, you might also consider:
- 注文のコピーを独自のデータベースに保存する。
- 顧客に領収書のメールを送信する。
line_item.adjustable_quantity
を使用する場合、顧客が購入したラインアイテムと数量を照合します。Checkout セッションに多くのラインアイテムが含まれる場合は、line_items を使用してページ分割できます。
リダイレクトの動作を制御する
Webhook イベントを受信すると顧客がリダイレクトされるように Checkout を設定できます。Webhook がトリガーになるこのリダイレクトの挙動は、オンラインフォームと Stripe がオンラインで提供するページのどちらを使用しているかによって多少異なります。
Stripe がオンラインで提供するページ | イベントを受信したことを確認した「後」、Webhook エンドポイントは顧客を success_url にリダイレクトします。エンドポイントが停止していたり、イベントが正しく確認されない場合は、支払い成功の 10 秒後にハンドラーが顧客を success_url にリダイレクトします。 |
オンラインフォーム | Webhook エンドポイントは、顧客をただちに return_url にリダイレクトします。イベントを受信したことを確認する必要は「ありません」。 |
テスト
stripe listen
の実行が続いていることを確認します。前のステップで行ったように、テストユーザーとして Checkout を実行します。イベントハンドラーが checkout.session.completed を受信することで、イベントが正常に処理されていることがわかります。
遅延通知型の支払い方法を処理するサーバ側
注意
このステップは、Bacs ダイレクトデビット、銀行振込、Boleto、カナダのプレオーソリデビット、コンビニ決済、OXXO、SEPA ダイレクトデビット、SOFORT、ACH ダイレクトデビットのいずれかの決済手段の使用を計画している場合にのみ必要になります。
遅延通知型の支払い方法で支払いを受け取る場合、売上はすぐには利用可能になりません。売上の処理までに数日かかることがあるため、売上がアカウントで利用可能になるまで注文のフルフィルメントを保留する必要があります。支払いが成功すると、基本となる PaymentIntent のステータスが processing
から succeeded
に変わります。
以下の Checkout イベントを処理する必要があります。
イベント名 | 説明 | 次のステップ |
---|---|---|
checkout.session.completed | 顧客が Checkout フォームを送信して、デビット支払いのオーソリを正常に完了しました。 | 支払いが成功するか、失敗するかの結果を待ちます。 |
checkout.session.async_payment_succeeded | 顧客の支払いが成功しました。 | 顧客の購入商品またはサービスのフルフィルメントを行います。 |
checkout.session.async_payment_failed | 何らかの理由により支払いが拒否されたか、失敗しました。 | メールで顧客に連絡して、新たに注文をするようにリクエストします。 |
これらのイベントすべてに Checkout Session (セッション) オブジェクトが含まれます。
イベントハンドラーを更新して、注文のフルフィルメントを実行します。
テスト
stripe listen
の実行が続いていることを確認します。前のステップで行ったように、テストユーザーとして Checkout を実行します。イベントハンドラーが checkout.session.completed
イベントを受信し、イベントが正常に処理されています。
これですべてのステップを完了しました。いつでも本番環境に移行する準備ができています。
本番環境に移行する
イベントハンドラのエンドポイントを本番環境にデプロイした後は、Stripe に本番用の URL を登録する必要があります。Webhook の登録に関するガイドに従って、作業をしてください。