BackEnd

Stripe Connectを使ってCheckoutを利用した継続課金を実装

投稿日:2021年4月26日 更新日:

はじめに

前回は、Stripe Connectを使った継続課金の実装について説明しました。今回は、Checkoutを使った場合の継続課金の実装について説明します。

なお、継続課金に使用する商品については、前回の記事で登録したものを使うものとします。

Checkoutを使う場合の動線

Checkoutを使う場合と使わない場合の大きな違いとして、決済の動線が異なります。

Checkoutを使う場合、一度、下の画像のようなStripeのサイトに遷移し、決済に成功すると、こちらが指定したURLにリダイレクトされます。stripe

決済成功や、その後の継続課金成功時などのイベントが発生した場合、こちらが設定したWebhook URLに通知されます。

Webhook URLの指定は、Stripe Connectアカウントの開発者の中にあるWebhookから設定できます。

stripe webhook

「Connect アプリケーションからイベントを受信するエンドポイント」の「エンドポイントを追加」から新しいWebhook URLを設定することができます。

Webhook URLと通知するイベントの種類を選択してエンドポイントを作成します。

作成するとこのような画面になります。この「署名シークレット」はWebhook URLに送られてきたパラメータを検証する際に使用します。

決済画面への遷移

Checkoutを使って継続課金を実装する場合、決済完了情報がWebhookで送られてくるため、どのユーザが決済を完了した通知なのかを特定する必要があります。

その方法としては、いくつかやり方があると思いますが、例えば、Checkoutの画面に遷移するためのCheckoutSessionを作成する際に、client_reference_idとして決済するユーザのIDを渡しても良いですし、CheckoutSessionを作る際に、session_idとuser_idをテーブルに保存しても良いと思います。

今回は、継続課金のログを残す意味も兼ねて、継続課金の管理テーブルをインサートする方法でやってみます。

マイグレーション

継続課金の状態を管理するuser_subscriptionsテーブルを追加します。

Checkout Sessionの作成

継続課金を処理するSubscriptionControllerを作成します。

indexは継続課金のためのボタンが1つだけある画面で、successは決済完了後に遷移する画面です。

createCheckoutSessionはindexから呼ばれるAPIになっており、Checkout Sessionを作成し、Session IDを返却します。

また、既存のStripeの顧客が存在する場合、 \Stripe\Checkout\Session::create の引数のcustomerにStripeの顧客IDを渡してあげると、Stripeの決済画面にはじめからメールアドレスやカード情報が設定された状態になります(デフォルトの支払い方法が選択されます)

その他のパラメータについては、こちらを参照してください。

indexのViewはこの様になっています。

createCheckoutSessionのAPIを実行し、返却されたSession IDをもとに、Stripeの決済画面に遷移します。

決済完了後の制御

決済が完了すると、設定したWebhook URL宛にイベントが飛んできます。リクエストパラメータを確認し、アプリケーション側の継続課金の処理を行います。

$type にはイベントの種類が格納されています。また、 $object には以下のような値が格納されています。

object['data']['id'] がSession IDになります。

おまけ

ローカルでWebhookをテストする

Stripeの画面で設定するWebhook URLは外部に公開されている必要があります。ローカルでWebhookをテストするにはStripe CLIを使います。

上記のコマンドを実行すると、決済完了後に指定したURLにリクエストが送られてきます。

既存の顧客をCheckoutSessionで渡す

CheckoutSessionを作成する際に、StripeのCustomerを渡すこともできます。

継続課金の決済状態をバッチで確認する

一般的にWebhookは到達保障性が担保されていないため、決済が完了したかをバッチで確認し、完了していれば、user_subscriptionsテーブルを更新します。

StripeにCheckoutSessionを問い合わせた際、決済が成功していれば、以下のような値が返却されます。

継続課金の自動更新をバッチで確認する

自動更新の決済が正常に行われたかを確認し、決済に失敗していた場合、user_subscriptionsテーブルを更新します。

StripeにSubscriptionを問い合わせた際、決済が成功していて、Subscriptionが有効な場合、以下のような値が返却されます。

statusが決済状態を表しています。collection_methodがcharge_automaticallyの場合、最初の支払いが23時間以内に行われないと、statusがincomplete_expiredに変わり、以降の請求は行われません。

また、collection_methodがcharge_automaticallyの場合、更新のための支払いに失敗するとstatusがpast_dueが変わり、Stripeがすべての支払い再試行を終了するとcancelまたはunpaidとなります。

collection_methodがsend_invoiceの場合、請求書の支払いが期日までに行われなかった場合、statusがpast_dueに変わり、その後、追加の期日までに支払いが行われないと、cancelまたはunpaidとなります。

さいごに

Stripeで継続課金を実装する際の参考になれば幸いです。

おすすめ書籍

プログラミングPHP 第3版 PHPフレームワーク Laravel入門 第2版

page_footer_responsive




-BackEnd
-, ,

執筆者:

免責事項

このブログは、記事上部に記載のある投稿日時点の一般的な情報を提供するものであり、投資等の勧誘・法的・税務上の助言を提供するものではありません。仮想通貨の投資・損益計算は複雑であり、個々の取引状況や法律の変更によって異なる可能性があります。ブログに記載された情報は参考程度のものであり、特定の状況に基づいた行動の決定には専門家の助言を求めることをお勧めします。当ブログの情報に基づいた行動に関連して生じた損失やリスクについて、筆者は責任を負いかねます。最新の法律や税務情報を確認し、必要に応じて専門家に相談することをお勧めします。


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA


関連記事

rails

半年ぶりにRails Tutorialをやったメモ

はじめに Railsを触り始めて半年ほどたちました、tonnyです。 復習もかねてRails Tutorialを実施したので、そのメモを残します。 やはり2回目でも気づくことは多いので、非常に勉強にな ...

Rust入門してみた その3 Enum / match / Option編

1 はじめに2 Enum2.1 Enumの定義2.2 パターンマッチ2.3 Enumへのメソッド実装3 よく使う標準Enum3.1 Option3.2 Result4 おすすめ書籍 はじめに 前回に引 ...

rails

form_withでフォームの送信前に処理を行う方法

1 はじめに2 form_with3 サンプル4 さいごに5 参考 はじめに フォームを送信する前に処理を行いたいケース(Google Analyticsのイベントのトラッキングなど)があると思います ...

laravel logo

Laravelのブラウザテスト「Dusk」で非同期で重たい処理のテストを実装してみよう

1 はじめに2 JavaScriptの式で待機する2.1 テスト対象となるコード2.2 Duskのテストコード3 DOM要素の表示を待つ3.1 テスト対象となるコード3.2 Duskテストコードの実装 ...

rails

Railsのバリデーション

1 はじめに2 基本的なバリデーション3 EachValidatorクラス4 Validatorクラス5 autoload_pathsの編集6 さいごに はじめに 今回はRailsのActiveRec ...

フォロー

blog-page_side_responsive

2021年4月
 123
45678910
11121314151617
18192021222324
252627282930  

アプリ情報

私たちは無料アプリもリリースしています、ぜひご覧ください。 下記のアイコンから無料でダウンロードできます。
S