「一人でも多く、一円でも多く」価値を届ける決済の仕組みと工夫
本記事は CAMPFIRE Advent Calendar 2022 3日目の記事です。
こんにちは。CAMPFIREでエンジニアリングマネージャーをしている小川です。
11/30に10Xさん、カンムさんとの共催イベント「泥臭くも価値を届ける決済の仕組みと工夫」にCAMPFIREから私が登壇させていただきました。
今回はイベントで発表した内容を通じて、CAMPFIREの決済とその裏にある考えや工夫についてご紹介できればと思います。
クラウドファンディングの決済
そもそもクラウドファンディングの決済にはどんな特徴があるのでしょうか。
そのためにまず、クラウドファンディングがどのようなものなのからお話したいと思います。
クラウドファンディングとは
クラウドファンディングの一般的な定義は以下のようなものになります。
クラウドファンディングとは、「群衆（クラウド）」と「資金調達（ファンディング）」を組み合わせた造語で、「インターネットを介して不特定多数の人々から少額ずつ資金を調達する」ことを指しています。
プロジェクトオーナー(クラウドファンディングプロジェクトの起案者)の実現したいことに対して、共感や魅力を感じた支援者が支援をするというのが基本的なしくみとなります。
上記URLにもありますが、一般的な資金調達と異なり、「これをしたい！」といったアイディアや情熱があれば、誰でもプロジェクトオーナーとして起案でき、それに対して支援者もその想いやアイディアに魅力を感じれば、ハードルが小さく支援をすることができます。そのような双方にとっての手軽さがクラウドファンディングの大きな魅力の源泉となっています。
このクラウドファンディングには以下のようにいくつかの種類があります。
購入型
寄付型
融資型(ソーシャルレンディング)
株式型
ファンド型
ふるさと納税型
今回は記事の主旨上、それぞれの説明にまでは踏み込みませんが、ご興味ありましたら、以下をご覧いただければと思います。
本記事ではCAMPFIREでも多く取り扱っている「購入型」クラウドファンディングを前提にお話したいと思います。
購入型クラウドファンディングの特徴
購入型クラウドファンディングは、お金を支援することで、支援者がリターンとしてモノやサービスを得ることができるタイプのクラウドファンディングです。
購入型クラウドファンディングの成立方式には「All-in」、「All-or-Nothing」2つの方式があり、
All-or-Nothingは、期限内に目標金額を達成した場合のみプロジェクトが成立する
All-inは、目標金額に達していなくてもプロジェクトが成立する
という違いがあります。
All-or−Nothingは、金額が達成されない場合 = プロジェクトが成立しない場合、支援者に返金されます。やりたいことの実現に対し、目標金額で集まった資金が必ず必要になる場合は、こちらの方式が選択されます。
決済という観点でいうと、All-or-Nothingのプロジェクト方式は、支援をしたからといって、必ず支援者がお金を支払うことが確定するわけではない点が特徴です。支援者の支払いは、目標金額を期限内に達成し、プロジェクトが成立した時点で確定します。
また、ECと異なり、支援時点ではリターンが必ずしも用意されているわけではない点も特徴といえるでしょう。集まった資金をもとにリターンが準備されるケースもあるからです。
CAMPFIREならではの特色
こうしたクラウドファンディングにおいて、CAMPFIREの特色はなんでしょうか。
そのひとつが、支援に際して、多様な決済手段を用意していることです。全11種、以下のような決済手段を使うことができます。
クレジットカード
コンビニ払い
銀行振込（Pay-easy払い）
auかんたん決済
ソフトバンクまとめて支払い/ワイモバイルまとめて支払い
ドコモ払い
FamiPay
PayPal
楽天ペイ
PayPay決済
au PAY
どうしてこんなに決済手段を用意しているのでしょうか？それはCAMPFIREのミッションと関わりがあります。
CAMPFIREでは「一人でも多く一円でも多く、想いとお金がめぐる世界をつくる。」というミッションを掲げています。そのミッションに基づき、決済手段がないから想いを届けられないようにはしない、それが多様な決済手段を用意している理由です。
執行役員CPOの大橋もインタビューで以下のように回答しています。
ミッションはただ掲げるだけでなく、実際にあらゆる意思決定に絡めていますが、その表れの一つだと思います。
CAMPFIREの支援者は限られた属性の人に閉じず、全国各地の10代から70代以上まで年齢を問わず多くの方にご利用いただいています。
「私はいつもクレジットカードで決済しています」という方もいれば、「PayPayしか使いたくない」「楽天ポイントが貯まるなら支援したい」「ネット決済は難しいから銀行振込に対応して欲しい」という方までさまざまです。
決済習慣は支援者により多種多様なので、"自分に適した決済手段が用意されていないから支援を諦める"ということがあるなら、そうした体験はミッションに反していると思います。ですので、決済手段を幅広くご用意することで、支援者にとってストレスない体験を提供するという選択は、必然的な流れだったと考えています。
こうした多様な決済手段を実現するために、CAMPFIREはどのような工夫をしているのか、次節以降で見ていきたいと思います。
CAMPFIREの決済における課題と工夫
多様な決済手段のための課題とアプローチ
CAMPFIREは、「一人でも多く一円でも多く」を実現するため、多様な決済手段を用意しています。しかしながら、当然その分の決済に関連する考慮事項が増えてきます。
決済における考慮事項は多種多様です。
利用上限額はいくらか？
仮売上〜実売上の期限は何日か？
キャンセル期限は何日か？
キャンセル時の払い戻し方法は何か？
そもそも仮売上やキャンセルができるのか？などなど・・・
さらにAll-in / All-or-Nothingについても、決済の確定タイミングが異なってくるので、加えて検討する必要があります。
決済手段を追加するときは、これらの諸条件を加味しつつ、システム・運用設計を考えていかなくてはなりません。スライドにも書きましたが、これらをまともに考えていくと、考慮事項が複雑になってしまい大変です・・・。
こうした多様な決済手段をきちんとサービスにおいて提供し続けるため、私たちが取っているアプローチを整理すると「抽象化」と「単純化」と言えるかと思います。
それぞれについて見ていきましょう。
CAMPFIREの決済手段における抽象化
決済手段の抽象化のアプローチにおいては、「決済のパターン化」があります。多様な決済手段はそれぞれ相違点があるとはいえ、共通点もまた数多くあります。これらを抽象化してパターン化することで、決済における考慮事項をだいぶ整理して絞って考えることができます。
CAMPFIREにおける決済手段は以下3パターンに整理できます。
内部決済パターン
CAMPFIREサイト内で決済が完了するパターン
クレジットカードほか
外部サイト経由パターン
外部サイトに遷移して認証や決済完了するパターン
PayPal、LINE Pay、FamiPayほか
外部アクション経由パターン
決済予約をして、期間内に決済完了するパターン
Pay-easy、コンビニ決済
こうしてパターン化していくと、それぞれで大体設計や運用において注意すべき箇所が見えてきます。それぞれのパターンにおいて注意すべき点の一例をかんたんに紹介してみます。
内部決済パターン
一番スタンダードなパターンです。ここで主に考慮すべきは、エラーが発生した際のCAMPFIRE側のデータと決済サービス側とのデータ整合性です。
内部決済パターンは全体における比率も大きいので、運用における検知も重要ですが、そもそもそれを発生させないような実装も重要です。
たとえば、DBのトランザクション内で決済サービスへのリクエストをしていると、ロールバックが起きた際に、決済サービス側にのみデータが残ってしまうこととなります。そうしたことが起きないように、トランザクションと決済サービスへのリクエストは明示的に分離するといった工夫が必要です。
外部サイト経由パターン
このパターンにおいて考慮すべきは遷移した外部サイトでの離脱による決済中断です。
決済手段によっては、CAMPFIRE側、決済サービス側に処理途中扱いのデータが残ってしまうことがあります。
こうした点は実装してみて気づくことも多いので、抜け漏れがちですが、そうした処理途中扱いのデータを定期的にバッチで処理するなどして、データが中途半端な状態のままにしないことが大切です。
外部アクション経由パターン
このパターンにおいては以下2点の考慮が必要になってきます。
①決済完了通知のハンドリング
Webhook等による決済完了通知のハンドリングが必要です。エラーで通知を適切に拾えなかったときに、そのアラートで気づき、リカバリする仕組みが必要になります。
②期間内に入金が完了しなかったことによる決済中断
同じように期間内の入金が行われなかったことも適切に検知する必要があります。
さらにこうした通知がそれでも漏れていたケースも考慮して、定期的なCAMPFIRE側 - 決済サービス側の突合も必要でしょう。
CAMPFIREでの設計・実装においては、こうしたパターンは継承関係で表現されています。最初から明示的にこのようなパターンがあったわけではないのでやや継承がもつれていますが・・・
こうしたパターン化をすることで、決済を追加するにあたっても、予めどのような作業が必要か、留意事項はどのような点か、といったことを明確にすることができています。
社内では決済追加時に考えるべきことを整理したドキュメントがあり、これらを見ながら、要件や設計を詰めていきます。また、実装においてもパターンに当てはめつつ、各決済手段の差異は具象クラスに閉じ込めることができています。
CAMPFIREの決済手段における単純化
決済手段における単純化として挙げたいのは、実現される価値と、もたらされる複雑さを考慮した上での、割り切った意思決定です。
その一例として、以下では再オーソリの扱いについて見ていきたいと思います。
まず、CAMPFIREでは再オーソリをしていません。そのため、All-or-Nothingのプロジェクトにおける募集期間は、クレジットカードの仮売上期間の範囲内(60日)です。
このことは、一見すると不合理な選択に見えます。
募集期間を長くできたほうがプロジェクトの成功率が上がるように思えるからです。では、どのような観点からこのような意思決定をしたのでしょうか？
まず、開発者やPdMといった内部の観点があります。
その観点からのひとつは、再オーソリが持ち込む複雑さです。たとえばプリペイドカードやデビットカードは、性質上、再オーソリをすると一時的に二重引き落としとなります。再オーソリを許容する場合は、こうした点をどう扱うかと向き合わなくてはなりません。
また、他の決済手段との兼ね合いもあります。決済手段のなかには、コンビニ決済のように、そもそも仮売上や再オーソリがないものもあり、クレジットカードでのみ再オーソリで募集期間を長くするとしても、他の決済手段とのバランスがちぐはぐになってしまいます。
もうひとつはユーザー体験の観点です。
その観点からは、再オーソリがもたらすプロジェクト期間の延長が、プロジェクトの成功にとって必ずしも寄与しないと思われました。
極端な例ですが、プロジェクト期間が半年になったとしたら、どうでしょうか？公開して支援しようかな？と思ったとしても、まだ終了まで時間があるから今すぐでなくてもいいかな、となってしまいそうです。
プロジェクト自体の熱量を考えた場合、やみくもにプロジェクトの期間を延ばすのが良い結果をもたらすことにはなりません。
実際、目標金額を達成したプロジェクトは、募集期間が30-45日間のものが多いとの結果が出ています。
以上、再オーソリを例にした、単純化の判断について見てきました。ここで重要なのは、必ずしも内部の都合だけで単純化の判断をしているわけではないということです。その裏にはユーザーにとって利益になるか、あるいは不利益にならないかの判断軸があります。
今回のケースでいえば、再オーソリはユーザーにとってもそんなにメリットをもたらさないものでした。それが「CAMPFIREでは再オーソリをしていない」という意思決定につながっているのです。
おわりに
以上、先日の登壇でお話したことをベースに、CAMPFIREの決済の特色と、そのために工夫していることについて書いてきました。まとめると、以下となるかと思います。
CAMPFIREは、「一人でも多く一円でも多く、想いとお金がめぐる世界をつくる。」というミッションのつながりから多様な決済手段を用意している
その多様さを支える裏側にある複雑さに対処するために色々工夫をしてきた
決済処理のパターン化
決済処理の単純化の意思決定
決済の設計や実装はいろいろと考慮すべきことが多く大変ですが、そのぶんやりがいもまた多く楽しいものでもあります。
今回の記事において、その難しさと楽しさを少しでもお伝えできたら幸いです。
この記事が気に入ったらサポートをしてみませんか？