Bancontact および SEPA ダイレクトデビットによるサブスクリプションを設定する
Bancontact および SEPA ダイレクトデビットを使用したサブスクリプションの作成と請求の方法をご紹介します。
Bancontact は 1 回限りの使用の支払い方法で、支払いごとに顧客の認証が必要となります。支払いが認証されると、Stripe は顧客の IBAN を SEPA ダイレクトデビット支払い方法に保存します。それ以降は、SEPA ダイレクトデビット支払い方法を使用して将来の決済を受け付けることができます。
この連携では、Stripe は、最初のサブスクリプションの支払いを Bancontact で請求して、顧客の銀行情報を収集します。無料トライアルを提供している場合、Stripe は Bancontact を通して顧客に 0.02 EUR を請求し、銀行情報を収集して、即時に返金します。
Checkout セッションは、顧客の購入意図の詳細を表すものです。顧客がサブスクリプションを開始しようとしたときにセッションを作成します。Checkout セッションに顧客がリダイレクトされると、購入完了のための決済フォームが表示されます。顧客は購入を完了すると、元のサイトにリダイレクトされます。
Stripe を設定するサーバー側
任意の Stripe クライアントをインストールします。
Stripe CLI をインストールします (オプション)。CLI には Webhook のテストが用意されていて、これを実行することで商品および価格を作成できます。
その他のインストールオプションについては、Stripe CLI を使ってみるをご覧ください。
料金体系モデルを作成するダッシュボードStripe CLI
ダッシュボードまたは Stripe CLI で商品とその価格を作成します。
この例では、「基本」と「プレミアム」という 2 つのサービスレベルオプションがある固定価格のサービスを使用しています。サービスレベルオプションごとに、1 つの商品と 1 つの継続価格を作成する必要があります (初期費用のような 1 回限りの支払いを追加する場合は、1 回限りの価格で 3 つ目の商品を作成します。わかりやすくするために、この例には 1 回限りの支払いを含めていません)。
この例では、各商品が 1 カ月間隔で請求されます。基本商品の価格は 5 EUR で、プレミアム商品の価格は 15 EUR です。
他の料金体系モデルについては、Billing の例をご覧ください。
Checkout セッションを作成するクライアント側サーバー側
サーバー側のエンドポイントを呼び出して Checkout セッションを作成する購入ボタンをウェブサイトに追加します。
<html> <head> <title>Checkout</title> </head> <body> <form action="/create-checkout-session" method="POST"> <button type="submit">Checkout</button> </form> </body> </html>
既存の Price の ID を使用して Checkout セッションを作成します。モードが subscription
に設定されており、1 つ以上の継続価格を渡すことを確認してください。継続価格に加えて、1 回限りの価格を追加できます。Checkout セッションを作成したら、レスポンスで返された URL に顧客をリダイレクトします。
セッションの作成時には、payment_
を指定することも、ダッシュボードの設定に基づいて支払い方法が自動的に選択されるようにすることもできます。payment_
を指定しない場合は、ダッシュボードで Bancontact の継続支払いを有効にする必要があります。これにより、SEPA ダイレクトデビットは Bancontact の継続支払いにのみ有効になりますが、SEPA ダイレクトデビットの支払いが単独の支払い方法として有効になることはありません。
顧客は支払いを正常に完了すると、success_
にリダイレクトされます。これはお客様のウェブサイト上にあり、支払いの成功を顧客に知らせるページです。上記の例のように success_
に {CHECKOUT_
テンプレート変数を含めて、成功ページでセッション ID を使用できるようにします。
顧客が支払いを完了せずに Checkout セッションでお客様のロゴをクリックすると、Checkout は、cancel_
に顧客を誘導して、ウェブサイトにリダイレクトします。これは通常、顧客が Checkout にリダイレクトされる前に表示していたウェブサイトのページです。
デフォルトでは、Checkout セッションは作成後 24 時間で期限が切れます。
注意
次に挙げる理由により、支払い開始の検出時には、success_
へのリダイレクトのみに依存しないでください。
- 悪意を持つユーザが、支払いをせずに
success_
に直接アクセスし、商品やサービスにアクセスできるようになる可能性があります。url - 顧客が支払いの成功後に
success_
に到達するとは限りません。リダイレクトが発生する前に、顧客がブラウザタブを閉じることがあります。url
支払いが成功したことを確認する
顧客が支払いを完了すると、success_
として指定された URL にリダイレクトされます。この URL は通常、顧客に支払いが成功したことを知らせるお客様の Web サイト上のページです。
ダッシュボード、カスタム Webhook、またはサードパーティーのプラグインを使用して、顧客に注文の確認メールを送信したり、売上をデータベースに記録したり、配送ワークフローを開始するなどの、支払い後のイベントを処理します。
Zapier などのプラグインを使用すると、Stripe の支払いからの情報を利用して購入のフルフィルメントシステムを自動更新できます。
プラグインで対応可能な自動化の例の一部を以下に挙げます。
- 支払いの成功に対応して、注文の追跡に使用されるスプレッドシートを更新する
- 支払いの成功に対応して、在庫管理システムを更新する
- メールまたはチャットアプリケーションを使用して、社内のカスタマーサービスチームへの通知をトリガーする
構築したシステムをテストする
テスト用 API キーを使用して、支払い方法として Bancontact を選択し、登録ボタンをクリックします。確定すると、支払いをオーソリまたは失敗させるオプションのあるテストページにリダイレクトされます。
- Authorize test payment (テスト支払いをオーソリする) をクリックして、設定成功のケースをテストします。
- Fail test payment (テスト支払いを失敗させる) をクリックして、顧客が認証に失敗するケースをテストします。