Bacs ダイレクトデビット支払い
注意
Stripe は、顧客の通貨、決済手段の制限、その他のパラメーターを評価して、決済手段オプションを自動的に提示します。決済を受け付けるの手順を使用して、Stripe ダッシュボードから決済手段を設定することをお勧めします。
引き続き、Checkout で顧客に提示する決済手段を手動で設定する必要がある場合は、こちらのガイド (たとえば、_「サブスクリプション」_モードでの決済の受け付け) を使用します。それ以外の場合は、ダッシュボードに移行します。
イギリスの Stripe ユーザは、支払いモードで Checkout を使用して、Bacs ダイレクトデビットによる支払いを受け付けることができます。
Checkout セッションは、顧客の購買意図の詳細を表すものです。顧客が何らかの支払いを行おうとしたときにセッションを作成します。Checkout セッションに顧客がリダイレクトされると、購入完了のための決済フォームが表示されます。顧客は購入を完了すると、元のサイトにリダイレクトされます。
商品および価格を作成する
Checkout を使用するには、まず商品と価格を作成する必要があります。物品やサービスレベルごとに商品を作成します。各商品の料金体系は 1 つ以上の価格で示されます。
たとえば、20 GBP と 25 EUR の、通貨が異なる 2 つの「価格」が設定された T シャツ「商品」を作成できます。これにより、対象商品の詳細を変更せずに価格を変更したり追加したりできるようになります。商品と価格は、API を通じて、またはダッシュボードを使用して作成できます。
決済時に価格を決定する場合 (たとえば、顧客が寄付金額を設定する場合など)、または事前に価格を作成したくない場合は、既存の商品を使用して Checkout セッションの作成時に単発の価格を作成することもできます。
注意
Prices を使用しない既存の Checkout システムがある場合には、Prices の導入以降に Checkout API が変更されていることに注意してください。この移行ガイドを使用してアップグレードするか、既存のシステムを保持することができます。
Checkout セッションを作成するクライアント側サーバ側
ウェブサイトに決済ボタンを追加し、サーバー側のエンドポイントを呼び出して Checkout セッションを作成します。
<html> <head> <title>Checkout</title> </head> <body> <form action="/create-checkout-session" method="POST"> <button type="submit">Checkout</button> </form> </body> </html>
line_items を使用してセッションを作成します。ラインアイテムは、顧客が購入しているアイテムの一覧を表します。
顧客は支払いを正常に完了すると、success_url
にリダイレクトされます。これはお客様の Web サイトのページであり、支払い情報の収集に成功し、支払いが処理されていることを顧客に知らせます。
顧客が支払いを完了せずに Checkout セッションでお客様のロゴをクリックすると、Checkout は顧客を cancel_url
に移動することで、元の Web サイトにリダイレクトします。このページは通常、顧客が Checkout にリダイレクトされる前に表示していたお客様の Web サイトのページです。
Checkout は支払いを受け付け、将来の使用のために支払い方法を保存することができます。この方法で保存された支払い方法は、PaymentIntent (支払いインテント) による将来の支払いに使用できます。Checkout セッションを作成したら、レスポンスで返された URL に顧客をリダイレクトします。
注
Bacs ダイレクトデビットのルールでは、支払いの詳細が最初に収集されたときと、口座から引き落とされたときに、顧客は引き落とし通知メールを受信する必要があります。Stripe は、デフォルトでこれらのメールを送信します。
Checkout セッションを作成すると、セッション ID が返されます。上の例で示されるように、success_url
に {CHECKOUT_SESSION_ID}
テンプレート変数を含めることによって、成功時のページでセッション ID を使用できるようにします。
注意
次に挙げる理由により、支払い開始の検出時には、success_url
へのリダイレクトのみに依存しないでください。
- 悪意を持つユーザが、支払いをせずに
success_url
に直接アクセスし、商品やサービスにアクセスできるようになる可能性があります。 - 顧客が支払いの成功後に
success_url
に到達するとは限りません。リダイレクトが発生する前に、顧客がブラウザタブを閉じることがあります。
支払い後のイベントを処理するサーバ側
顧客は支払いを完了すると、success_url
パラメータで指定された URL にリダイレクトされます。通常、これはお客様の Web サイト上にある、支払いが成功したことを顧客に知らせるページです。
ただし、Bacs ダイレクトデビット支払いは通知遅延型の決済手段であるため、売上はすぐに利用可能になりません。Bacs ダイレクトデビット支払いは通常、売上が利用可能になるまでに 3 営業日かかります。このため、売上が利用可能になるまで注文のフルフィルメントを保留する必要があります。支払いが成功すると、基になる PaymentIntent のステータスが processing
から succeeded
に変わります。
支払いのステータスに変化があると、以下の Checkout イベントが送信されます。
イベント名 | 説明 | 次のステップ |
---|---|---|
checkout.session.completed | 顧客が Checkout フォームを送信して、デビット支払いのオーソリを正常に実行しています。 | 支払いの成功または失敗の結果を待ちます。 |
checkout.session.async_payment_succeeded | 顧客の支払いが成功しました。 | 顧客が購入した商品またはサービスのフルフィルメントを行います。 |
checkout.session.async_payment_failed | 何らかの理由により顧客の支払いが拒否されたか、失敗しました。 | メールで顧客に連絡して、新たに注文をするようにリクエストします。 |
Webhook コードでこれら 3 つの Checkout イベントのすべてを処理する必要があります。
各 Checkout Webhook のペイロードには Checkout Session (Checkout セッション) オブジェクト が含まれ、これには、顧客と PaymentIntent に関する情報が含まれます。
顧客がリダイレクトされる前に、checkout.session.completed
Webhook がお客様のサーバーに送信されます。Webhook の確認応答 (任意の 2xx
ステータスコード) によって、success_url
への顧客のリダイレクトが開始されます。支払いに成功してから 10 秒以内に Stripe が成功確認応答を受け取らなかった場合、顧客は自動的に success_url
ページにリダイレクトされます。
success_url
ページで顧客に成功のメッセージを表示できますが、その際に、Bacs ダイレクトデビット支払いは即時の決済手段ではないため、注文のフルフィルメントに数日かかることを知らせます。
通知遅延型の支払いの他に即時の支払い (クレジットカードなど) を受け付ける際には、checkout.session.completed
イベントの受信時に両方の種類の支払いを処理できるように、Webhook エンドポイントを更新する必要があります。
顧客や支払いに関する情報を取得するには、Webhook のペイロードの customer
や payment_intent
のプロパティで参照される Customer または PaymentIntent オブジェクトを取得します。
Webhook をローカルでテストする
Webhook をローカルでテストするには、Stripe CLI を使用できます。Stripe CLI をインストールすると、イベントをサーバに転送できます。
stripe listen --forward-to localhost:4242/webhook Ready! Your webhook signing secret is '{{WEBHOOK_SIGNING_SECRET}}' (^C to quit)
詳細については、Webhook の設定をご覧ください。
組み込みをテストする
この時点で、銀行口座の詳細を収集して支払いを受け入れる Bacs ダイレクトデビットの基本的な組み込みが完了しています。
組み込みの準備ができていることを確認するために、テスト環境で使用できる銀行口座番号が複数あります。
銀行コード | 口座番号 | 説明 |
---|---|---|
108800 | 00012345 | 支払いが成功し、PaymentIntent が processing から succeeded に変化します。 |
108800 | 90012345 | 支払いが 3 分後に成功し、PaymentIntent が processing から succeeded に変化します。 |
108800 | 33333335 | 支払いが承認されますが、すぐに debit_not_authorized エラーコードによって失敗し、PaymentIntent が processing から requires_payment_method に変わります。同意書は inactive になり、この PaymentMethod を再び使用することはできません。 |
108800 | 93333335 | 支払いが debit_not_authorized エラーコードによって 3 分後に失敗し、PaymentIntent が processing から requires_payment_method に変化します。同意書は inactive になり、この PaymentMethod を再び使用することはできません。 |
108800 | 22222227 | 支払いが insufficient_funds エラーコードによって失敗し、PaymentIntent が processing から requires_payment_method に変化します。同意書は active のままで、この PaymentMethod は再使用が可能です。 |
108800 | 92222227 | 支払いが insufficient_funds エラーコードによって 3 分後に失敗し、PaymentIntent が processing から requires_payment_method に変化します。同意書は active のままで、この PaymentMethod は再使用が可能です。 |
108800 | 55555559 | 支払いが 3 分後に成功し、PaymentIntent が processing から succeeded に変わりますが、不審請求の申請が直ちに作成されます。 |
108800 | 00033333 | 決済手段の作成は成功しますが、同意書が顧客の銀行によって拒否され、即座に inactive に変化します。 |
108800 | 00044444 | Bacs ダイレクトデビットの設定を求めるリクエストが、口座番号が無効なため即座に失敗し、顧客は送信前に情報を更新するように求められます。支払いの詳細は収集されません。 |
テストの実行には前述の任意の口座番号を使用できます。ただし、Bacs ダイレクトデビットによる支払いは処理に数日かかるため、3 分の遅延で動作するテスト用口座番号を使用して、本番環境の支払いの動作のシミュレーションをしやすくします。
注
デフォルトでは、Stripe は支払いの詳細が最初に収集されたときと、顧客の口座から引き落としが行われるたびに、顧客にメールを送信します。テスト環境では、これらの通知は送信されません。
支払いの失敗
支払いはさまざまな理由で失敗する可能性があります。失敗の理由は、charge.failure_code から入手できます。特定の失敗コードの支払いのみを再試行できます。支払いを再試行できない場合は、顧客に連絡して、別の銀行口座または別の決済手段を使用して再度支払うように依頼することをお勧めします。
以下は、現時点で送信される Bacs ダイレクトデビット用の失敗コードの一覧です。コードは随時追加される可能性があるため、コードを開発、保守する際には、これらのタイプがすべてではないことに注意してください。
失敗コード | 説明 | 再試行の可否 |
---|---|---|
account_closed | 銀行口座が解約されています。 | 不可 |
bank_ownership_changed | アカウントが新しい決済サービスプロバイダー (PSP) に移管されました。新しい PSP の詳細が通知されているかどうかを確認してください。通知されていない場合は、顧客から新しい同意書を収集する必要があります。 | 不可 |
debit_not_authorized | 顧客が銀行に対して、この支払いが無許可であったか、支払い銀行の同意書がないことを通知しました。 | 不可 |
generic_could_not_process | この支払いは処理できませんでした。 | 可 |
insufficient_funds | 顧客の口座には、この支払いに充当できるだけの資金がありません。 | 可 |
invalid_account_number | 口座番号が無効です。これは、GBP の口座ではないか、口座がダイレクトデビットの支払いを処理できないことを示している場合があります。 | 不可 |
支払いを再試行するには、同じ PaymentMethod を使用して、再度 PaymentIntent を確定します。
確実に成功させるために、支払いを再試行する前に支払人に連絡することをお勧めします。