注文のフルフィルメント
Checkout Sessions API で受け取った支払いをフルフィルメントする方法をご紹介します。
Checkout Sessions API を使用して支払いを受け取った場合、顧客が代金を支払った対象物を提供するための対応が必要になる場合があります。たとえば、場合によっては、サービスへのアクセス権を付与したり、物品を発送したりすることが必要になります。これはフルフィルメントと呼ばれるプロセスであり、このプロセスを処理するには次の 2 つの方法があります。
- 手動: Stripe が提供した情報を使用して、手動で注文のフルフィルメントを履行できます。例えば、ダッシュボード を監視したり、支払い通知メールを確認したり、レポート確認後に注文のフルフィルメントを履行したりすることができます。
- 自動: 自動化されたフルフィルメントシステムを構築できます。 Recommended
1 つ目のオプションは、取引額が少額のプロジェクトまたは実験的なプロジェクトに適していますが、多くの場合、フルフィルメントの自動化をお勧めします。このガイドの以降の部分では、自動フルフィルメントシステムの構築方法を説明します。
自動フルフィルメント
以下に説明する自動フルフィルメントシステムは、Webhook とお客様のウェブサイトへのリダイレクトを組み合わせてフルフィルメントをトリガーします。支払いごとにフルフィルメントが発生するように Webhook を使用する必要があり、リダイレクトによって顧客は支払い後すぐにサービスやフルフィルメントの詳細にアクセスできます。
フルフィルメント関数を作成サーバ側
支払いを正常にフルフィルメントするための関数をサーバー上に作成します。Webhook によってこの関数がトリガーされ、この関数は、決済完了後に顧客が貴社のウェブサイトに誘導されたときに呼び出されます。本ガイドでは、この関数を fulfill_
と呼んでいますが、関数の名前は自由に設定できます。
fulfill_
関数では、次のことを行う必要があります。
- 同じ Checkout セッション ID で複数回呼び出されたケースを正しく処理します。
- 引数として Checkout セッション ID を受け入れます。
- 拡張したline_items プロパティを使って、API で Checkout セッションを取得します。
- payment_status プロパティを確認して、フルフィルメントが必要かどうかを判断します。
- ラインアイテムのフルフィルメントを実行します。
- 指定された Checkout セッションのフルフィルメントステータスを記録します。
以下のコードを fulfill_
関数の開始点として使用します。TODO
コメントは、実装する必要がある機能を示します。
注
以下のコードスニペットでは、選択した言語に応じて fulfill_
関数に fulfillCheckout
または FulfillCheckout
という名前が付けられていますが、これらはすべて同じ関数を表しています。
注
Checkout セッションに多数のラインアイテムがある場合は、自動ページ分割と Checkout ラインアイテムを操作する API を使用して、すべてのラインアイテムを取得します。
受け付ける決済手段とビジネスニーズに応じて、fulfill_
関数で次の処理を行うことができます。
- サービスへのアクセス権をプロビジョニングする。
- 商品の配送をトリガーする。
- 支払い詳細とラインアイテムのコピーを自社のデータベースに保存する。
- Stripe の領収書を有効にしていない場合に、顧客にカスタムの領収書メールを送信する。
- 顧客が Checkout で数量を調整できるようにする場合に、ラインアイテムと購入数量を照合する。
- 在庫または在庫レコードを更新する。
支払いイベントハンドラーを作成サーバ側
フルフィルメントをトリガーするには、Webhook イベントハンドラーを作成して支払いイベントをリッスンし、fulfill_
関数をトリガーします。
貴社に対して支払いがあると、checkout.
イベントが作成されます。これらのイベントの受け付け、処理、受領確認を行うように、サーバー上のエンドポイントを設定します。
即時の決済手段と遅延型の決済手段
ACH Direct Debit やその他の銀行振込など、一部の決済手段は即時ではありません。このため、Checkout が完了しても、売上はすぐ利用できるようにはなりません。決済手段が遅延した場合、後で支払いが成功すると checkout.session.async_payment_succeeded イベントが生成されます。オブジェクトのステータスは、決済ステータスが成功または失敗になるまで処理中になります。
注
以下のコードに示されている Webhook secret (whsec_
) は、Stripe CLI または Webhook エンドポイントから取得できます。ローカルでのテストには Stripe CLI を使用できます。Stripe は Webhook エンドポイントを使用して、サーバーで実行されているハンドラーにイベントを送信します。詳細は次のセクションを参照してください。
また、checkout.
イベントをリッスンして処理することもできます。たとえば、遅延していた支払いが失敗した場合に顧客にメールを送信できます。
イベントハンドラーをローカルでテスト
Webhook イベントハンドラーを開発、テストするための最も簡単な方法は、Stripe CLI を使用することです。Stripe CLI をお持ちでない場合は、インストールガイド に従ってインストールしてください。
Stripe CLI がインストールされている場合は、イベントハンドラーをローカルでテストできます。サーバーを (localhost:4242
などで) 実行し、次に stripe listen コマンドを実行すると、Stripe CLI がイベントをローカルサーバーに転送します。
stripe listen --forward-to localhost:4242/webhook Ready! Your webhook signing secret is 'whsec_<REDACTED>' (^C to quit)
Webhook secret (whsec_
) をイベント処理コードに追加し、顧客として決済フローを実行してフルフィルメントをテストします。
支払いが完了したら、以下を確認します。
stripe listen
が実行されているコマンドラインには、ローカルサーバーに転送されたcheckout.
イベントが表示されます。session. completed - サーバーログには、
fulfill_
関数からの想定出力が表示されます。checkout
Webhook エンドポイントを作成
ローカルでテストした後、Webhook イベントハンドラーをサーバー上で稼働させます。次に、Webhook エンドポイントを作成して checkout.
イベントをサーバーに送信し、決済フローを再度テストします。
ランディングページでフルフィルメントをトリガーする推奨
Webhook をリッスンすることは、すべての支払いに対して常にフルフィルメントがトリガーされていることを確認するために必要ですが、そうすると Webhook が遅延することがあります。決済フローを最適化し、顧客がアクセスしたときにすぐに確実にフルフィルメントされるようにするには、ランディングページからもフルフィルメントをトリガーします。ランディングページを設定するには、Checkout セッションの作成時に return_url を渡すか、フロントエンドで returnUrl を confirm
に渡します。
指定した URL の Checkout セッション ID を使用して、次の手順を行います。
- サーバーが決済フローのランディングページに対するリクエストを受信したときに、URL から Checkout セッション ID を抽出します。
- 指定した ID を使用して
fulfill_
関数を実行します。checkout - フルフィルメントの試行が完了した後、ページをレンダリングします。
ランディングページをレンダリングする際、以下を表示できます。
- フルフィルメントプロセスの詳細。
- 顧客が現在アクセスできるサービスのリンクまたは情報。
- 物品の配送またはロジスティクスの詳細。
Webhook が必要です
顧客が決済フローのランディングページにアクセスするとは限らないため、フルフィルメントのトリガーをランディングページからのみにすると当てになりません。たとえば、支払いに成功しても、ランディングページが読み込まれる前にインターネットへの接続が失われることがあります。
Webhook イベントハンドラを設定することで、Stripe はクライアントを完全にバイパスして、支払いイベントをサーバーに直接送信できるようになります。Webhook は、支払いの受け取りを確認するための最も信頼性の高い方法です。Webhook イベントの配信に失敗した場合、Stripe は複数回再試行します。