WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
What’s new in Apple Pay

What’s new in Apple Pay

MetalGPUMetalFXシェーダーvisionOS
元の動画を見る

Highlight

Apple Pay ボタンが今年からダイナミックになります。SwiftUI / UIKit アプリで該当ユーザーには、デフォルトのクレジットカードのカードフェイスがそのまま表示されるようになります。ただし、決済リクエストに Merchant Category Code とサポートする決済ネットワークを指定していることが前提です。

主要内容

この 10 年間、Apple Pay は「ユーザーがいかに速く決済できるか」という課題に取り組んできました。一方で、加盟店側の体験は長らく大きな変化がありませんでした。ボタンは黒一色、事前承認決済（preauthorised payments）は決済ネットワークから渡されるデフォルトの加盟店名しか表示できず、注文追跡は Apple Pay のフローに乗せるか、メール添付に頼るか、あるいは「Wallet に追加」ボタンを置くだけ。結果としてユーザーは決済しても加盟店を識別しづらく、開発者もブランド情報を Wallet 側まで広げる手段がありませんでした。

今年の WWDC では、この 3 点をまとめて補完してきました。Apple Pay ボタンはダイナミックボタンに変わり、ユーザーがこれから使うクレジットカードのカードフェイスを表示するようになります。事前承認決済の画面は統一的に作り直され、加盟店側でカスタムの logo・名称・説明・画像を提供できるようになりました。注文追跡は Apple Intelligence と連携し、Wallet が Mail から注文メールを自動で識別して Wallet 注文を生成できます。さらに FinanceKit には新しい background delivery extension が追加され、金融系アプリは起動していない状態でもデータを更新できるようになりました。これは家計簿、消費分析、widget のリアルタイム更新といった機能を作る開発者にとって、かなり重要な能力です。

詳細

ダイナミック Apple Pay ボタン（01:11）の核となる仕組みは、ボタン自身が「今回の取引に最も適したカード」を選び出すことです。ボタンに対象カードの判定材料を渡すには、PKPaymentRequest に merchantCategoryCode を設定する必要があります。

let paymentRequest = PKPaymentRequest()
paymentRequest.supportedNetworks = [.visa, .masterCard]
paymentRequest.merchantCapabilities = [.threeDSecure]
paymentRequest.merchantCategoryCode = PKMerchantCategoryCode(rawValue: 5995) // Pet Shops, Pet Food and Supplies

// PKPaymentRequest を受け取るイニシャライザを使うと、ボタンはこれらのフィールドに基づいてカードを選択する
PayWithApplePayButton(paymentRequest: paymentRequest) {
    // handle payment
}

ポイントは次の通りです。

  • supportedNetworks で利用可能な決済ネットワークを指定します。配列に含まれないカードは利用不可として扱われます。
  • merchantCapabilities でサポートする暗号化プロトコルとカード種別を指定します。
  • merchantCategoryCode は業界標準コード（例：5995 はペット用品）で、ユーザーが事前にどのカードが使えるかを把握できるため、決済失敗を回避できます。
  • PKPaymentRequest を受け取るイニシャライザを使う必要があります。これを使わないと従来のボタン外観にフォールバックしてしまい、上記フィールドに基づくカード選択は行われません。

新しいカードフェイス表示が不要な場合（ブランドガイドラインで黒一色のボタンを強制したいケースなど）は、view modifier で無効化できます（03:25）。

VStack {
    PayWithApplePayButton(.buy) {
        // handle payment
    }
}
.payWithApplePayButtonDisableCardArt()

ポイントは次の通りです。

  • payWithApplePayButtonDisableCardArt は従来のボタン外観を強制します。
  • この modifier は view hierarchy 全体に作用するため、複数のボタン、あるいはアプリ全体に一括適用できます。
  • SwiftUI と UIKit のアプリは追加の実装なしで新しいボタンが手に入ります。

事前承認決済（03:55）まわりの変更はさらに大きいです。Wallet には統一された preauthorised payments ビューが追加され、サブスクリプションや定期支払いをまとめて表示し、引き落とし直前の通知も送信できるようになりました。加盟店側で自社の logo・名称・支払い詳細を表示させたい場合は、Merchant Token API を実装する必要があります。サーバ側で bundle-vending endpoint を提供し、zip パッケージ（usage information JSON、加盟店 logo、商品画像、必要に応じてローカライズファイルを含む）を返却します。パッケージ全体は HPKE（auth mode）でユーザー端末まで end-to-end 暗号化され、1 パッケージあたりの上限は 5MB です。schema の主なフィールドは merchantTokenIdentifier、merchantName、merchantLogoName、upcomingPayments、pastPayments です。

注文の自動追跡（10:19）は、Apple Intelligence をオンデバイスで使い、Mail の注文メールを認識して自動的に Wallet 注文に変換する仕組みです。認識精度を上げるには、メール本文に加盟店名を含めること、各メールに注文番号を含めること、配送関連メールと紐付けるための tracking number を含めること、が大事です。加盟店は Apple Business Connect でメールアドレスと logo を登録しておくことで、認識された注文にブランド情報を付与できます。より高度な機能（メールがない注文更新、レシート連携、返品フロー）が必要な場合は、従来通り order bundle を使うか、決済リクエストに webServiceURL を設定する方式が引き続き利用できます。

FinanceKit の background delivery extension（13:56）は、今回追加された開発者向け機能の中で最も実用的なものです。新しい extension タイプは 2 つのエンドポイントを実装します。didReceiveData は [BackgroundDataType]（値は accounts、accountBalances、transactions）を受け取り、どのデータが変わったかを通知します。willTerminate は実行時間ウィンドウの終了時に呼ばれ、進行中の処理を保存する機会を与えてくれます。アプリ側では FinanceStore に対して興味のあるデータタイプと更新頻度（hourly / daily / weekly）を宣言するだけで OK です。引き落としが発生したときシステムが自動で extension を起動してくれるので、アプリが起動していない状態でも widget の更新や日次の消費レポート生成が可能になります。FinanceKit は今年イギリスにも展開され（12:55）、Open Banking Standard 経由で Connected Cards にアクセスできるようになりました。

重要ポイント

  • やること: 既存の Apple Pay 連携に Merchant Category Code と supportedNetworks を追加する。

    • 価値: ダイナミックボタンが有効化される前提条件です。コード変更はわずか数行ですが、決済失敗率を直接下げられます（ユーザーは決済前にどのカードが使えるか分かるため）。SwiftUI / UIKit アプリは追加コストなしで新しいボタン外観を手に入れられますが、このフィールドを埋めないと適用されません。
    • 始め方: PKPaymentRequest を生成しているすべての箇所を洗い出し、merchantCategoryCode を追加し、supportedNetworks と merchantCapabilities が揃っているかを確認します。ボタン初期化時には単純なコールバックではなく PKPaymentRequest を渡すように統一しましょう。

  • やること: サブスクリプション系のサービスで Merchant Token Usage Information bundle を実装する。

    • 価値: ユーザーが Wallet で目にするのは、決済ネットワークが返す不思議な加盟店名ではなく、自社の logo・カスタム名称・サブスクリプション詳細になります。これはブランド露出の新しい入り口で、SaaS、ストリーミング、フィットネスサブスクリプションなど、継続課金が必要なプロダクトに特に向いています。
    • 始め方: まずサーバ側で Merchant Public / Private key pair を生成し永続化します。次にドキュメントに沿って bundle-vending endpoint を実装し、サンプル zip（≤5MB、logo、JSON schema、商品画像入り）を組み立てて end-to-end 暗号化フローを通しで動かします。

  • やること: 家計簿・消費系アプリを FinanceKit background delivery extension に移行する。

    • 価値: widget がメインアプリの起動に依存せずデータを更新できるようになり、ユーザーが買い物をした直後やカード明細が反映された直後に最新の残高が見えるようになります。リテンションと「リアルタイム感」の体験差は大きく開きます。
    • 始め方: background delivery extension の target を新規追加し、didReceiveData と willTerminate を実装します。データストレージを app group に移行し、メインアプリ側で FinanceStore に対して関心のあるデータタイプと頻度（hourly / daily / weekly）を登録します。テストでは実際のトランザクションをトリガーに、アプリが終了していても widget が更新されることを確認しましょう。

  • やること: 注文確認メールのテンプレートを Wallet 自動追跡に対応した形式に作り直す。

    • 価値: ユーザーは何もしなくても Wallet 上で注文情報や配送状況を確認できるようになります。カスタマーサポートの問い合わせは減り、配送見逃しの可能性も下がります。Apple Business Connect に登録すればブランド logo も表示できます。
    • 始め方: 既存の注文確認メールテンプレートを監査し、本文に加盟店名と注文番号があることを確認します。配送メールには同じ tracking number を含めます。Apple Business Connect で業務用メールアドレスと logo を登録し、テスト用アカウントにテストメールを送って Wallet が各フィールドを正しく識別できるか検証します。

関連セッション

  • Dive into App Store server APIs for In-App Purchase — App Store Server API とサーバ通知の最新アップデート。サブスクリプションビジネスのサーバ側で必修の内容です。
  • Discover Apple-Hosted Background Assets — Apple ホスト型のリソースを使ってバックグラウンドでサイレントにアップデートする仕組み。FinanceKit background delivery と発想が共通しています。
  • Enhance child safety with PermissionKit — PermissionKit による子ども向けコミュニケーション安全機能。同じく App Services 系の新しいフレームワークです。
  • Dive deeper into Writing Tools — Writing Tools の深い統合。Apple Intelligence をシステムレベルの体験に組み込むもう一つの実例です。

コメント

GitHub Issues · utterances