決済の追加には、支払い画面だけでなく、プロダクトそのものに関わる判断が伴います。お客様が何を購入するのか、アプリがいつそれを提供するのか、支払いが遅れたり、失敗したり、返金されたりしたらどうなるのかを把握する必要があります。
決済についてのわかりやすいブリーフがあれば、連携とテストの範囲を決めやすくなります。また、決済事業者とプラットフォームが、予定しているビジネスモデルに対応しているかを確認する助けにもなります。
何を売り、誰がお金を受け取るのかを説明する
まず、商品やサービス、売り手、買い手について書いてください。自社から一度だけ買ってもらう場合と、サブスクリプション、あるいはほかの売り手が代金を受け取るマーケットプレイスとでは、仕組みが違います。決済事業者を選ぶ前に、どのモデルが必要なのかを説明してください。
お客様が買うものと、価格の決まり方。
支払いが一回きりか、継続課金か、前金か、それ以外の形か。
支払いを受け取る事業者と、決済事業者のアカウントの所有者。
プロダクトが対応すべきお客様の国、通貨、支払い方法。
マーケットプレイスなど、第三者にお金を支払う仕組みの場合は、決済事業者がそのモデルに対応しているか、アカウント登録や送金の要件はどうかを確認してください。意味のある実装の見積もりを出すには、決済の流れが決まっている必要があります。
決済事業者とプラットフォームの利用条件を確認する
決済事業者が、御社の所在地、商品の種類、販売したい市場に対応しているかを確認してください。アカウントの審査、使える支払い方法、入金の条件は、その事業者に確認する必要があります。技術的に連携できるからといって、御社が利用を認められるとは限りません。
モバイルアプリや Telegram の中で購入が行われる場合は、プロダクトと配信経路に適用されるプラットフォームの要件を確認してください。Apple の審査ガイドラインやTelegram のデジタル商品の支払いに関するガイダンスは、購入画面の設計に影響しうるルールの例です。流れを確定する前に、実際のプロダクトに当てはまる最新の要件を確認してください。
支払いの状態とプロダクトへのアクセスを対応させる
重要な状態ごとに、その後どうなるかを書き出してください。会員制のプロダクトなら、初回の支払いが確定したらアクセスを有効にする、という形が考えられます。解約しても、支払い済みの期間が終わるまではアクセスを残すこともできます。具体的な動作はビジネス上の判断であり、アプリケーションはそれを一貫して実装する必要があります。
決済システムは、お客様がサイトに戻ってくるかどうかとは別に、アプリケーションに通知を送ることができます。こうした通知は一般に Webhook と呼ばれ、更新の成功や支払いの失敗といったイベントにバックエンドが対応できるようにします。Stripe のサブスクリプションイベントに関するドキュメントには、そうしたイベントの例が載っています。ほかの事業者には、それぞれ独自のイベントの仕組みがあります。
同じ通知が繰り返し届いたとき、処理が中断されたとき、確定が遅れたときに、システムがどう対応するかを決めておきましょう。お客様もスタッフも正しい状態を確認でき、誤って二重に購入されたり、間違ったアクセス権が付与されたりしないようにする必要があります。
解約、返金、サポートを決める
お客様が自分でできる操作と、スタッフの確認が必要な操作を教えてください。返金や解約が承認された後、プロダクト上の記録とアクセス権をどうするかを決めておきましょう。管理画面を作る前に、ビジネスルールを書き残しておいてください。
支払いに関する問い合わせに誰が対応するのか、取引ごとの決済事業者の参照番号をスタッフがどこで確認できるのかも決めておきましょう。アプリケーションは、必要以上に支払い情報を見せることなく、調査に十分な情報をスタッフに提供すべきです。お客様向けのポリシーや関係する義務については、担当する方と確認してください。
お客様とスタッフの体験をテストに含める
本番の支払いを処理する前に、決済事業者が用意しているテスト環境とシナリオを使ってください。よいテスト計画は、購入そのものと、それがプロダクトに与える影響、スタッフの操作までをカバーします。
支払いの成功、失敗、お客様が購入手続きを途中でやめた場合。
確定待ちの支払いや、お客様の追加の操作が必要な支払い。
同じ通知が二回以上届く場合。
該当する場合の、更新、解約、返金。
支払いの確定から、注文やアクセス権の更新までのあいだで処理が中断された場合。
決済事業者が対応している購入方法を選び、アプリケーションが扱う必要のある支払い情報を決めてください。支払いデータに関する責任の所在は、実装の前に明確にしておくべきです。テストモードで問題なく動いたのはよい兆候ですが、本番のすべての取引がうまくいく保証にはなりません。
決済手数料と継続的な作業も考慮する
開発費は、合意した連携の作業をカバーするものです。処理手数料などの費用は、選んだサービスとアカウントによって決まります。メール配信や監視など関連するサービスも含めて、プラットフォームのほかの運用コストとあわせて確認してください。
販売するもの：…
売り手と、決済アカウントの所有者：…
必要な国、通貨、支払い方法：…
支払いによってアクセスを付与または変更するタイミング：…
解約と返金の扱い：…
承認とサポートを担当する人：…
こうした決定事項はプロジェクトのブリーフとあわせて送ってください。まだ答えの出ていない点を洗い出し、購入の流れ全体を踏まえて連携を計画します。