決済サービスが用意している定期課金機能でWebサービスの定期課金の仕組みを作るべきでない事例をまとめた
2017-08-02 07:01:37 +0900
課金決済サービスの定期課金機能は使わない方がポータビリティ高いし、
— {{ nick }} (@webuilder240) 2017年6月29日
色々イレギュラーが出るので
使わない方が後々幸せというのがぼくの意見です。
そのうちこれはブログに書こうと思います。 https://t.co/p8OQWhnlwl
— {{ nick }} (@webuilder240) 2017年6月29日
ということなんで、書いてみました。
決済サービスが用意してくれている定期課金の仕組みは利用しないほうがいいと個人的には思っている。 1年以上この仕組みでやってきたが、なかなか弊社案件ではちょっとつらいものがあって、今後のために色々書いておこうと思ったので書いた。
先に書いておきますが、利用している決済サービスに対しては概ね満足しており、 特定の決済サービスへの批判ということではないということをご了承いただきたいです。
いきなりまとめ
- サービスロックインが心配
- イレギュラーな事例への対応ができない（しにくい）から。
- 複数決済サービスの利用時に期間や挙動に細かい差異の吸収ができない。
- 要件がかっちり決まっており、仕様変更が未来永劫ないか、今後実装変更のために時間を利用できる場合は自前実装はしなくてもいい。
ということで、理由をざっくり説明したいと思う。
1. サービスロックイン
これは最近あった事例だけど、決済サービスが大手企業がバックに付いていても某社の様にサービスがなくなるかわからない。 スタートアップ企業とはそういうものだし、そんなときに定額課金を各サービスに依存している場合、相当苦労することだろう。 移行先の決済サービスに定額課金の機能が存在していても、（殆どのサービスのところは存在しているはず）
細かい挙動（次の決済日時算出ロジック）が違ったりして、意図しない課金日に設定されたりということがあるいうことを考えるとそのまま全く同じに移行して動くという保証はない。
こういったリスクを最小限に抑える場合は、自前で定期課金の仕組みを実装するべきである。 当然再実装は必要になる部分はどっちにしろあるけど、殆どの場合で同じように動かすのは容易だと思う。
大きく決済周りの実装を要件の変更に対応することもあるだろうから、 その際に、「特定のサービスに依存していない」というのは強みになると思う。
特に弊社では決済周りの実装がカスタマーによって細かく異なるケースも存在する可能性もあることから、 サービスロックインは無い方が良いのでは？と思い始めているというのも理由の一つだと思う。
2. イレギュラーに対応できない。
イレギュラーといっても色々あるが、簡単にいえば決済サービスが定期課金のAPIで実装されていないけどやりたいことの全部である。 日割り計算が決済サービスの定額課金APIでなければそれだし、 他にも複数のプランがあって、途中のプランのアップグレードやダウングレードを考慮するときに、 「差分だけ支払ってアップグレードする」ということが難しいというか、定期課金のAPIで実装されてない場合。仕組み上不可能に近い。
他にも「XXXXできますか？」「XXXに対応しないといけない」という特殊な要望もあるだろう。 それを今後対応する場合でも最初から見据えて実装するべきである。 これらに対して柔軟に対応したい、ということを考えると自前定期課金の仕組みを実装するべきだと思う。
3. 複数決済サービスの利用時の期間や挙動に細かい差異が生じる
課金を取り扱うサービスの場合、複数の決済サービスを利用することが可能性としてあがってくる事がある。 クレジットカード決済でも審査の都合からJCBが使えないというトラブルもあり、Paypalをイレギュラーに利用する場合もあるだろう。
他にも銀行振込の決済サービス・携帯のキャリア決済・コンビニ払い、さらには外貨サービスは別かも…と、 多種多様の支払い方法があり、それらに対してすべての支払い方法を対応するようなケースも想定される。
当然すべての支払い方法がカバーされている決済サービスを利用すれば良いのだが、 手数料やビジネス上の問題から、それぞれの支払い方法で最適な決済サービスを選ぶこともあるだろう。
会社・サービスが異なると、基準となるタイムゾーンなどが異なる場合もあり、決済サービスと自分たちの意図している課金日がずれてしまったりすることも存在し、 課金日を厳格にアプリケーション側で管理したいような性質のサービスの場合は、決済サービスで自前で定期課金の仕組みを作った方が圧倒的に気楽である。
まとめ
簡単ではあるが、定期課金処理について少し困ったことを吐き出してみた。
決済サービスに依存した定期課金処理は実装もラクで便利ではあるが、 使いどころを間違えると後で痛い目に遭うので、導入には大いに時間をかけて検討するべきである。 この記事を決済処理を実装する前の自分におくりたかった…
やっぱり弊社案件では定期課金に対しても柔軟性が必要になるケースがあるかもなので、 これから時間を作って、定期課金の実装を自前のものに載せ替えることを検討している。
参考記事とか
www.bokukoko.info www.bokukoko.info
最後に
僕の働いているオシロ株式会社ではエンジニアを募集しています。
手前味噌ですが、面白い福利厚生や会社制度もありますし、 普通のWebサービスではあまりないような課題があるので、やりがいがあるんじゃないかな。と思っています。 まずは話を聞いていただけるだけでもとても嬉しいので、まずはWantedlyの採用ページを見てみてください。 何卒よろしくお願いいたします。