注文のフルフィルメント
Checkout Sessions API で受け取った支払いをフルフィルメントする方法をご紹介します。
Checkout Sessions API (Payment Links を含む) を使用して支払いを受け取った場合、顧客が代金を支払った対象物を提供するための対応が必要になる場合があります。たとえば、場合によっては、サービスへのアクセス権を付与したり、物品を発送したりすることが必要になります。これはフルフィルメントと呼ばれるプロセスであり、このプロセスを処理するには次の 2 つの方法があります。
- 手動: Stripe が提供した情報を使用して、手動で注文のフルフィルメントを履行できます。例えば、ダッシュボード を監視したり、支払い通知メールを確認したり、レポート確認後に注文のフルフィルメントを履行したりすることができます。
- 自動: 自動化されたフルフィルメントシステムを構築できます。 Recommended
1 つ目のオプションは、取引額が少額のプロジェクトまたは実験的なプロジェクトに適していますが、多くの場合、フルフィルメントの自動化をお勧めします。このガイドの以降の部分では、自動フルフィルメントシステムの構築方法を説明します。
自動フルフィルメント
以下に説明する自動フルフィルメントシステムは、Webhook とお客様のウェブサイトへのリダイレクトを組み合わせてフルフィルメントをトリガーします。支払いごとにフルフィルメントが発生するように Webhook を使用する必要があり、リダイレクトによって顧客は支払い後すぐにサービスやフルフィルメントの詳細にアクセスできます。
注
Payment Links は Checkout を使用するため、以下の情報は特に記載のない限り、すべて Payment Links と Checkout の両方に適用されます。
フルフィルメント関数を作成サーバ側
支払いを正常にフルフィルメントするための関数をサーバー上に作成します。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.
イベントが生成されます。
注
以下のコードに示されている 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_
) をイベント処理コードに追加し、顧客として Checkout を実行してフルフィルメントをテストします。
- 購入ボタンを押して Checkout に進むか、決済用リンクにアクセスします。
- Checkout で次のテストデータを指定します。
- カード番号として
4242 4242 4242 4242
を入力する - カードの有効期限として将来の任意の日付を入力する
- 3 桁の任意のセキュリティコードを入力する
- 請求先の任意の郵便番号 (
90210
) を入力する
- カード番号として
- 支払うボタンを押します。
支払いが完了したら、次の点を確認します。
stripe listen
が実行されているコマンドラインに、ローカルサーバーへ転送されたcheckout.
イベントが表示されます。session. completed - サーバーログには、
fulfill_
関数から想定される出力が表示されます。checkout
Webhook エンドポイントを作成
ローカルでテストした後、Webhook イベントハンドラーをサーバで設定して実行します。次に、Webhook エンドポイントを作成して checkout.
イベントをサーバーに送信し、 決済フローを再度テストします。
ランディングページの URL を設定推奨
Checkout を設定することで、顧客の決済完了後にお客様のウェブサイトのページを送信します。ページの URL に {CHECKOUT_
プレースホルダーを含めると、顧客が Checkout からリダイレクトされるときにプレースホルダーが Checkoutセッション ID に置き換えられます。
ホストされた Checkout
デフォルトの ui_mode が hosted
の Checkout セッションでは、success_
を設定します。
注
checkout.
イベントをリッスンする Webhook エンドポイントを設定し、さらに success_
を設定した場合、 Checkout はサーバーが Webhook イベントの送信に応答するのを待ってから顧客をリダイレクトします。この方法を使用する場合は、サーバーが checkout.
イベントにできるだけ早く応答するように設定してください。
Payment Links
API を使用して作成する Payment Links の場合、after_completion.redirect.url を設定します。
Payment Links の場合、次のようにダッシュボードで作成します。
- 支払い後タブに移動します。
- 確認ページを表示しないを選択します。
{CHECKOUT_
プレースホルダーが含まれたランディングページの URL を指定します (例:SESSION_ ID} https://example.
)。com/after-checkout?session_ id={CHECKOUT_ SESSION_ ID}
ランディングページでフルフィルメントをトリガーする推奨
Webhook をリッスンすることは、すべての支払いに対して常にフルフィルメントがトリガーされていることを確認するために必要ですが、そうすると Webhook が遅延することがあります。決済フローを最適化し、顧客がアクセスしたときにすぐに確実にフルフィルメントされるようにするには、ランディングページからもフルフィルメントをトリガーします。
前のステップで指定した URL の Checkout セッション ID を使用して、次の手順を行います。
- サーバーが Checkout のランディングページに対するリクエストを受信したときに、URL から Checkout セッション ID を抽出します。
- 提供された ID で
fulfill_
関数を実行します。checkout - フルフィルメントの試行が完了した後にページをレンダリングします。
ランディングページをレンダリングすると、次の情報を表示できます。
- フルフィルメントプロセスの詳細
- 顧客が現在アクセスできるサービスに関するリンクまたは情報
- 物品の配送先や物流の詳細
Webhook は必須
顧客が Checkout のランディングページにアクセスするとは限らないため、フルフィルメントのトリガーをランディングページからのみにすると当てになりません。たとえば、Checkout で支払いに成功しても、ランディングページが読み込まれる前にインターネットへの接続が失われることがあります。
Set up a webhook event handler so Stripe can send payment events directly to your server, bypassing the client entirely. Webhooks provide the most reliable way to confirm when you get paid. If webhook event delivery fails, Stripe retries multiple times.