今回、決済サービス「Stripe」の Connect 機能を利用して、イベント決済サービスを実装しました。

■やりたかったこと

現在600名ぐらいの会員数のサポートサイトの開発、運営をしています。

こちら → FANCアカデミー

パーソナルトレーナーさんの活動サポートさんとで、ポータルサイト化を進めています。

今回、会員さんが自身で企画されたイベントの申し込みページを作成する機能を実装することに。

事前決済機能を実装するに当たり、協会としては手数料のみを扱い、決済金額は会員さんの指定口座に直接入金できるようにしたかったのです。

■Stripeを使った理由

今回、当初は Paypal を考えたんですが、なんか使いにくそうだったんで、なんか無いかなぁと探してたところにハマってくれました!

それと、サポートが秀逸だったから!

もう、一にも二にもこれです!

困ったときのサポートさん!それと、FBグループさん!

ほんと、ありがたかったです!

■Connect機能を実装にあたっての方針

アカウントをどちらにするのか?

まず決めることは、アカウントを「スタンダード」とするか「カスタム」とするか。

いろいろ掲載されている情報をマージしてみました。

スタンダード(Standard) カスタム(Custom)
一般の Stripe ユーザのように、売り手自身が Stripe アカウントを Stripe のフォームから作成し、アカウントを管理します。

Stripe の管理画面(ダッシュボード)へ、売り手自身がアクセスできるようになります。

こちらは、Shopify や Jimdo などの E コマースプラットフォームや、オンライン予約システムを提供するプラットフォーム、オンラインで請求書等を管理できるプラットフォームのようなケースで多く利用されています。売り手自身が独自にウェブサイトなどを持ち、プラットフォームから決済機能を連携させるなどのユースケースです。

アカウントの管理は売り手自身が行うので、チャージバックや返金、マイナスの残高が発生した場合は売り手自身が責任を持ちます。

プラットフォームがユーザエクスペリエンスをフルカスタマイズしたい場合に向いています。

子アカウントの Stripe アカウント登録から管理まで、全てをプラットフォームが提供し管理するため、Stripe ブランドを売り手に見せることなく決済周りの設定を構築できます。

また Custom では、決済から振込までの資金フローも柔軟にコントロールできるので、あらゆるケースに対応できます。例えば、

・予約時からサービス提供までの時間が比較的長い場合、プラットフォームが子アカウントへの入金タイミングをコントロールしたいというケースがよくありますが、そのようなときには Custom がおすすめです。

・モール型のビジネスのように、モール上で複数店舗から商品を買う場合には、一つの決済を複数の店舗に分けたいという場合もありますが、この場合は Custom のみ対応が可能です。

当初は「カスタム」を考えていたのですが、子アカウントの登録までの敷居がちょっと高いなぁっていうのと、要件としては「スタンダード」で十分なので、「スタンダード」で実装することとしました。

ただし、会員さんには、パソコンをお持ちでない方もおられるので、また、うまく登録できないで問い合わせが多そうなことが予想されるので、子アカウントの登録自体は弊社が行うこととし、会員さんからはGoogle Formで情報をもらうようにしました(^^)

チャージ方法はどうするのか?

チャージ方法には、「Direct Charge」と「Destination Charge」の2種類があります。
※もう一個「Shared Charge」あるんですが、ここではカット(^^;

お金の流れと、カスタマー情報を子アカウントと、プラットフォームのどちらで持つが異なります。

カスタマー情報は、「Direct Charge」が子アカウント側。「Destinaion Charge」がプラットフォーム側。

プラットフォーム側に集約されたらナニがナニかわからなくなるだろうから、子アカウント側に持ってもらうようにしたく、「Direct Charge」となりました。

■Connect機能利用の流れ

事前にもととなるストライプアカウントで「プラットフォーム」と呼ばれる設定が必要です。

その画面例です。

Stripe Connectの実装 その1.5」に続く(^^)