BackEnd

Stripe Connectで支払方法をクローンする

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

はじめに

Stripe Connectには、資金の流れとして大きくダイレクト支払いとデスティネーション支払いという流れがあります。
ダイレクト支払いは、Shopifyのように、ユーザにプラットフォームの存在を意識させないようなSaaSを運営する際に適しています。ショップに送金された金額の一部を、手数料としてプラットフォームに入れることができます。
デスティネーション支払いは、楽天市場のようなマーケットプレイス型のWebサイトを運営する際に適しています。一度すべての金額がプラットフォーム側に入り、それをプラットフォームの裁量で店舗側に配分することができます。
そのため、支払方法をまとめたいというユースケースは、通常デスティネーション支払いの方が適していると思いますが、今回は個人間で送金・返金できるマッチングサービスのようなサービスを作りたいと思うので、ダイレクト支払い方式を使用しますが、クレジットカードの管理は一か所にしたいと思います。

ダイレクト支払いの場合は前回説明した通り、Connectアカウントごとに顧客管理する形になります。この場合、顧客は店舗ごとに支払方法を登録しなければなりません。その手間を省くためには、支払方法をクローンすることで解決できます。今回は支払方法のクローンについて紹介します。
今回は、前回の記事の続きになります。前回の記事はこちら。

プラットフォームの顧客側の実装

前回までの記事では触れませんでしたが、今回はプラットフォームの顧客が必要になるので、顧客登録・支払方法の登録を実装していきます。

プラットフォームの顧客登録

まずは、プラットフォームの顧客を登録します。決済時にこの顧客から支払方法をクローンするため、サイトの登録時にサイトプラットフォームの顧客を登録するようにします。

 

支払方法の登録

作成した顧客に対して、支払方法を登録できるようにします。

まず、ルーティングです。前回作成したものに追記します。
web.php

次に、controllerです。

支払方法の登録はプラットフォーム顧客に対して行うため、ここではまだConnectアカウントは登場しません。
function editPaymentMethod() では、支払方法登録ページを表示しています。支払い方法が登録済みのユーザ向けに、現在のクレカ番号の下4ケタを表示するため、顧客と支払方法を取得しています。
function updatePaymentMethod() では、実際に支払方法を変更します。顧客に支払方法を登録した後、デフォルトの支払方法を変更することで、以降に申し込むサブスクリプションはこの支払方法が使用されます。

最後に、viewの実装です。基本的には、前回までに作った支払ページと同じです。

ここまで作成すると、このような画面でプラットフォーム顧客の支払方法を登録することができるようになります。

支払方法クローンの実装

前回までの記事までで、Connectを使用してサブスクリプション製品を登録するところまで実装済みです。まだの方は前回の記事を参考にしてください。

顧客と支払方法のクローン

支払方法がプラットフォーム顧客に登録できたところで、今度は実際に支払方法をクローンしたうえでサブスクリプション登録するところを説明します。
前回作成したProductControllerの subscribe() を編集します。

支払方法のクローン

まずは、支払方法(PaymentMethod)をクローンします。

PaymentMethod::create() の第一引数のパラメータにクローン元の支払方法を指定することで、支払方法をクローンできます。また、併せてプラットフォーム顧客を指定する必要があります。
また、第二引数のパラメータに stripe_account を設定することで、Connectアカウントに紐づく支払方法となります。

顧客のクローン

email は後で実装する顧客重複チェック用に登録します。
payment_method は先ほどクローンした支払方法を指定します。
invoice_settings.default_payment_method も同じく先ほどクローンした支払方法を指定します。これを指定することで、この後のサブスクリプション登録で、紐づけた支払方法が使用されます。
先ほどと同じく第二引数に stripe_account を指定することで、Connectアカウントに紐づく顧客になります。

サブスクリプション登録

最後に、サブスクリプション登録を行います。以下のようにパラメータ設定を行います。
customer には先ほどクローンした顧客IDを指定します。
items は課金アイテムを指定します。
第二引数は、先ほど同じようにConnectアカウントを指定します。

顧客と支払方法クローンの全体ソースコード

店舗の顧客の重複チェックは、前回実装したものと同じロジックです。また、すでに店舗顧客が存在する場合は、その顧客に紐づいている支払方法を使用すればよいので、新たにクローンは行いません。

サブスクリプション登録ページの修正

支払方法をクローンする流れに変更したため、以前までサブスクリプション登録ページにあった支払方法の登録フォームを削除し、シンプルな形にしたいと思います。

ここまで作成すると、以下のような画面でサブスクリプションを登録できます。店舗をまたいでも、プラットフォーム顧客に登録してある支払方法を使用できるので、顧客がいちいち支払方法を入力する手間を省くことができます。

Stripeの管理画面では、次のようにプラットフォームから店舗に顧客と支払方法がクローンされていることが分かります。

▼プラットフォームの顧客

▼店舗にクローンされた顧客

さいごに

Stripe Connectのダイレクト支払いでも、ユーザが支払方法の入力の手間を省くことができました。ぜひ参考にしてみてください。

おすすめ書籍

PHPフレームワークLaravel入門 第2版 PHPフレームワーク Laravel実践開発 PHPフレームワーク Laravel Webアプリケーション開発 バージョン5.5 LTS対応 よくわかるPHPの教科書 【PHP7対応版】

blog-page_footer_336




blog-page_footer_336




-BackEnd
-, ,

執筆者:

免責事項

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


comment

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

CAPTCHA


関連記事

rails

Railsのバリデーション

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

Rust入門してみた (基本構文編)

1 はじめに2 Rustとは?3 Rustの特徴的な基本構文3.1 変数と定数3.2 所有権3.3 所有権の借用3.4 関数3.5 エラーハンドリング3.5.1 回復不能なエラー(panic!)3.5 ...

Rust入門してみた (構造体 / トレイト)

1 はじめに2 構造体2.1 メソッド2.1.1 関連メソッド2.2 トレイト2.2.1 構造体のフィールドの1つとして、トレイトのインスタンスを持つ場合2.3 derive属性3 おすすめ書籍 はじ ...

laravel logo

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

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

rails

Railsでの非同期処理とDelayed Job

1 はじめに2 Active Job2.1 Active Jobの役割2.2 ジョブを作成する2.3 ジョブをキューに登録する2.4 コールバック2.5 例外3 Delayed Job3.1 設定3. ...

フォロー

blog-page_side_responsive

2021年4月
 123
45678910
11121314151617
18192021222324
252627282930  

アプリ情報

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