Appleは、企業が iPhoneのTap to Payを通じて非接触型決済を受け入れることを可能にします
22年後半には、米国の加盟店は、iPhone とパートナー対応の iOS アプリを使用するだけで、Apple Pay やその他の非接触型決済を受け入れることができるようになります。
Appleは、iPhone にTap to Payを導入する計画を発表しました。この新しい機能により、中小企業から大規模な小売業者まで、米国中の何百万もの加盟店が、iPhone をタップするだけで Apple Pay、非接触型クレジット カード、デビット カード、その他のデジタル ウォレットをシームレスかつ安全に受け入れることができるようになります。追加のハードウェアまたは支払い端末が必要です。iPhone のTap to Payは、支払いプラットフォームやアプリ開発者が iOS アプリに統合し、企業顧客に支払いオプションとして提供できるようになります。Stripe は、今春、Shopify POS アプリを含め、ビジネス顧客に iPhone でのTap to Payを提供する最初の決済プラットフォームとなります。追加の支払いプラットフォームとアプリは、今年後半に続きます。
「ますます多くの消費者がデジタル ウォレットやクレジット カードで支払いをタップするようになっているため、iPhone のTap to Payは、非接触型決済を受け入れるための安全でプライベートで簡単な方法を企業に提供し、パワー、セキュリティ、およびAppleのApple PayおよびApple Wallet 担当副社長、Jennifer Bailey は次のように述べています。「決済プラットフォーム、アプリ開発者、決済ネットワークと協力して、個人事業主から大規模小売業者まで、あらゆる規模の企業が非接触型決済をシームレスに受け入れ、ビジネスを成長させ続けることをこれまで以上に簡単にします。」
iPhone で Tap to Pay が利用可能になると、加盟店は iPhone XS 以降のデバイスでサポートされている iOS アプリを介して非接触型決済の受け入れを解除できるようになります。チェックアウト時に、マーチャントは顧客に iPhone または Apple Watch をかざして Apple Pay、非接触型クレジットカードまたはデビットカード、またはマーチャントの iPhone の近くにあるその他のデジタルウォレットで支払うよう促すだけで、支払いは NFC テクノロジーを使用して安全に完了します。iPhone の Tap to Pay を介して非接触型決済を受け入れるために追加のハードウェアは必要ないため、企業はビジネスを行う場所に関係なく支払いを受け入れることができます。Apple Pay はすでに米国の小売業者の 90% 以上で受け入れられており、この新しい機能により、大小を問わず事実上すべての企業が、顧客がチェックアウト時に iPhone でタップして支払うことができるようになります。
プライバシーは、Apple のすべての支払い機能の設計と開発における基本です。iPhone の Tap to Pay を使用すると、顧客の支払いデータは、Apple Pay を非公開かつ安全にするのと同じテクノロジーによって保護されます。iPhone で Tap to Pay を使用して行われたすべての取引は、Secure Element を使用して暗号化および処理されます。Apple Pay と同様に、Apple は何が購入されているのか、誰が購入しているのかを知りません。
Appleは、決済および商取引業界の主要な決済プラットフォームおよびアプリ開発者と緊密に連携して、米国内の何百万もの加盟店にiPhoneのTap to Payを提供します。Tap to Pay on iPhone は、決済プラットフォームやアプリ開発者が加盟店の顧客に提供する堅牢な決済および商取引ツールのスイートを補完および強化し、ビジネスの運営と成長を支援します。iPhone の Tap to Pay は、American Express、Discover、Mastercard、Visa などの主要な決済ネットワークの非接触型クレジット カードとデビット カードで動作します。
Stripe の最高ビジネス責任者であるビリー アルバラド (Billy Alvarado) 氏は、次のように述べています。「iPhone の Tap to Pay により、Stripe を使用する何百万もの企業が、顧客に迅速かつ安全なチェックアウトを提供することで、対面での商取引体験を向上させることができます。」
iPhone のTap to Payは、参加している支払いプラットフォームとそのアプリ開発パートナーが利用でき、今後の iOS ソフトウェア ベータ版でソフトウェア開発キット (SDK) を活用できます。
Sandbox環境は、App、Webサイト、およびPOSシステムでのApple Payのオフライン実装をテストするのに最適です。本ドキュメントは、Sandbox環境の概要、テスト方法の詳細、Apple Payトランザクションのテストに役立つ一般的なサポート情報を提供します。
新しい支払いの形態 Apple Tap to Pay
iPhoneでタップして支払う
支払いアプリは、非接触型クレジットカードまたはデビットカードからの非接触型支払いを受け入れることができるようになりました。アップルペイ、 アップルウォッチ、他のデジタルウォレットを備えたスマートフォン — iPhone 上で、追加の端末やハードウェアは必要ありません。
米国のすべてのクレジット カードとデビット カードの 3 分の 2 以上が非接触型カードとして発行されており、非接触型決済の採用が急速に増加しているため、加盟店はほとんどの顧客から iPhone をタップするだけで支払いをシームレスに受け入れることができます。
簡単で信頼できる支払い体験を提供する
使用している加盟店でタップして支払う。iPhoneで一貫した信頼できる支払い体験を顧客に提供します。顧客に表示される画面には、請求額、加盟店の名前、カテゴリ、アイコン、カードまたはデバイスをタップする場所の指示が明確に示されます。
iPhoneの Tap to Payを使用すると、顧客の支払いデータは、iPhone と同じテクノロジーによって保護されます。アップルペイのプライベートで安全な方法で行われたすべてのトランザクションとなります。
タップして支払う場合、iPhoneでSecure Elementを使用して暗号化および処理されます。アップルペイでの支払いについて、Apple は、何が購入されているのか、誰が購入しているのかを知りません。
支払いカードと購入を検証する
支払いを受け入れることに加えて、マーチャントを使用できます。タップして支払う、iPhoneで請求を行わずに顧客の支払いカードを読み取るため、顧客は次のことを簡単に行うことができます。
- 毎月のジム会費など、将来の支払いのために顧客のファイルにカードを追加します。
- 領収書なしで払い戻しを発行するなど、トランザクションを完了するのに役立つ以前の購入を検索します。
ポイントカードの読み取りと発行
Apple Wallet の NFC 対応のロイヤルティ カード、ディスカウント カード、ポイント カードは、タップして支払う iPhoneで支払いカードとは独立して、または支払いカードと同時に。Apple Wallet でサポートされているロイヤルティ カードを持っている加盟店は、次の場所にもリクエストを送信できますアップルペイに関連してロイヤルティ プログラムに参加する顧客タップして支払う iPhoneで取引。
Tap To Payを始めてみる。Get started
WWDC Tap to pay
♪ 明るい音楽 ヒップホップのミュージック♪ ♪ こんにちは 私の名前はLaisと申します。Davidと申します。ウォレットおよびApple Payの今年新しくなった機能について説明します。2014年にApple Payを発表し、店舗やオンラインそしてApp内で迅速かつ安全にプライベート決済を行うための新しいベンチマークを打ち立てました。 それ以降Apple Payは世界中に広がっています。Apple Payは現在72カ国と地域で利用可能で毎日100万件以上の取引が行われています。 本日はウォレットとApple Payに興味深い新機能とAPIを導入したことをお話しします。 Laisが詳しく説明します。 ありがとうございます、David。本日は主要なアジェンダを見ていきます。まず最初に簡単なアップデートの話をします。一度の決済で複数の加盟店への支払いに対応する機能を追加しました。またサブスクリプションなどの自動支払いへの対応も大幅に強化しています。注文の追跡によりユーザーの購入後の体験をより充実させることができます。 そして最後にDavidがウォレットのIDによる本人認証について説明します。 まずはいくつかの興味深い最新情報をお伝えします。 Tap to Pay on iPhoneは今年初めに発表され米国ではiOS 15.4に搭載されました。Tap to Pay on iPhoneは安全でプライバシーが守られており簡潔に非接触型決済を行うことができます。これをAppに統合することでシームレスで安全な非接触型決済を簡単に実現できます。 これにはApple Pay 非接触型クレジットカード、デビットカードなどのデジタルウォレットが含まれます。iPhoneにタップするだけで支払いが完了するため追加のハードウェアや決済端末は必要ありません。 macOS 13ではApple Payのエクスペリエンスを再設計しました。昨年デザインを再設計したiOSのペイメントシートは 大きな成功を収めましたが、今年はmacOSでも同様の体験を提供します。 SwiftUIを使用してこれを実装することでiOSと同時にmacOSにも新機能を搭載することができました。 本日ご紹介するApple Payのすべての機能はMacにも 対応しています。新しいSwiftUI APIを紹介します。 SwiftUIで構築されたAppで Add to Apple WalletやApple Payのボタンを統合することがさらに簡単になりました。これらの新しいAPIは書く必要があるコードの量を大幅に削減します。 エアラインパスの追加をユーザーに促すボタンを追加する方法について見てみましょう。 まず最初にパスを作成します。正常に読み込めなかった場合、処理をする必要があります。 これはパスデータが不正であったり署名が適切でなかった場合などに生じる場合があります。次にパスの配列で AddPassToWalletButtonを呼び出します。この例では要素が1つだけの配列ですが同じボタンに複数のパスを設定することができます。結果はBoolとして送信されユーザーがパスを追加したかどうかに基づきAppに保存・ログするなどの アクションをトリガできます。この例ではそれをstate varに保存します。 これだけです。最小値のセット内でボタンのサイズとスタイルをカスタマイズできます。デフォルトのサイズは幅250、高さ50です それをより幅広くまたは、より高くすることもできます。 SwiftUIでAdd to Apple Walletボタンを追加する方法について説明しました。Pay with Apple Payボタンを追加する方法を見ていきましょう。まず最初にPKPaymentRequestクラスを使用してペイメントリクエストを作成し、それに通常の設定を行います。そしてauthorizationChangeメソッドを作成します。これら2つが準備できたのでボタンを表示するコードを追加してみます。PayWithApplePayButtonの呼び出しを追加し、ラベルpaymentRequestオブジェクト authorizationChangeメソッドを送信します。 Apple Payが現在のデバイスに対応していない場合に処理するために、フォールバックビューを送信できます。Add Passボタンのようにサイズやスタイルをカスタマイズできます。すべてで17種類のラベルが用意されているため、ユースケースに合わせて支払いボタンを、カスタマイズできます。iOS・iPadOS・macOS watchOSで利用可能です。 ここからはマルチ決済について説明します。iOS 16では同じ決済取引で異なる加盟店に対して、複数のペイメントトークンを要求する機能を導入します。オンラインマーケットプレイス、旅行予約、チケット販売サービスなどに便利です。例を見ていきましょう。 Allisonが旅行を計画していると想像してください。旅行代理店のホームページにアクセスすると、航空券、ホテル、レンタカーなど必要なものがすべて提供されています。 Allisonは合計500ドルを支払うだけです。Allisonは旅行代理店にクレジットカードの全情報を提供します。 旅行会社がAllisonのクレジットカードに500ドルを請求し、関係各社に支払うと想像するかと思います。 しかし一般的には旅行会社が各社にクレジットカード情報を伝え、個別決済しています。 これも機能しますが、Allisonのプライバシーやセキュリティにとってクレジットカード情報を共有されるのは、あまり良いことではありません。ここで新たにマルチ決済用のAPIが登場し、取引に関わる各加盟店のペイメントトークンを要求することが可能になりました。このペイメントトークンを使って、複数の企業がそれぞれAllisonに承認された該当金額を請求することができます。 AllisonはApple Payが提供するプライバシーとセキュリティの利点を活用しながら、旅行の予約と決済を行うことがが可能になりました。ペイメントシートも更新され取引に関与したサブマーチャントの内訳をユーザーに表示します。 ユーザーは合計欄をタップすると支払サマリーに移動できます。ここでは決済取引に関わるすべての加盟店の内訳とそれぞれの加盟店に対する承認した金額を確認できます。 Appにマルチ決済を追加する方法について説明します。まず最初にPKPaymentRequestクラスを使用してペイメントリクエストを作成し、通常の設定を行います。次に合計金額など決済のためのサマリー項目を追加します。 次に新しいPKPaymentTokenContextクラスを使用して決済取引に関与する。それぞれの追加のマーチャントのペイメントトークンコンテキストを作成します。各マーチャントの詳細とそれぞれについて承認する金額を記入してください。 最後にペイメントリクエストにペイメントトークンのコンテキストを設定します。すべてのペイメントトークンコンテキストの金額の合計は、ペイメントリクエスト自体の合計金額以下または同じであることを必ず確認してください。 Appでその加盟店のペイメントトークンをリクエストする際には常に同じ加盟店の同じ外部識別子を使用する必要があります。WebでApple Payによるマルチ決済を導入する場合は、Apple Pay JS APIのドキュメントをご確認ください。次は自動支払いにおける改善点について見ていきます。 iOS 16ではウォレットAppから加盟店に設定した自動支払いを表示および管理できる機能を導入しています。 今回のリリースでは、サブスクや分割払い継続課金などの定期支払いと店舗カードの残高補充などの自動リロード支払いの2種類の自動支払いに対応しています。 ペイメントリクエストの際に自動支払いの設定をリクエストできる新しいAPIを導入します。ユーザーのApple IDと連結した新しい種類のペイメントトークンであるApple Payマーチャントトークンを導入し、より確実に継続的にユーザーに課金できるようにします。Apple Payのマーチャントトークンがどのように役立つか、詳しく見ていきましょう。 JulieがiPhoneのApple Payを使ってブッククラブの会費を支払っているとします。ブッククラブがペイメントリクエストをして、Julieが支払いを承認すると、ブッククラブはペイメントトークンを受け取り、毎月そのトークンを使い Julieに会費を請求します。このペイメントトークンは決済を承認するために、使用されたJulieのデバイスに接続されています。 Julieが新しいiPhoneを購入した場合はどうなりますか？新しい自動支払い機能ではJulieの決済ネットワークが対応している場合、代わりにブッククラブがApple Payのマーチャント トークンを受け取ります。このペイメントトークンはJulieのiPhoneではなくApple IDと紐付けられており、継続的な認証を確実に保証します。つまりJulieがiPhoneを機種変更したり、今使っている携帯電話を解約した場合でも、ブッククラブはJulieに確実に月会費を請求し続けることができます。 このようなApple Payでの、決済に対応している場合は自動支払いを導入することでユーザーに確実に継続して請求することができ、サービスに支障をきたさないようにもできます。 今回のリリースで対応する最初の自動支払いの種類は定期支払いです。定期支払いは 毎週・毎月・毎年など 定期的なスケジュールで、課金される固定または変更できる金額設定があります。 これらの決済は指定した日に、終了することもキャンセルされるまで継続することも可能です。 トライアル期間や導入期間もサポートします。サブスク、分割払い、定期的課金などの用途に最適な決済方法です。 自動支払いを使ってAppで定期支払いを設定する方法を見ていきましょう。 PKRecurringPaymentSummaryItemクラスを使用して定期支払いの金額と期間を指定することから説明します。 定期支払いには、通常の請求期間だけでなく導入期間やトライアル期間を指定することができます。startDateおよびendDateプロパティを使用してトライアル期間の終了日と通常の課金期間の開始日を示すことができます。 次に、新しいPKRecurringPaymentRequestクラスを使用して定期支払いリクエストを作成します。決済の説明、定期的な請求期間およびユーザーが、定期支払いの方法を更新または削除するウェブページの管理URLを提供します。 オプションでトライアル課金期間や課金契約テキストを用意することでユーザーに決済条件を理解してもらいやすくなります。 そして、オプションでトークン通知URLを指定し、決済用Apple Payマーチャントトークンが発行された場合、サーバーがライフサイクル通知を受け取ることが可能です。 例えばカード発行会社やユーザーがトークンを削除した場合に通知を受け取ることができます。 マーチャントトークンのライフサイクル通知に関する詳細はApple Pay Merchant Token Management APIのドキュメントを参照してください。 paymentRequestオブジェクトに定期支払いリクエストを設定します。 サマリー項目に関する簡単な留意点として定期支払いはペイメントリクエストのサマリー項目に自動的に追加されることはありません。 サマリー項目の配列に手動でアイテム項目を追加してください。ペイメントリクエストの合計はユーザーに請求される 最初の金額です。 この例では合計がトライアル期間中の金額を表示するように設定されています。 ペイメントシートにはユーザーへの定期支払いの詳細が表示され、ユーザーは請求内容セクションをタップして、詳細を確認することができます。 今回のリリースでサポートする2つ目の種類の自動支払いである自動リロード決済について説明します。 この決済により、残高が一定の基準額を下回る際は自動的に一定の金額が上乗せされます。自動リロード決済は、店舗カードのチャージやプリペイド残高の管理などに最適です。自動リロード決済の設定をリクエストするには、新しいPKAutomatic ReloadPaymentSummaryItemクラスを使用して、リロード額と閾値を指定するところから始めます。 新しいPKAutomatic ReloadPaymentRequestクラスを使用して自動リロード決済リクエストを作成し、定期支払いのように決済の説明、請求書、および管理URLを提示します。オプションで課金契約、文章とトークン通知URLを指定できます。そして、ペイメントリクエスト オブジェクトに、自動リロード決済を設定します。 繰り返しますが、自動リロード決済をサマリー項目に含め請求合計金額を適切に設定してください。 ウェブ上でApple Payによる自動支払いをする場合はApple Pay JS APIのドキュメントをご確認ください。 ここで自動リロード決済がユーザーのペイメントシートにどのように表示されるのかを説明します。 Appで自動支払いをする際にユーザーに最高の体験を提供するために留意していただきたいことをいくつかご紹介します 自動支払いのサマリー項目は、システムにより追加されないため気をつけてください。 合計請求金額は、ユーザーが最初に請求される金額です。課金規約の文章は、短くすることが適切です。ペイメントシートには最初の500文字だけが表示されます。課金契約の文章は、ユーザーの通常の課金契約や法的契約に置き換わるものではありません。各地域の定期支払いに関する法律に準拠するかどうかは、皆さま次第です。 ユーザーに提示する法的契約書がある場合、それはペイメントシートの前にお客様に提示するべきものです。1回の取引で リクエストできる自動支払いの種類は1つだけです。マルチ決済では、自動支払いはご利用いただけません。決済用に発行されたApple Payマーチャントトークンのライフサイクル通知を受け取りたい場合、必ずトークン通知URLを指定して Apple Pay Merchant Token Management APIをサーバーに導入してください。 これらの新しいAPIと Apple Payのマーチャントトークンの利点を気に入っていただけると思います。 自動支払いを採用するパートナー企業の一部をご紹介します。 Apple PayマーチャントトークンはAmerican Express・Discover Mastercard・Visaに対応し、将来的に他の決済ネットワークにも対応する予定です。購入後の体験を充実させるために次に、注文の追跡機能を導入しました。 iOS 16の新機能である注文の追跡は参加加盟店への注文を追跡できます。ウォレット内でアクティブな注文、最近完了した注文、過去の注文の概要を直感的に把握できるようになりました。 あるベーカリー商品の注文が1件現在処理中になっています。注文がまだ処理中ですが後ほど戻って確認します。今はPet Avenueで私の猫のために、おもちゃやアクセサリを購入したいと思います。 Apple Payで購入することを選択しました。決済承認してすぐにウォレットにその注文を追跡するための通知が届きました。その通知から注文に関する詳細、現在の状況が確認できます。 配送や追跡情報を含む注文の情報が確認でき、注文したアイテムのリストも確認できます。下記にはPet Avenueの連絡先や決済情報の確認Pet Avenue Appに戻るといった複数の選択肢があります。 Pet Avenueは注文処理が本当に早くすぐに商品を発送したと想像してください。Pet Avenueは発送してすぐに、現在確認できる情報を更新しました。 「発送済み」に状態が変更されたことを確認でき、6月10日に到着予定ということも確認できます。 配送におけるカスタムメッセージや追跡情報も共有できます。私のベーカリー商品のことを覚えていますか？ ちょうど受け取り準備ができたと通知が来ました。確認しましょう。受け取り設定でベーカリー商品を注文していました 。受け取り準備ができたようです。Bake My Breath Awayは、受け取り画面、受け取り説明、到着した物を受け取る バーコードを提示します。 Apple Payでシームレスに注文の追跡を確認できました。注文の追跡をどのようにユーザーのエクスペリエンスに統合していくのか見ていきましょう。注文の追跡について見ていくには、まず最初にディベロッパアカウントのOrder Type IDを 作成する必要があります。 Order Type IDは、エンティティとして組織を識別し注文情報を提示します。複数のOrder Type IDを登録でき、例えば複数の加盟店に代わって注文情報を提供します。Order Type ID Certificateも作成します。その認証情報を使用して注文パッケージの構築や注文を更新します。注文は注文パッケージとして割り当てられます。注文パッケージには 注文のメタデータや情報すべて含まれます。 配送、受け取り、オーダーフルフィルメントなど、幅広いシナリオで表示されます。注文パッケージには、ロゴやラインアイテムなどの画像も含まれます。ローカライゼーションを追加することで多様なユーザーに対応することも可能です。 すべての注文パッケージは、そのオリジンを確認するために暗号化された署名が必要です。すべてが揃ったところで注文パッケージを展開用に圧縮します。このセッションに付随する注文パッケージのサンプルを確認してください。 注文パッケージに関する詳細につきましてはデベロッパードキュメントを確認ください。 Apple Payでシームレスにウォレットに注文を追加します。ユーザーが決済を承認した際に、Appまたはホームページで 決済情報を受け取り、サーバーへ処理するために送られます。決済情報が正常に処理されるとサーバーは注文といくつか メタデータを作成します。サーバーはAppやホームページに結果を含めた注文についての詳細を返します。注文の詳細によりデバイスでサーバーから注文を非同期リクエストすることができます。サーバーはデバイスに注文パッケージを返します。 サーバーは注文を作成する際にOrder Type IDの名前空間内で、固有のOrder IDを割り当てます。サーバーに安全性のある認証トークンを生成することも必要です。これは、注文の詳細の一部でもある共有された秘密です。デバイスは注文をリクエストした際にデバイス自体を認証するためトークンを使用します。 決済認証の結果を返す例を見ていきましょう。ユーザーが決済を認証した際にAppは決済情報をサーバーへ送り、注文を作成するよう要求します。サーバーの結果が成功を示しているかどうかを確認し、サーバーから返されたエラーを処理します。サーバーが成功を示した場合、適切な認証結果で決済を完了してください。注文の詳細で決済の認証結果を返すにはまず初めにサーバーの結果から抽出する必要があります。 Order Type ID Order IDサーバーへのURLおよび認証トークンを含むPKPaymentOrderDetailsオブジェクトを作成します。PKPaymentOrderDetailsオブジェクトをPKPaymentAuthorizationResultの新しいorderDetailsプロパティに割り当てます。それだけです。 ウェブ上で注文の詳細による決済を完了することもできます。以前と同様にサーバーの結果から注文の詳細を抽出します。 決済を完了するデータに、注文内容を記載してください。注文を更新するために自動更新のサポートを示す注文パッケージを作成します。注文が追加されるとデバイスは更新するためにそれに登録します。 サーバーは登録に関する店舗情報を保管する必要があります。後ほどサーバーが注文を更新する際に、登録情報を使用して更新するために登録したデバイスを示します。デバイスがプッシュ通知を受け取るとサーバーから注文リクエストを再度行うことができます。サーバーは更新した注文パッケージをデバイスに返します。ユーザーと皆さまだけがそれらが注文されたことを知る必要があります。 注文の追跡を非公開で設計しています。注文情報は直接デバイスとサーバー間でやり取りされます。iCloudを介して注文が同期された場合、エンドツーエンドで暗号化されています。最高のカスタマーエクスペリエンスを提供するためにこれらのプラクティスを実施してください。Appと提供する注文を関連付けます。 Appが通知を配信しインストールされた場合、注文の追跡通知は無効にできます。これにより重複した通知を防ぐことができます。ユーザーの好みに関する知識を利用して適切なローカライゼーションだけを提供します。注文パッケージのサイズには気をつけてください。小さいサイズを維持するようにして高いネットワークコストを削減してください。注文を更新する際に更新するために登録したデバイスの通知を促します。ウォレット内の注文は注文の\実際の状態と、一致している必要があります。 注文の追跡のためにHIGを確認することも忘れないでください。プラットフォームは注文の追跡の統合をより簡潔に実施できます。秋までにShopify Narvar Routeが注文の追跡に対応することを発表します。注文の追跡に対応するプラットフォームが次月に増えますので注目していてください。注文の追跡はユーザーにとって購入後の体験を強化する最適な方法です。自動更新によりユーザーは注文の状態について、常に最新のものを確認できます。ユーザーはこの体験をきっと喜ぶと思います。皆さまが受けた注文で活用されることを楽しみにしています。ここからは、Davidに代わります。 ありがとうございます。Lais! iOS 16でのウォレットのIDを追加する新しい機能について話していきたいと思います。 今年初めにiOS 15.4のウォレット内にIDを搭載しました米国の該当する州のユーザーは運転免許証や州IDをウォレットに追加できます。ウォレット内のIDは、ユーザーの物理的IDと同じ発行機関によって発行されています。米国では各州のDepartment of Motor Vehiclesそれに相当する組織が該当します。 iOS 16ではAppやApp Clipがユーザーの年齢や本人確認を行うためにウォレット内のIDに情報を要求できる、新しいAPIが追加されました。Appは情報をリクエストしてユーザーはリクエストを確認し承認します。その後Appは復号化および検証のため、サーバーにレスポンスを送ります。 ユーザーIDからデータ要素の数をリクエストできます。これらには氏名、住所、生年月日、顔写真、発行機関、身分証明書の番号と有効期限、運転免許証の種類（該当する場合）などが含まれます。 IDのユースケースとして非常に一般的なのは年齢確認です。物理的なIDの場合生年月日を見ます。生年月日は年齢を確認するためだけの必要な情報よりも多くの情報を明確にします。私の年齢を確認する場合実際に生まれた日や年、年齢を正確に知る必要はありません。十分な年齢に達しているかどうかだけを知る必要があります。 ウォレット内のIDで直接その質問に回答することができます。Appはユーザーが特定の年齢以上であるかどうかを示す、ブール値のデータ要素を要求することができ、完全な生年月日を確認するよりもプライバシーを保護する方法で年齢認証ができます。 AppがAPIを呼び出すとどんな情報をリクエストしたかがシートに表示されます。その情報を保存する意図があるかどうか 保存する期間も表示されます。これによりユーザーは情報をAppと共有するかどうか十分な情報を得た上で、判断することができます。 Face IDやTouch IDを使って相手が明確に承認するまで情報が共有されることはありません。あなたが受け取るレスポンスにはリクエストした要素だけが含まれています。物理的なIDカードをスキャンするなどの他の本人認証の仕組みでは IDに記載されている内容をすべて共有することになります。ウォレット内のIDにより必要な情報だけを限定して共有することでユーザーにとって、よりプライバシーが守られサーバーで安全に保管するべき機密情報の量も減らすことができます。このレスポンスにはIDの発行元が署名しているため、その情報が本物であることを、簡単に確認することができます 発行機関はIDを作成しますがAPIを呼び出す時点では関与しません。 ユーザーが自身の情報をいつ誰と共有したかを知ることはできません。APIを利用するにはディベロッパアカウントを介してエンタイトルメントをリクエストする必要があります。マーチャントIDや暗号化証明書を設定する必要があります。 このプロセスはApple PayでApp内決済の設定をする際に、とても似ています。IDと認証の活用について後ほど話したいと思います。ここからは検証フロー について話していきます。 ハイレベルで4つのステップで構成されています。まず最初にAppはPassKitフレームワークでAPIを起動して、リクエストしている情報を特定します。システムはシートを表示してユーザーにリクエストを承認することを促します。リクエストが承認されるとAppは暗号化された応答を受け取ります。Appは復号化や検証を行うためにサーバーに応答を送ります まず最初にPassKitにAPIを使用する方法について話します。AppがSwiftUIする場合Appの VerifyIdentityWithWalletButton SwiftUIビューを使用する必要があります。 ボタンを押すと本人確認フローが起動するボタンが表示されます。Pay with Apple PayやAdd Pass to Walletボタンを追加するようにウォレットボタンによる個人認証の検証はAPIを使用する、すべてのAppで馴染みのある一貫した体験を提供します。 4つの異なるラベルから選択してユースケースに適したボタンを表示できます。利用可能なスペースに応じて1行および複数行のバージョンを自動的に切り替えます。ボタンを作成する際にPKIdentityRequestオブジェクトを指定する必要があります。それにはリクエストしたい情報とその返送方法が記述されています。その作成方法について見ていきましょう。 探しているデータ要素を記述したPKIdentityDrivers LicenseDescriptorを作成することから始めます。 addElementsメソッドを使用してリクエストしたい要素と、その要素を保存するかどうかを指定します。addElementsメソッドを複数回起動することで保管するため意図の異なる要素セットを指定できます。この例では２回呼び出しています。まず最初に「最低でも18歳」要素を追加しそれは保存されることはありません。再度addElementsメソッドを呼び出しユーザー名、苗字、顔写真を要求しており、これらはすべて最大30日間保存可能です。 記述子はその後 PKIdentityRequestに入ります。次のステップは使用するマーチャント識別子を特定することです。マーチャント識別子は暗号化認証を示しそれによりAPI応答は暗号化されます。ディベロッパアカウントを介して、マーチャント識別子と暗号化認証で構成します。APIから受け取るレスポンスに紐づくnonceを指定する必要があります。 応答の再送を防止し特定のユーザーセッションに結びつけるために使用される重要なセキュリティ機能です。nonceをどのように管理するかはご自身のセキュリティ要件に基づき決定してください。多くの場合これはサーバーからです。後ほどサーバーはnonceが有効であることを強化することに対応します。これらのプロパティを設定することでPKIdentityRequestがあります。 これからはボタンについて振り返ります。個人認証が有効の場合Appにボタンが表示され、タップするとリクエストによる個人認証フローが開始されます。個人認証が有効でない場合、指定したフォールバックビューが代わりに表示されます。 例えばiPhoneにウォレットのIDがない場合これは発生します。フォールバックビューを使用して個人を認証する 他の方法を提供します。 個人認証が有効だったとしてユーザーはボタンをタップします。システムはリクエストによりシートを表示し、それには リクエストした要素やそれらを保管の意図が含まれます。ユーザーはFace IDまたはTouch IDでリクエストを承認したり承認なしにシートを閉じることができます。 コードはリクエストの結果を含む、結果のオブジェクトを受け取ります。リクエストが承認されると成功結果を受け取ります。これは暗号化応答を含むPKIdentityDocumentオブジェクトによるものでありAppはサーバーに復号化や認証のために送信します。 リクエストが成功しなかった場合、失敗の結果を受け取ります。失敗の最も共通の原因は、リクエストが承認されないことでありキャンセルされたエラーを受ける場合に発生します。それはVerifyIdentityWithWalletButtonでありAPIのSwiftUIバージョンです。それを使用してボタンを表示し個人認証フローを起動し、ウォレットのIDから情報をリクエストします。 AppでSwiftUIを使用しない場合、PKIdentityButtonやPKIdentityAuthorization Controllerクラスを使用して同じことを完了することができます。今まで情報をリクエストしユーザーはリクエストを承認しAppは暗号化応答をサーバーに送信してきました。 次にサーバーが応答を復号化および検証するためにすべきことについて話していきます。このトピックでは簡潔に概要を説明するだけなので詳しくはディベロッパ ドキュメントを確認してください。対応形式はいくつかの国際基準を用いるため、それらについて理解することを強く推奨します。受け取る応答データはCBORで暗号化されたエンベロープにあります。 CBORはRFC 8949で定義されたデータ形式です。JSONに類似していますが、オブジェクトをエンコードするためにバイナリデータを使用します。暗号化エンベロープは復号化処理に必要なメタデータを含んでおり暗号化データ自体も同時に含んでいます。HPKEを使用してデータは暗号化されそれはRFC 9180で定義された暗号スキームになります。 サーバーは秘密鍵を使用してこのデータを復号化します。復号化するとmdoc応答オブジェクトを取得します。mdoc応答はモバイル運転免許証、および州IDのISO規格であるISO 18013 part 5に定義されています。mdoc応答オブジェクトはリクエストしたデータ要素を含みます。応答が本物であることを確認するためにサーバーが検証するべき、多くのセキュリティ機能が含まれています。サーバー自身が復号化を行い検証します。Appleサーバーや発行機関のサーバーはどちらも関与しません。復号化と応答の検証について話す前にセッショントランスクリプトについて話す必要があります。 これは応答ペイロードと特定のAppの特定のリクエストを結ぶCBOR構造ですサーバーはこの構造を構築し復号化および検証の際に使用する必要があります。セッショントランスクリプトは先ほどPKIdentityRequestで使用したものと同じ nonceやマーチャントIDを含みます。ディベロッパチームのチームIDと暗号化証明書の公開鍵のSHA256ハッシュも含みます。セッショントランスクリプトを構築する際、サーバーは使用した入力がすべて有効であるか確認する必要があります。 nonceはすでに使用されておらず現在のユーザーと結びついている必要があります。他の値はディベロッパアカウントの内容と一致している必要があります。ここからは暗号化データの復号化について話します。作成したばかりのセッション トランスクリプトが暗号化エンベロープのメタデータと同様に必要になります。秘密鍵も必要です。これは先ほどディベロッパアカウントで設定した証明書に対応する秘密鍵です。 ユーザー情報の守秘義務を守るために秘密鍵は常に非公開であることを確認してください。 サーバーに保存して守りAppには保存しないでください。秘密鍵が漏洩した場合は直ちにディベロッパアカウント証明書を失効させてください。暗号化データの復号化後2つの暗号署名とリクエストされたデータ要素を含むmdoc応答オブジェクトを受け取ります。データ要素を使用する前にmdoc応答でどちらの署名も確認する必要があります。まず初めに発行者の署名を確認します。これはユーザーIDの発行機関の署名です。この署名を確認することで応答のデータが本当の発行機関のものであり改ざんされていないことを検証します。 その署名が有効であるかを確認するだけでなく信頼できる発行機関の署名であるかも確認する必要があります。ウォレットのIDを使用した。発行機関の証明書についての詳細はドキュメントを確認してください。 次にデバイスの署名を検証する必要があります。この署名はユーザーのiPhoneのSecure Elementの鍵によって作成されました。それは受け取った応答が発行機関がもともとIDを発行したiPhoneと同じものであることを証明するものです。ここではセッショントランスクリプトを発行機関の署名による情報と同時に再度使用する必要があります。これでリクエストしたデータ要素を使用する準備が整いました。これらの要素を発行機関およびデバイスの署名の検証なしに絶対に使用しないでください。 そうしなければ受け取ったデータが本物かどうかわからないからです。 これらのステップは完了しました。これで完了です Appは情報をリクエストしサーバーは応答を復号化および検証しました。ウォレットにIDがない場合、どのように実装をテストするのか疑問を持つかと思います。これについては、いくつかメカニズムがあります。まず初めにiOS シミュレータでテストできます。そこではAPIがmock応答を返します。 この応答は実際のものと類似していますが実際の署名が不足しています。同様にテストプロファイルを使用してiPhoneのウォレットにIDがない場合でさえも、iPhoneに実際にmock応答を受け取ることができます。これについての詳細はドキュメントをご確認ください。サーバーはこれらのmock応答を決して本物のように処理してはいけませんので注意してください。サーバーの実装に役立つようにドキュメントには応答例とそれを復号化および検証するために必要なものがすべて含まれています。 iOS 16ではウォレットのIDで個人認証ができるようになりました。AppでAPIを使用する方法やサーバーで応答を処理する方法や実装をテストする方法について話しました。今年はウォレットおよびApple Payにたくさんの新しい機能を導入しました。これらにはマルチ決済や自動支払いの改善や注文の追跡、個人認証が含まれます。 詳細につきましては、デベロッパ ドキュメントを確認ください。ご視聴ありがとうございました。 素晴らしいWWDCを! ♪
アムステルダムに本拠を置く決済ソフトウェアプロバイダーの「Adyen（アディエン）」は、アップルの新機能「Tap to Pay」を競合のストライプに先駆け、幅広い顧客向けに提供している。Tap to Payは、iPhoneを決済端末にして支払いを受けられる機能で、加盟店はハードウェアを新たに設置する必要がない。
アップルは、2月にiPhoneと対応アプリだけで決済が可能なTap to Payを発表した。この機能は、顧客が自分のiPhoneを、店側のiPhoneにタップするだけで支払いを完了することができるもので、アップルは、ストライプが最初に対応アプリを提供すると述べていたが、同社のアプリはまだテスト段階にあり、リリースは来年春になる予定だ。
ECプラットフォームのShopify（ストライプを採用）とSquareは、一部の加盟店限定でTap to Payを提供している。一方、Adyenは7月12日、米国のすべての同社の顧客がiPhoneで即座に、Tap to Payを利用可能になり、アパレルメーカーのVinceやG-Star、スコッチ&ソーダ、ナイキなどが対応したと発表した。Adyenのソフトウェアは、加盟店の既存ソフトウェアと統合できるように設計されており、新たにダウンロードする必要がない。
Adyenは、アフターコロナ時代における新たなショッピングパターンに勝機を見出そうとしていると、同社CFO（最高財務責任者）のIngo Uytdehaageは話した。
米国本拠のライバルのSquareが実店舗を主な対象とし、ストライプがECに特化しているのに対し、Adyenは実店舗とECの両方に対応している。Adyenは、現CEOであるPieter van der DoesとArnout Schuijiffによって2006年に設立された。2人は、2018年の同社のIPOによりビリオネアとなっていた。
ここ最近は、フィンテック企業の株価が暴落しているが、2人の資産額はVan der Doesが18億ドル、Schuijiffが24億ドルと、今でもビリオネアの地位を維持している。
Adyenは、2021年にウーバーやスポティファイ、リーバイス、イーベイなどの顧客を介して5160億ドルの決済を処理した。ストライプの処理額は6400億ドルだった。
Adyenは、ユーロネクスト・アムステルダムに上場しており、時価総額は433億6000万ドルとなっている。同社の収益は過去3年間で平均64%増加したが、他のフィンテック銘柄同様、同社の株価も暴落し、ADR（米国預託株式）は13.81ドル程度と、年初来で45%下落している。競合他社では、ペイパルの株価が年初来で62%安、ブロック（旧スクエア）が60%安となっている。
マクロ環境が厳しさを増す中、Adyenは米国事業を強化している。Uytdehaageによると、同社は2021年に売上の40%以上を欧州以外で稼ぎ、米国は2番目に大きな市場だという。同社は、ニューヨークとサンフランシスコの事業所を拡張している。テック企業の多くがリストラをする中、リンクトインのデータによると、Adyenは6月から7月にかけて34人を新規採用した。
コメント