2019年3月2日土曜日

Webサービスにおける少額決済の実装面での現実

前稿でGoogle Pay, Google Pay + Payment Request API, Microsoft Payに対応する事を決めたのですが、実際に実装をしてみると課題がたくさんわかりました。

1. すべてのプラットフォームで動かせるOAuth決済基盤は少ない

OS/ブラウザサポート状況を掴むのは意外と面倒なので、まずはそこをまとめました。 上記の対応状態を見るとGoogle Payにさえ対応しておけばあらゆる環境に対応できる。 Apple Payも気楽に使えるかと思っていたのですが、MacだとTouch IDが必要だったり、細かな条件が色々あって割とハマりやすい気がする。 特にiPhoneではカードごとの専用アプリでクレジットカードを認証しないと使えないのには驚きました。 Web認証用のIDを持ってる人って少ないと思うんですよね。 少なくとも私は持ってなかったので面食らいましたし、少し面倒だなと思いました。

2. 巨大プラットフォーマーのOAuth決済は結構お金が掛かる

ではGoogle Payが最強なのかというとそうでもない。 最初に調べた時は記載されていないので気付けなかったけど、いざ中の人とやり取りすると実は、みたいなところが色々ありました。 実際掛かる手数料をGoogle Pay以外も含めて、確認が取れているものだけまとめると、こんな感じになります。
  • Amazon Pay: カード決済基盤に月額3,000円、決済手数料4〜4.5%
  • Google Pay: 決済手数料なし、ただしGoogle Playのmerchant IDを通じて販売
  • Apple Pay: Developer Programに登録が必要なので年間99ドル
    • iOSアプリでなければ決済手数料30%は取られない
なんか意外と高いなあ。 Google Payが実装時点では一番安く見えたのですが、使い方によっては一番高くなるのが意外でした。 いざ中の人に申請をしている時にGoogle Playのアカウント必要だし、手数料はそこに依存するよと言われ、おんぎゃーとなりました。 Payは無料でもPlayで取られるのかあ。甘く見ていた。
Google PayにはStripeでそのような記載がなかったので、掛からないのかと思ってしまいました。 merchant IDがどのように結び付くのかで調べるべきだったようですね。やり取りの結果、手数料が掛かるとわかりました。 Microsoft Payのmerchant IDももしかしてMicrosoft Store (収益分配率95%) に依存するのかなあと思ったけど、こちらはStripeのドキュメントには追加手数料は掛からないと書いてある。む、難しい…。

3. 自社にカード情報を送信しないで済むOAuth/ログインID決済が良いかも

Google Payは手軽にあらゆる環境をサポートできるので便利ですが、他の決済基盤より高いし、少しレスポンスが悪い問題があります。 またGoogle Payに頼り過ぎになってしまう問題も出てくるでしょう。 無料でもう少し頑張る方法がないかという事になるのですが、実はいくつかの選択肢がある。 Stripe CheckoutとPAY.JP Checkoutです。

Stripe CheckoutはログインID決済なのでメールアドレスとクレジットカード番号を収集しないといけないのですが、 それらをStripeが管理してくれる仕組みを用意してくれている。 ログインIDの決済を利用すると基本的に自社サーバ内にデータを保持する必要がありますが、そこをStripeが担保してくれるので手軽に信頼性が高まる。これは嬉しい。 自社に機密情報を持たないで済むぶんだけ若干セキュアなのかなあ。

PAY.JP CheckoutはOAuthなのでカード番号の送信も不要になります。 その場でOAuthでログインしてカード番号を受信して補完し、そして決済するという仕組み。面白い。 たぶんこちらのほうがよりセキュアな仕組みになっていると思います。

これらのサービスは手数料も安いし、APIもオープン、申請も自動化されており、どのような環境でも動くUIを提供してくれており、なおかつ決済が非常にスムーズという、非常に素晴らしい機能を提供してくれています。 私は強大なプラットフォーマーのOAuthのほうが強いかもと最初は思ったけど、こちらのほうが良いかも知れない。 このレベルでサービスを提供してくれれば是非とも使いたくなります。

4. Payment Request APIの実装は全然楽じゃなかった

Payment Request APIを使った決済処理の実装は、実装が一緒で済むから楽そうだと思ったのですが、そんな事はなかった。 実際に実装してみてわかったのは、確かにPayment Request APIの仕様に準拠する部分は実装が楽なのですが、ブラウザに依存する部分の実装はバラバラで、全然楽じゃありません。 コードでは new PaymentRequest() あたりですかね。 どうせ各ブラウザでしか表示できないUIをサポートするために、仕様が微妙に異なる実装をブラウザ毎に書くのはかなりストレスです。

この問題、またしてもStripeは解決策を用意してくれていて、 Payment Request APIを使う決済処理基盤に対して、Stripe Request Buttonという統一的な仕様とUIを用意してくれている。 基本的には素晴らしいものなのですが、完璧なものという訳でもないんですよねえ。 第一の理由は、そのものの問題ではなく、ストアのロイヤリティがバラバラなせいで利益を圧迫する可能性がある事です。 統一的なUIで表示すると当然ながら価格は同一にしないといけないけど、〜30%のロイヤリティを適当に取られるのは割と面倒だし、勝手に利益率が下がる可能性を抱えるのもちょっとなあ。 といってストアごとに実装するかと言われると面倒過ぎ、Payment Request APIは現状があるべき姿なのかよくわからない。

第二の理由は動かない事があるため。 これはたぶんChrome 70の挙動がめちゃくちゃ変わったのが原因で、Chrome 70以降からブラウザをインストールした人にはボタンが表示されないバグが出てしまっている気がする。 ちょっと正確なバグはよくわからないので、私は偉い人が解決してくれるのを待っている。 他にも例えばMac+Chrome (70-?) でたぶん動かないし、iOSのChromeでもたぶん動かないような問題を認識している。 このようにPayment Request APIは理想は素晴らしいものの、現実では意外とうまく動かない事がわかってきました。つらい。 正直とても対応する気にはなれないし、すべての環境で動くものを使って、時代の流れに身を任せようと思ってます。

このような理由から、私はPayment Request APIには力を入れてません。 デスクトップのPayment Request APIは最初触った時にはなかなかイケていただけに、残念な感じです。 あとちょっと気になるのが、Chromeの chrome://flags です。 これを見るとPayment Request APIではなく、PWA＋少額決済に関する本気度を感じられると思うので、一度見てみると良いと思います。 逆にマイクロソフトは自社モバイルOSからiOSやAndroidに乗り換えを推奨しており、Payment Request APIに依存するMicrosoft Payの扱いも少し不安ではある。

5. ブラウザにクレジットカード情報を入れられなくなるかも？

クレジットカードの入力をなくす方法は、OAuthによる決済や、ログインIDによる決済以外にも、ブラウザにカード情報を保存する方法も、選択肢として一応は考えられます。 私はこれも結構便利かなと思っていたのですが、Chrome 70からクレジットカード情報はブラウザ内に記憶しなくなくなりました。 おまけにGoogle Payに登録しているクレジットカードは使えなくなったので、basic-cardの指定は想像以上に使いにくいものに変わってしまった。

セキュリティ的には良い改善と思うけど、basic-cardを毎回入力するのはさすがにちょっとね。 今は他のブラウザでは使えるものもあると思いますが、将来的にはもしかすると、ブラウザに記憶はできなくなる事も想定しておく必要がありそうです。



このような実装上の様々な問題はあったものの無事、決済処理の実装は完了し、サービスもリリースする事ができました。 今後もユーザを増やすために、なるべく無料で、より多くの決済基盤に対応していきたいと思っています。 Stripe CheckoutやPAY.JP Checkout的なものをどこかの会社が作ってくれればすぐに採用する予定です。

今のところはAlipayが次の候補に上がりそうだけど、ブラウザのサポート状況を見てという感じである。どこに書いてあるんだろう。 あとAlipayは手数料無料を謳ってるけど、Stripe経由だと手数料は掛かるはず。 手数料を無料にはできないのかな。この辺はきちんと調査していないので、いずれ調査したい。


以上で少額決済全体を俯瞰するお話は終わりですが、Google Pay API + Payment Request APIの実装方法はこちらにまとめておきました。 よろしければこちらもどうぞ。

0 件のコメント:

コメントを投稿