Amazon PayとPayPayを入れたら決済完了率が54%上がった話
落とし物防止タグMAMORIOの配送ありの決済ページにAmazon PayとPayPayを導入したところ、ユニークユーザーあたりの決済完了率を約54%向上させ、結果として売上も約76%向上させることに成功しました。
それまでは決済サービスのPAY.JPを利用してApple Payとクレジットカードの決済手段を提供していたのですが、Androidユーザーに不利であることと、PAY.JPが今年新たにAPI v2をリリースしてPayPayを提供したことをきっかけに、PayPayと住所入力を省略可能なAmazon Payを導入することにしました。
その結果、現在はユーザーが利用する決済手段の60%がAmazon Payになり、7％がPayPayになっています。
Amazon Payが日本で登場したのは2015年5月11日（米国では2013年）であり、PayPayがリリースされたのは2018年10月5日ですが、もしも私が過去に戻って、日本向けのtoCサービスで決済導線を作り直せるならば、最初からこうしたほうが良かったなと思います。
- クレジットカード、Apple Pay、PayPay は PAY.JP に寄せる
- 配送先があるなら Amazon Payはマスト
- 配送先がないなら PayPayはマスト
何が変わったのか
導入前は、クレジットカードまたはApple Payで支払う導線しかありませんでした。
導入後は、最初の選択肢を以下のようにしました。
- Apple Payで進む
- Amazon Pay で進む
- 住所を入力して進む
Apple PayとAmazon Pay の場合、ユーザーはAmazonアカウントにある配送先と支払い方法を使えます。こちらのフォームで住所を入力してもらう必要がありません。
一方で、PayPayとクレジットカードは「住所を入力して進む」の中に置きました。
PayPayは支払いとしては強いですが、配送先を持っていません。
配送先が必要なECでは、PayPayを入れても住所入力は残ります。
Amazon Pay は支払い手段というより、住所入力と支払い入力をまとめて消す導線でした。
Amazon Pay が強かった理由
Amazon Pay が強かった理由は「Amazonで払えるから」だけではありません。
もちろん日本ではAmazonアカウントを持っている人が多いですが、決済ページで特に効いたのは、配送先をAmazonから取れることです。
配送先フォームは、開発者が思っているよりもかなり面倒です。
- 郵便番号
- 都道府県
- 住所
- 建物名
- 氏名
- 電話番号
- メールアドレス
これをスマホで入力するのは手間です。
しかも入力ミスがあります。
番地が抜ける、建物名が抜ける、電話番号の桁が合わない、郵便番号から住所補完しても残りを入れ忘れる、みたいなことが起きます。
Amazon Pay はここをまとめて飛ばせます。
なので、配送がある導線では Amazon Pay の優先度を最重要にすべきです。
単なるウォレット決済としてではなく、住所入力を丸ごと省略できる仕組みとして捉えるべきです。
PayPayも悪くない
今回の決済手段の導入にあたり、配送先の入力をスキップできないPayPayの利用率(7%)は、Amazon Payと比べると小さく見えます。
ただし、日本のコード決済のPayPayのシェアは大きく、配送先がない導線であればさらに話は変わります。
デジタル商品やサブスクの初回決済、資料請求後の課金、アプリ内のWeb決済のように、住所が不要な導線ではPayPayのほうが効果が出やすいはずです。
ユーザーが「PayPayで払う」を見て迷うことはありません。
PAY.JP に寄せると実装が楽
PAY.JP はクレジットカード、Apple Pay、PayPayをサポートしています。カード決済は従来のPAY.JPトークン、Apple PayはPAY.JPのApple Pay、PayPayはCheckout v2で外部リンク型決済にしました。
これは正直かなり楽です。
また、決済サービスを増やすと、管理画面、返金、入金、エラー調査、サポート対応が分散しますが、それらが一元化されるのも重要です。
ただし、Amazon Payだけは別で、セラーセントラルに登録し、そちらで管理する必要があります。
ですので、PAY.JPをベースに決済システムを構築する場合は、管理を一元化できないリスクを取ってでも物販の住所入力スキップのベネフィットが上回る場合にのみ、Amazon Payを検討すべきでしょう。
実装の注意点
外部決済で一番重要なのは、ユーザーがブラウザに戻ってくることを前提にしないことです。
PayPay も Amazon Pay も、支払いの途中で外部画面へ移動します。
ユーザーが決済後にタブを閉じることもありますし、リダイレクトだけ失敗することもあります。
そのため今回の実装では、支払い開始時点で payment_attempts という注文台帳を DB に作るようにしました。
ここには、ユーザー、決済方法、金額、購入 payload、商品情報、reference_id、Checkout Session、Payment Flow、receipt、現在のステータスなど、取れる途中結果をできるだけ保存しています。
つまり、支払い処理を「ブラウザが戻ってきたら注文を作る」ではなく、「最初に注文台帳を作り、決済会社から返ってくる結果で台帳を更新し、確定できたものだけ注文として反映する」形にしています。
また、PayPay は PAY.JP Checkout v2 を使っています。
PayPay の場合、支払い完了は PAY.JP Webhook でも受け取れるので、ユーザーがブラウザに戻らなくても支払い成功を拾えます。
Webhook で受け取った Payment Flow の結果を注文台帳に保存し、成功していれば決済を完了にします。
これで PayPay は、支払い成功後にユーザーが戻らなかった場合でも、配送し忘れを防ぎやすくなっています。
決済会社側では支払いが動いているのに、自社側には何も残っていない、という状態が一番危険です。
なので、外部決済を入れるなら、ボタンやリダイレクトURLだけではなく、最初から注文台帳、Webhook、再照会、二重処理防止までセットで考えたほうがいいです。
まとめ
日本でECや申し込み導線なら、決済は最初からこう考えたほうがいいです。
- 配送先があるならAmazon Payを優先して入れる
- 配送先がないならPayPayを優先して入れる
- クレジットカード/Apple Pay/PayPayはPAY.JPに寄せる
- Amazon Payは別実装として割り切る
- 外部決済は二重処理、未処理、リダイレクト失敗を前提に作る
- PayPayはWebhookまたはサーバー側再照会で完了確定する
- クレジットカード/Apple Payは消さない
決済はプロダクトの本質的価値ではありませんが、そこで止まったユーザーには、本質的価値は届きません。
日本でtoCの購入導線を作るなら、Amazon PayとPayPayは、趣味の機能ではなく、決済導線の基礎工事として見たほうがいいです。
Discussion