Apple Payと注文管理の実装

こんにちは Katieです 今日のセッションでは Apple Payの実装と 注文のトラッキングについてお話します 本日のアジェンダですが まず Apple Payを始めるために必要な 基本事項を説明します 次に 支払いリクエストを 作成する方法や 支払いシート内で変更に 対応する方法を紹介します また 支払いフローの最後に 注文の詳細を追加することで ユーザーが注文をトラッキング できるようになりました 注文の詳細により 注文したパッケージを ウォレットで取得することもできます その構築方法は追って紹介します 最後に 注文を更新する方法を説明します では 始めましょう Apple Payはプライバシーを守りながら 簡単かつ安全に行える決済方法です WebサイトやAppのデベロッパは Apple Payを使用して コンバージョンやユーザー体験を 向上させることができます 始めるにあたって 2つの重要な アイテムを作成する必要があります 1つ目は 支払いを 受け付ける販売者として デベロッパを識別する一意のIDです IDを作成するには Appleデベロッパポータルの IDセクションにアクセスしてください 従来のフォーマットは逆DNS形式で merchantという語から始まります マーチャントIDを作成したら そのIDで ペイメントプロセッシング証明書 を作成してください 簡単に言うと Apple Payでは 各ペイロードが 登録されたマーチャントIDと公開証明書で 暗号化されます このペイロードは デベロッパ側で 復号し処理することができます その後 支払いが成功したか 失敗したかを返すことができます 支払い処理の詳細については ご利用のペイメントサービス プロバイダにお問い合わせください Apple Payの設定方法は AppとWebサイトで手順が異なります App向けにApple Payを設定するには Xcodeの「Signing & Capabilities」 タブを開き Apple Pay機能の下に マーチャントIDを追加するだけです Webサイトを構築していて そこにApple Payを設定したい場合は いくつかの追加手順が必要です Apple Payのトランザクションを処理する ドメインを登録する必要があります これはAppleデベロッパポータルの IDセクションで行うことができます また このセクションでは 先ほど作成した マーチャントIDに紐付けられる Apple PayマーチャントID証明書 を作成できます この証明書は Apple Payサーバへの セッションを認証するために 使用されます Appに統合する場合も Web上で統合する場合も eコマースプラットフォームや ペイメントサービスプロバイダを すでに利用している場合は 手順の一部を簡素化できる可能性があるため 個々のサービスの具体的な手順を 確認してください それでは 実際にApple Payを 実装する方法を見ましょう Apple Pay関連のコンテンツを 表示する前に ユーザーが現在の設定で 支払いを行えるかどうか を確認する必要があります 3Dセキュアやクレジットカード デビットカードなど シートが受け入れることができる 支払い方法の種類を 後ほど支払いリクエストを 設定する際に指定します ユーザー側でどのネットワークが 使用可能かを確認します なお 現在使用可能なカードがない場合 ユーザーはカードを追加できます ユーザーが支払いを 行えることを確認したら Apple Payボタンを表示します ユーザーが実行する必要がある アクションに合わせて 最適なコールトゥアクションと ボタンのタイプを選択してください Apple Payボタンは スクロールしなくても 見えるところに 目立つ形で 最初の支払いオプションとして表示します Apple Payボタンは完全に ローカライズされており ユーザーの設定に合わせて 調整することもできます UIKitを使用してAppに Apple Payボタンを表示するには まず PKPaymentButtonを作成し ボタンのタイプとスタイルを指定します タイプは「Apple Payで寄付する」や 「Apple Payで続ける」といった 支払いの種類を示します スタイルは 明るいか暗いかなど ボタンの外観を制御します 自動スタイルを使用すると ユーザーの設定に合わせて ボタンが動的に変更されます Webの場合は JavaScriptの Apple Payボタンを使用します Apple Payボタンを追加するには まず コンテンツ配信ネットワーク上の Webページにボタンスクリプト を読み込みます JavaScriptのApple Payボタンでは タイプやスタイル ローカリゼーションを 指定することもできます また CSSを使用して ボタンのサイズを さらにカスタマイズすることもできます 支払いシートに購入が 反映されるように 支払いリクエストを作成 する必要があります そのために Appの場合は PKPaymentRequestを作成します Appのニーズに応じて 支払いリクエストに設定できる フィールドは多数ありますが 先ほど作成したマーチャントIDや 受け入れる支払い方法 支払いの国コードと通貨コードは必須です 支払いを受け入れる ネットワークを指定してください 共同バッチ処理したカードに対して 希望するネットワークをApple Payが 選択できるよう 優先順位の高い順に ネットワークを指定する必要があります 最後に トランザクションの一部として 概要項目が用意されています 概要項目について 詳しく見てみましょう ここでは ペット用品の オンラインショップを運営していて Apple Payによる決済機能の 実装を検討していると想定します 概要項目は ユーザーが選択した商品の 合計金額から割引額を 差し引いたもので構成されます これは ユーザーがコストの内訳を 把握するのに役立ちます 概要項目の最後は必ず合計で この合計のラベルは 支払いを受ける会社でなければなりません この配列には 少なくとも1つの項目が 設定されている必要があります これで 支払いシートを 表示する準備が整いました まず PKPayment AuthorizationViewControllerを作成し 先ほど設定したリクエストを送信します 返されたViewControllerの表示は デベロッパが管理します では 今回設定する デリゲートを見てみましょう PKPaymentAuthorization ViewControllerDelegateは ユーザーが新しい メールアドレスを選択したときや トランザクションを承認したときなどに 支払いシートが変更を デベロッパに通知する方法です デベロッパは自分に関係する適切な変更に 対応すればよいのですが とはいえ 支払いシートを却下する責任は 常にデベロッパにあるため これを処理するために paymentAuthorizationViewController DidFinishを実装する必要があります 問題を解決するのに役立つ説明を添えて できるだけ早くユーザーに エラーを返すようにしてください たとえば ユーザーの 新しい配送先住所に問題がある場合は PKPaymentRequest ShippingContactUpdateの一部として エラーを返す必要があります didAuthorizePaymentは ユーザーが注文の詳細に満足し Face IDやTouch ID またはパスコードを使用して トランザクションを続行すると 呼び出されます 送信されたPKPaymentは デベロッパが自分で処理するか 支払い処理業者に渡す必要があります デベロッパは適切な結果で ハンドラを呼び出す必要があります iOS 16では SwiftUIでApple Payボタンを 簡単に作成できる機能が導入されました Apple Payでの支払いボタンの作成時に 支払いリクエストを渡すだけで ユーザーがボタンを操作すると 支払いシートが自動的に 表示されるようになります ボタンのタイプに加え 任意でスタイルも設定できます 支払い承認の変更は 前のスライドで見たデリゲートに似ています ここで ユーザーによる更新に 対応する方法を説明します ユーザーが支払いを承認すると 支払い承認フェーズの変更により Appに通知されます Appは支払い情報をサーバに送信し 支払いを処理するよう依頼します サーバの結果が成功を 示しているかどうかを確認し サーバからエラーが返されたら それを処理し 引き続き適切なエラーで 結果ハンドラを呼び出すようにします サーバの結果が成功を示している場合は 適切な承認結果で 支払いを完了してください 返す結果には 支払いの処理時に 発生したことを含める必要があります たとえば 住所が無効であるなどです ほとんどの場合 支払いは成功 または失敗のいずれかになります 支払いが失敗した場合は 重要度順に 1つまたは複数のエラーを 返すこともできます これはユーザーに表示されるので ユーザーはトランザクションを 再度試みることができます 承認結果には 注文の詳細を 含めることもできます これについては後ほど説明します では Webでこれを行う 方法を見てみましょう W3C Payment Request APIは Web上で支払いを処理できるよう にするオープンスタンダードです デベロッパは PaymentRequestオブジェクトを作成して Apple Pay が利用できる ことを明記する方法 合計金額や配送方法など トランザクションに関する情報を含む詳細 ユーザーに提供してもらう 情報を指定するオプションを 設定できます サーバ上でマーチャントの検証を 完了する必要があるため 新しいマーチャントセッションを作成し それをcomplete関数に渡します ネイティブと同様 ユーザーが支払いシートで 行う操作に応答できます また ユーザー認証時に 支払い応答を処理する必要があります これでApple Payと統合されたので 実際に注文を作成できます iOS 16では 注文のトラッキング 機能が導入されました 注文の詳細や追跡情報をすべて ウォレットApp内で確認 できるようになりました ユーザーは注文した商品を いつ受け取れるのか 配達済みか 問題が発生したかどうか 通知が届いているかといったことを 即座に知ることができます ここまでで ペット用品の オンラインショップと Apple Payを連携 させることができたので 今度は注文のトラッキング 機能を追加してみましょう 方法を説明します 注文の設定方法は Apple Payの設定と似ています デベロッパポータルの IDセクションに戻り 注文タイプIDを作成します これにより あなたの組織が 注文情報を提供する エンティティとして識別されます マーチャントIDと同様 逆DNS形式の命名法を 使用することをお勧めします ただし 注文タイプIDには先頭に orderという語をつけます 次に デベロッパポータルの 証明書のセクションで 注文タイプID証明書を作成します 証明書を使用して 注文パッケージを作成し 注文を更新し 通知を送信します 設定できたら Apple Payの購入フローから 直接ウォレットに注文を追加できます これを行うにあたって 先ほどの簡単な支払い処理フローを 振り返ってみましょう サーバに支払い情報が送信されて 処理されます 支払いが正常に処理されると サーバは注文を作成します 返す結果で注文のトラッキング 機能をサポートするには 作成した注文に関する詳細も 含める必要があります 注文の詳細情報により デバイスはサーバから注文を 非同期にリクエストできます サーバは注文パッケージを デバイスに送信し それがウォレットに表示されます ここで PKPayment承認結果の 一部として返す必要がある 注文の詳細を詳しく見てみましょう 注文の詳細は4つのフィールド で構成されています 注文タイプIDは 先ほど作成したものです そして 注文を識別する注文IDを 生成しなければなりません これは注文タイプIDの範囲内で 一意である必要があります WebサービスのURLを含めます 最後に サーバは安全な認証トークンを 生成する必要があります これは ユーザーのデバイスとサーバ間の 共有シークレットです 注文パッケージをリクエストする際に デバイスはこのトークンを 使用して自身を認証します この例は 先ほど見た 通常の支払い承認フローと 非常によく似ています では 注文の詳細を追加しましょう まず serverResultから それらを取得し PKPaymentOrderDetails オブジェクトを作成し 注文タイプIDや注文ID WebサービスのURLや 認証トークンを設定します PKPayment承認結果に これを割り当てます Web上で W3C Payment Request APIを使用して 注文の詳細を簡単に 追加することもできます 先ほどと同様 サーバの結果から 注文の詳細を抽出します その注文の詳細と 支払いを完了するための データを返してください 注文の詳細がデバイスに返されると それらの詳細は ユーザーの各デバイス間で同期されます 各デバイスは サーバから 注文パッケージをリクエストし 注文の詳細を提供します 注文の詳細で送信した 認証トークンと照合して 認証トークンを確認します 認証トークンが一致する場合は 注文パッケージをデバイスに返します これで デバイスのウォレットに注文を 表示する準備が整いました デバイスがリクエストしたら すぐ提供できるように できるだけ早く注文の修復 を試みる必要があります サーバが注文を返せなかった場合 デバイスは指数バックオフで 複数回再試行します この注文パッケージは ここまで何度も出てきましたが 実際 どのような構成 になっているのでしょうか 注文は注文パッケージとして配信されます 注文パッケージには 注文をユーザーに表示し それがデベロッパからのものであることを 証明するのに必要なすべてが含まれています 注文パッケージには 注文を説明する JSON辞書 ロゴなどの画像 注文の各アイテムの インライン画像が含まれます 画像の作成に関するガイダンスは 「Human Interface Guidelines」や リファラルソースを参照してください 注文パッケージには文字列ファイルなどの ローカライズされたリソースも含まれます 注文の合計サイズに注意し 関連するものだけを含めてください これらのコンテンツはすべて マニフェストという別のJSON辞書に 記述されています これは目次のようなものです 注文パッケージ内のすべての ファイルへの参照が含まれています エントリのキーはファイルの相対パスで 値はファイルの SHA256チェックサムです これは解析で使用されるものとは 異なるチェックサムです 次に 真正性を証明するために パッケージに署名する必要があります 署名は注文パッケージが信頼できるソース つまりデベロッパからのものであることを 証明します これは解析と同様 マニフェストのデタッチされた 暗号化メッセージ署名です 注文タイプID証明書に 関連付けられた秘密鍵と Apple Worldwide Developer Relations中間証明書を使用して マニフェストに署名し 更新されたバージョンの証明書 を使用します 注文の作成を完了するには パッケージを圧縮し ファイルの拡張子を orderに変更するだけです では 注文を更新する方法を説明します 注文情報は時間の経過とともに 変化することがよくあります たとえば ユーザーが少し前に 注文したペット用品が ようやく発送されるかもしれません 自動更新機能に対応していれば こういった更新をユーザーに 迅速かつ安全に配信できます ユーザーのペット用品の 注文はウォレットにあり 注文は更新機能に対応しているため ユーザーのデバイスはショップの Webサービスに登録されます 後日 ユーザーの注文が配達中になると サーバは登録情報を使用して すべての登録済みデバイスに通知します ユーザーのデバイスは プッシュ通知を受信すると サーバに注文をリクエストします サーバは更新された注文パッケージを デバイスに返します 基本的な注文フローがわかったところで 注文の更新に対応するための 具体的な手順を説明します まず 注文の更新に対応 していることを示します 注文が更新機能に対応していることを ウォレットに伝えるのはとても簡単で 注文パッケージに2つの 情報を含めるだけです まず order.jsonに webServiceURLを追加します これは 注文の詳細で 提供したのと同じものです そして authenticationToken フィールドも追加します このフィールドは ウォレットが 注文の更新をリクエストする際に その真正性を証明するために使用します 登録の追加や削除に関する デバイスからの要求について 管理が必要です サーバは登録情報の追加や削除に 対応できる必要があります 注文の更新に登録したデバイスを 検出できる必要があります これにより 注文の更新時に サーバがこれらのデバイスに 通知できるようになります また サーバは更新されたどの注文が 特定のデバイスに関連して いるかを認識できるように デバイスが登録されている注文を 検出できる必要があります この情報を構造化する方法は いくつかあります 1つの方法は デバイス用と注文用の 2つのエンティティを持ち 登録が多対多の関係で行われる リレーショナルデータベースを 使用することです 注文が更新されると サーバは登録済みのデバイスに 通知しなければなりません そのため サーバは保存されている 登録情報に基づいて 関連するデバイスを取得し プッシュトークンを使用して各デバイスに プッシュ通知を送信する必要があります 注文タイプIDは プッシュトピックとしても機能し ペイロードは空でなければなりません 注文タイプID証明書を使用して APNsと通信できます 通知に関するもう1つのポイントは 列挙型プロパティの changeNotificationsを 注文パッケージに設定して 注文の通知の配信方法を カスタマイズできることです 利用可能なオプションには 常に注文の更新通知を送信する enabledがあります これはデフォルト値です ウォレットに通知を複製 させたくない場合は disableIfAppInstalledを設定します これにより 注文パッケージに 記載されているAppを インストールしているユーザーには 通知が送信されなくなります 登録された各デバイスは サーバが 提供する新しい注文パッケージを リクエストします デバイスがプッシュ通知を 受信した時点では 空のプッシュ通知なので どの注文が変更されたかはまだわかりません デバイスはサーバと一緒に 前回のリクエスト以降に どの注文が変更されたかを確認します サーバに保存されている登録情報を使用して 関連する注文を見つけ そのIDを返します 更新時間をトラッキングし 応答に変更タグを含めることで 今後のリクエストで返される 注文IDの数を制限します たとえば タイムスタンプを使用できます 値はデバイスに対して不透明です デバイスは 次回の変更要求時に 変更タグを提供します 最後に デバイスはサーバが 更新したことを示す注文ごとに 最新のパッケージをリクエストします 今日は多くのことを取り上げました これらのプラクティスに従って 可能な限り最高のカスタマー エクスペリエンスを提供してください Apple Payを実装する場合は プロダクトページまたはカートページに Apple Payボタンを表示して エクスプレスチェックアウトを 提供しましょう ユーザーは支払いシートで 配送オプションと住所を 直接選択できるため 情報の入力を一切せずに 購入を完了できます 注文のトラッキング機能を実装する際は ユーザーの環境設定に 関する情報に基づいて 関連するローカリゼーションのみを 提供しましょう また 注文パッケージの サイズを小さくするため 含めるアセットの数に注意しましょう 注文を更新するときは 注文の更新を登録している デバイスにすぐに通知します ウォレットでの注文は 実際の注文の ステータスと一致させる必要があります 注文のトラッキングやApple Payボタン の表示については 「Human Interface Guidelines」 も参照してください 本日は 注文の作成と更新を通じて Apple Payの実装を開始する 方法について説明しました このセッションは Apple Payの実装と注文のトラッキング について紹介するものですが 詳しくはセッションメモにリンクされている ドキュメントを参照してください また 最新のWWDCの ビデオもご覧ください ご視聴どうもありがとうございました よい一日をお過ごしください