- 最近参入 LINE Pay、楽天ペイ、PayPay、Origami Pay、pring、d払い、Amazon Pay、Pay ID、pixiv PAY、Sma-sh Pay、EPOS Pay、＆Pay、atone、銀行Pay
- 参入予定: メルペイ、ゆうちょPay、7pay、Bank Pay、au PAY、ファミペイ、Payどん
大前提としては、少額決済は少額になればなるほど、気軽に払えるかどうかが鍵と思っている。 決済手数料、月額利用料は低ければ低いほど良いし、固定手数料は0が基本だろう。 実はこの条件の時点で大半のサービスが脱落する。
他にも覚えるのが大変なクレジットカードを毎回入力するより、 覚えるのが簡単なログインIDによる決済や、QRコード決済のほうが優れるだろう。 手数料は日々変動するのでまとめるのが大変だから、今回は主にこのユーザビリティの部分についてまとめておく。
1. ログインIDによる決済
良い言葉がなかったので適当に名付けたのですが、ここではクレジットカードを事業者に記憶してもらい、ログインIDだけで決済する方法を指している。 ログインして即支払いが完了すれば、毎回入力するより遥かに楽です。 一般的にはメールアドレスとパスワードを使ってログインIDと紐付けるため、 新規事業者がそのような仕組みを提供しようとする場合、メールアドレス、パスワード、クレジットカード番号を保存する必要が出てくる。 ただどこの誰かもわからない適当サイトにクレジットカード番号を教えるのは、不正利用や情報漏えいのリスクが伴う。 そのへんがログインIDによる決済の弱点だと思う。 いずれその辺で選別がなされていくと私は思っていて、そこをクリアしている決済サービスだけが生き残っていくのではないでしょうか。 私はPAY.JP Checkoutは良い仕組みだなと思いました。ログインIDによる決済サービスは山のようにあってまとめるのはギブアップ気味だし、本ページの趣旨とは外れるので、参考になったまとめサイトだけ載せておきます。
- 決済サービス比較ナビ
- 決済代行サービス比較30選｜各サービスの対応決済手段や特徴まとめ | Torteo Magazine
- おすすめのネット決済サービスはどれ？33個のサービスの特徴をまとめてみました｜ferret [フェレット]
2. OAuthによる決済
先に述べたクレジットカード番号の入力の手間やトラブルを解決する方法はあります。 信頼のおける大企業のログインIDにOAuthなどの仕組みを使ってログインし、決済すれば良い。 信頼のおける大企業がクレジットカード番号を管理する事で、情報流出もクレジットカード被害も最小限に抑えられる。 ちなみにログインIDによる決済を行っているサービスでも、メールアドレスやIDとトークンと結び付けて管理すれば十分実現可能なのですが、わざわざメールアドレスを登録するのは面倒なのではないかとも思いますし、運用側にとってもそのような手間を省きたいと考えるのは自然だと思います。OAuthによるトークン決済を採用したサービスは徐々に増えてきていて、例えば今なら米国企業のStripe, Google Pay, Microsoft Pay, Apple Pay, Amazon Pay, Facebook Pay、中国企業のAlipay, WeChat Payなどの巨大プラットフォーマーのOAuth決済が日本でも利用できる。 上記に書いた企業と比較するとややマイナーですが、日本企業でもPAY.JP Checkoutというものがあります。
米国大企業のほぼすべてが自社ログインIDを採用しているのは印象的で、実にわかりやすいプラットフォーム戦略だと思う。 その中でGoogle Pay, Microsoft Pay, Apple Payは決済の外側だけを用意しているだけで、実際にはStripeやSquare、クレジットカード会社などのプロセッサーが必要になっていて、そこで決済手数料が掛かるようになっている。このへんの料金の話も、最初は安いかもと思ったものが実は高かかったりと割とハマったので、実際に実装してみて気付いた話も参考にしてみてください。
中国のAlipay, WeChat Payも手数料無料です。 この理由は、消費者金融機能からの収益、公的機関から手数料を取る仕組み、支払い履歴のビッグデータ活用などと言われている。 現金化時に0.1%の手数料を取られはするが、ほぼ手数料を取られないというのは、なかなか強い仕組みだと思う。
3. Payment Request APIによる決済
Microsoft Pay、Apple Payは、W3Cによって標準化されたPayment Request APIを用いた決済サービスです。 Google Payは利用しても動作するし、利用しなくても動作する。 それ以外のサービスとしては、Samsung PayはPayment Request APIを利用しているみたい。Payment Request APIはブラウザに対応するプラットフォーマーのネイティブな決済基盤が立ち上がる仕組みになっている。 ネイティブ実装なので起動が早いのが特徴だと思う。 ChromeでAPIを呼び出すとGoogle Pay、Edgeで呼び出すとMicrosoft Pay、Safariで呼び出すとApple Payが起動するような要領である。 おのずとプラットフォーマーがネイティブの実装をしていなければ機能しない仕組みになるような気がするのだが、そのせいもあってかFirefoxはAPIの実装はされているものの、Payment Request APIでの決済はできない。
Payment Request APIに関する部分だけはほぼ同一のコードで様々なプラットフォームでの決済に対応できるようになるのが良い点です。ただこれも実際に実装してみるとそんなに簡単なものじゃないですけどね…。
4. QRコード決済
では最近流行りのQRコード決済はどうか。QRコードはメールアドレスを入力するより楽なのは確かです。 ただ事業者、特にWebサービスやアプリの開発者からすると簡単な話じゃなくて、セッションの問題が出てくる。 QRコードで決済する場合、QRコードで商品を選び、決済アプリからトークンを取得し、そのトークンに基づいて決済を行う。 しかしサービス側と決済を行った端末にはセッション上の繋がりがないので、 ユーザは支払いをサービス側に何らかの手段で通知する必要がある。 この手段としてはログインIDやトークンが必要になるのだけど、トークンの入力は煩雑で現実的ではない。 ようするにやっぱりログインIDを管理しなきゃ簡略化できないじゃんという事になってしまう。QRコード決済は信頼のおける基盤を持たない事業者や、非IT業者には良さげに見えるかも知れないけど、 そうではない場合、現状では大手のログインIDに委託する決済よりコストが高く付いてしまう。 既にセッションに対応しているのもあるかもだけど、多過ぎてもうよくわからんし…。 いくつかのAPIを眺めている限りではそのような事を感じました。 コストが高く付く実例としては、PayPayでクレジットカードの不正利用の話が少し前にホットになりました。 QRコード決済のセッションが分断されて、そこに人の手が入ってしまう事もあって、中間者攻撃が成立しやすかったせいもあった事件かなと思ったりします。 実際にサービスを運用する上ではそういった事も注意しないといけないです。 なんちゃら祭りというのはハッキングの格好の標的になりやすいですしね。 中国では既にハッキングが結構大きな問題になっているようで、この記事を読むと様々な手口がわかります。 非常に参考になる記事なので一度読んでみると良いかも知れません。
リスクのあるセッション回りは自動化したほうが絶対良いと私は思うし、実装自体は簡単だと思うので、そこを一括処理してくれる機構はいずれどこかが実装してくるのではないかと考えています。 仮にそのようなサービスが出てきたら、QRコードでWebサービスのログインができるようになるはずで、その時が一番面白い瞬間かも知れません。 Webサービスでの利用は、そのようなサービスが出てくるまでは待ちです。
QRコード決済サービスも、ログインIDによる決済と同様の理由で、よくまとまってると思ったまとめページだけ記載しておきます。
5. その他様々な個人間決済
最近は色々な個人間決済アプリが出てきています。 米国ではVenmoが有名ですが、Square Cashとかも出てきました。 日本ではPaypalが個人間決済に対応した事は記憶に新しいですが、Kyash, paymo (終了予定), polcaなど、形を変えて様々なサービスがあります。他にも何かあるかな？ これらもQRコード決済と同様で、セッションの問題が発生しない取引なら良いのですが、セッションの問題が生じるWebサービスでは使いにくい。 というかおそらくQRコードより実現可能性は低い状態だと思います。 ただこういったアプリがたくさん出てきているのを見ると、個人間決済は世界的にも流行なのかなあ。このような現状を踏まえた結果、私は自前でログインIDを管理しなければいけない少額決済サービスへの対応と、QRコード決済への対応は後回しにし、まずはStripe, Google Pay, Google Pay + Payment Request API, Microsoft Pay, Apple Payに対応してみようと思いました。 その後実装を進めるとやっぱ対応しなくても良いかなというものもあったり、やっぱこっちのほうが良いじゃんという事もたくさんあったりしました。 なので実際に実装をしてみて気付いた事をまとめたこちらのページも参考にして頂けると幸いです。
0 件のコメント:
コメントを投稿