📲
Amazon Pay決済をNativeアプリに導入する場合の一例
2023年初旬にお仕事で携わっているアプリケーションにAmazon Pay決済を導入しました。
Webへの導入はそれほど苦労しませんでしたが、モバイルアプリへの導入については情報の整理が必要だったので、その記録を残します。
前提
- モバイルアプリのカート画面(Amazon Payのボタンを設置する画面)はNativeである
- カートより先の画面(注文内容の最終確認画面、注文完了画面など)はWebViewである
- 筆者はサーバーサイドエンジニアである(ので、モバイルの挙動に関する記載は曖昧)
ドキュメント
- カートページや商品ページに 「Amazon Payボタン」の画像 を配置します。
- この画像をタップした時、「自動的にAmazonログイン画面に遷移させるページ」(android、iosにて後述) をSecure WebViewで表示します。
- この時、②でリダイレクトされる、Nativeコードを起動するURL(iOS: Universal Links, Android: Applinks) を設定します。
- ②のリダイレクト時のURLに「amazonCheckoutSessionId」が渡されます。
- Nativeコードが起動するので、URLに含まれる「amazonCheckoutSessionId」を取得します
- Server側で「amazonCheckoutSessionId」をパラメタにAmazon Pay APIを呼び出し、購入者の氏名・住所情報を取得して購入ページに反映して表示します。
- 購入ボタンクリック時に下記の処理を行います。
- Server側でAmazon Pay APIを呼び出し、金額などの決済に必要な情報と、④のリダイレクト先の Nativeコードを起動する「中継用のページ」(android、iosにて後述) のURLを設定します。
- このAPIの戻り値の中に③の「支払い処理ページ」へのURLが含まれているので、Secure WebViewで表示します。
- Amazon側の画面にて与信などの決済処理が完了すると自動的に④のリダイレクトが発生します。
- 中継用ページによりNativeコードが起動します。
- Server側で「amazonCheckoutSessionId」をパラメタにAmazon Pay APIを呼び出してAmazon Payの支払いSessionを完了させて、Thanksページを表示します。
シーケンス図
全体のフローを次の2つに分けてそれぞれ図示します:
- カート〜注文直前の最終確認画面
- 注文直前の最終確認画面〜注文完了画面
カート〜注文直前の最終確認画面
ドキュメントにおける 1. と 2. の部分です。
- カートページや商品ページに 「Amazon Payボタン」の画像 を配置します。
- この画像をタップした時、「自動的にAmazonログイン画面に遷移させるページ」(android、iosにて後述) をSecure WebViewで表示します。
- この時、②でリダイレクトされる、Nativeコードを起動するURL(iOS: Universal Links, Android: Applinks) を設定します。
- ②のリダイレクト時のURLに「amazonCheckoutSessionId」が渡されます。
- Nativeコードが起動するので、URLに含まれる「amazonCheckoutSessionId」を取得します
- Server側で「amazonCheckoutSessionId」をパラメタにAmazon Pay APIを呼び出し、購入者の氏名・住所情報を取得して購入ページに反映して表示します。
これを図にするとこうなります。
注:
-
url_1
= 「自動的にAmazonログイン画面に遷移させるページ」のURL -
url_2
= 「Amazon画面での処理(ログインおよび届け先・支払い方法の選択)が完了した旨を表示するページ」のURL -
url_3
= 「Amazonの届け先・支払い方法選択画面」にある「キャンセル」リンクを押した際に開く画面のURL -
url_4
= 注文完了するための中継用ページのURL- 後述する「注文内容の最終確認画面〜注文完了画面」の図でも登場します
-
url_5
= Nativeコードを起動するURL(iOS: Universal Links, Android: Applinks)- このURLは
url_2
の画面内に表示されます
- このURLは
-
url_6
= 「注文直前の最終確認画面」のURL
注文直前の最終確認画面〜注文完了画面
ドキュメントにおける 3. と 4. の部分です。
- 購入ボタンクリック時に下記の処理を行います。
- Server側でAmazon Pay APIを呼び出し、金額などの決済に必要な情報と、④のリダイレクト先の Nativeコードを起動する「中継用のページ」(android、iosにて後述) のURLを設定します。
- このAPIの戻り値の中に③の「支払い処理ページ」へのURLが含まれているので、Secure WebViewで表示します。
- Amazon側の画面にて与信などの決済処理が完了すると自動的に④のリダイレクトが発生します。
- 中継用ページによりNativeコードが起動します。
- Server側で「amazonCheckoutSessionId」をパラメタにAmazon Pay APIを呼び出してAmazon Payの支払いSessionを完了させて、Thanksページを表示します。
注:
-
url_7
= Checkout Sessionを更新して確定させる(今後更新できなくする)ためのURL -
url_8
= 注文データをつくるためのURL -
url_9
= 注文完了画面のURL
ふりかえり
- 自前のサービスへのログインセッションは WebView で、Amazonアカウントへのログインは Secure WebView で行なうので、いろいろと行ったり来たりを繰り返していて複雑
- url_2 と url_4 の中継的なページは、動作環境によってはよりシームレスな挙動を実現できるはずだけどまだやってない
-
Universal Linksの基本的な発動条件は「Safari/SFSafariView等でLinkをタップする」ことですが、iOSのバージョンやその他の条件によっては、ServerからのRedirectでも発動することがあります。
- https://github.com/amazonpay-labs/amazonpay-sample-app-v2/blob/master/ios/README.md#universal-linksについて-1
- 動作を統一させたかったので、明示的にタップさせる仕様にしている
-
- よりセキュアになるようにサーバーサイドでそのほか色々実装をしてたりするけど、今回の図には記載していない
- モバイルアプリの挙動を正確に図示できてなさそう
- WebView, Secure WebViewの起動をどこが司るのか理解できていないんだと思う
- 特に2つ目の図の⑤⑥あたり、WebViewでのリダイレクトを無理やりSecure Webviewに移すみたいなことを実際やってるという話なんだけど、それを実現する "リクエストハンドラー" みたいな概念を入れる必要があるんじゃないか
以上、記録でした。
Discussion