注文のフルフィルメントを実行するベータ
顧客が Custom Checkout で支払った後に、注文のフルフィルメントを実行する方法をご紹介します。
プライベートプレビュー
The Custom Checkout integration is in private preview. To request access, こちらをクリックしてください。
支払いを受け取ると、顧客に支払い内容を提供するためのアクションが必要になる場合があります。サービスへのアクセス許可や、物品の配送がこの例です。このプロセスはフルフィルメントと呼ばれます。このプロセスを処理するには 2 つの方法があります。
- 手動: Stripe が提供した情報を使用して、手動で注文のフルフィルメントを履行できます。たとえば、ダッシュボード を監視したり、支払い通知メールを確認したり、レポート確認後に注文のフルフィルメントを履行したりすることができます。
- 自動: 自動化されたフルフィルメントシステムを構築できます。 Recommended
1 つ目のオプションは、取引額が少額のプロジェクトまたは実験的なプロジェクトに適していますが、多くの場合、フルフィルメントの自動化をお勧めします。このガイドの以降の部分では、自動フルフィルメントシステムの構築方法を説明します。
自動フルフィルメント
以下に説明する自動フルフィルメントシステムは、Webhook とお客様のウェブサイトへのリダイレクトを組み合わせてフルフィルメントをトリガーします。支払いごとにフルフィルメントが発生するように Webhook を使用する必要があり、リダイレクトによって顧客は支払い後すぐにサービスやフルフィルメントの詳細にアクセスできます。
フルフィルメント関数を作成サーバー側
成功した決済のフルフィルメントを履行するための関数をサーバーに作成します。この関数は Webhook によってトリガーされ、顧客が Checkout の決済フルフィルメントを完了した後、お客様のウェブサイトに転送されたときに呼び出されます。このガイドでは、この関数を fulfill_
と呼びますが、関数には任意の名前を指定できます。
fulfill_
関数は以下を満たしている必要があります。
- 同じ Checkout セッション ID で複数回呼び出される場合に適切に処理します。
- 引数として Checkout セッション ID を受け入れます。
- line_items プロパティを拡張して、API から Checkout セッションを取得します。
- payment_status プロパティを確認して、フルフィルメントが必要かどうかを判断します。
- ラインアイテムのフルフィルメントを履行します。
- 指定した Checkout セッションのフルフィルメントのステータスを記録します。
以下のコードを fulfill_
関数の開始点として使用します。TODO
コメントは、実装する必要のある機能を示します。
注
以下のコードスニペットは、選択した言語に応じて fulfillCheckout
または FulfillCheckout
という名前が付けられていますが、これらはすべて同じ関数 (fulfill_
関数) を表します。
注
Checkout セッションにラインアイテムが多く存在する場合は、Checkout のラインアイテム API を適用して auto-pagination を使用することで、すべてのラインアイテムを取得できます。
受け付ける支払い方法とビジネスニーズに応じて、fulfill_
関数に以下の処理を実行させることができます。
- サービスへのアクセスを提供します。
- 商品の配送をトリガーします。
- 支払いの詳細とラインアイテムのコピーをお客様のデータベースに保存します。
- Stripe の領収書が有効になっていない場合に、カスタムの領収書メールを顧客に送信します。
- 顧客が決済時に数量を調整できるようにする場合、ラインアイテムと購入数量を照合します。
- 在庫または在庫記録を更新します。
支払いイベントハンドラーを作成サーバー側
フルフィルメントをトリガーするには、Webhook イベントハンドラーを作成して支払いイベントをリッスンし、fulfill_
関数をトリガーします。
誰かが支払いを行うと、checkout.
イベントが作成されます。これらのイベントの受信を受け付け、処理し、確認するためのエンドポイントをサーバーに設定します。
ACH ダイレクトデビット やその他の銀行振込など、一部の支払い方法は直ちに行われません。決済完了後、売上はすぐには利用可能になりません。遅延型の支払い方法は、後で支払いが完了したときに checkout.
イベントを生成します。
注
以下のコードに表示されている Webhook シークレット (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 シークレット (whsec_
) をイベント処理コードに追加し、顧客として決済を実行してフルフィルメントをテストします。
支払いが完了したら、以下を確認します。
stripe listen
が実行されているコマンドラインには、ローカルサーバーに転送されたcheckout.
イベントが表示されます。session. completed - サーバーログには、
fulfill_
関数からの想定出力が表示されます。checkout
Webhook エンドポイントを作成
ローカルでテストした後、Webhook イベントハンドラーをサーバで設定して実行します。次に、Webhook エンドポイントを作成して checkout.
イベントをサーバーに送信し、 決済フローを再度テストします。
ランディングページでフルフィルメントをトリガーする推奨
Webhook のリッスン は、各支払いのフルフィルメントを常にトリガーするために必要ですが、Webhook は遅延することがあります。決済フローを最適化し、顧客がアクセスしているときにすぐにフルフィルメントを履行できるようにするには、ランディングページからもフルフィルメントをトリガーする必要があります。Checkout セッションの作成時に return_url を渡すか、フロントエンドの confirm
に returnUrl を渡すことにより、ランディングページを設定できます。
指定した URL の Checkout セッション ID を使用して、以下を実行します。
- サーバーが決済のランディングページに対するリクエストを受信したら、URL から Checkout セッション ID を抽出します。
- 指定した ID を使用して
fulfill_
関数を実行します。checkout - フルフィルメントの試行が完了した後、ページをレンダリングします。
ランディングページをレンダリングする際、以下を表示できます。
- フルフィルメントプロセスの詳細。
- 顧客が現在アクセスできるサービスのリンクまたは情報。
- 物品の配送またはロジスティクスの詳細。
Webhook が必要です
顧客は決済のランディングページにアクセスできることを保証されていないため、ランディングページに限定してフルフィルメントをトリガーすることはできません。決済で支払いが完了した後、ランディングページが読み込まれる前にインターネットの接続が失われることがあります。
Webhook イベントハンドラーを設定すると、Stripe が顧客を完全にバイパスして、支払いイベントをお客様のサーバーに直接送信します。 Webhook は、支払いを受け取るタイミングを把握するための最も信頼できる方法です。 Webhook イベントの送信に失敗した場合、Stripe は複数回の再試行を行います。