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

What's new in Wallet and Apple Pay

WWDC 2020Apple PayWalletPassKitApp Clips
观看原视频

Highlight

Apple 在 iOS 14 和 macOS Big Sur 中为 Apple Pay 增加了新的 PassKit 类型、更多支付按钮样式、App Clips 付款建议、Mac/Catalyst 支持、联系人格式化和发卡行 Wallet 扩展，开发者可以把一次性交易和跨平台结账流程做得更短。

核心内容

过去接 Apple Pay，经常被理解成「在完整 App 或 Safari 里放一个付款按钮」。这场 session 把按钮放进更长的交易链路里：用户如何看到正确的付款入口，如何在 App Clip 里少填表，如何在 Mac 上调用 Apple Pay，商户如何拿到更稳定的联系人数据。

第一个变化来自 Wallet 的边界扩大。Apple Pay 已经覆盖信用卡、交通卡、学生证等需要 Secure Element 支撑的场景。PKPaymentPass 里的 payment 语义变窄了，所以 Apple 新增 PKSecureElementPass，并建议新老开发者迁移过去，PKPaymentPass 未来会被废弃。（01:17）

第二个变化落在入口。PKPaymentButton 仍然是付款主入口，但按钮类型更细，可以表达 rent、tip、给交通卡充值等具体动作；PKButtonStyleAutomatic 会跟随系统浅色/深色外观切换按钮样式。用户看到的按钮不再只写「购买」，而是贴近当前任务。（01:35）

第三个变化是 App Clips。停车、租车、餐厅付款、加油这些任务不值得让用户先完整下载 App。Session 建议把 Apple Pay 作为 App Clip 的默认付款方式，允许游客结账，把账号创建放在购买完成后，并用 Sign in with Apple 降低注册成本。（03:04）

后半段转向平台一致性。Apple Pay 来到 Mac Catalyst 和原生 Mac app，联系人数据在 iOS、macOS 和 Web 上会有基础格式化，发卡行也可以通过 Wallet 内的 extension 让用户更容易发现可添加的卡。交易链路从「能不能付」变成「在哪个平台都少出错」。（06:18）

详细内容

Secure Element 通行证的新名字

（00:57）交通卡、学生证和支付卡在设备侧的共同点是 Secure Element，而不全是 payment。PKSecureElementPass 保留了 PKPaymentPass 的属性，名字更准确。Apple 明确建议新项目和现有项目都开始采用它，并说明 PKPaymentPass 会在未来废弃。

这给 Wallet 类应用一个迁移信号：如果代码是在枚举设备上的 Wallet 凭证，而不是专门处理一次付款，应优先检查 PKSecureElementPass。这样代码语义和 Wallet 能承载的凭证类型一致。

用按钮类型表达具体交易

（01:35）PKPaymentButton 增加了更多 button types。Session 里举的场景包括租车、租自行车、打赏、给交通卡充值。type 控制按钮文案，style 控制外观。新的 PKButtonStyleAutomatic 会根据系统主题自动在浅色和深色样式之间切换。

这件事小，但直接影响转化。一个 App Clip 如果是扫码租车，按钮应该是 rent with Apple Pay；如果是小费场景，按钮应该是 tip with Apple Pay。按钮文案越贴近任务，用户越少需要猜测下一步发生什么。

App Clips 里的付款路径

（03:54）Apple 给 App Clips 的付款建议很明确：能用 Apple Pay 就优先用 Apple Pay；允许 guest checkout；账号创建推迟到购买完成后；需要账号时用 Sign in with Apple；让 App Clip 保持简单聚焦；地图、路线等资源按需加载，不要塞进初始下载。

这些建议都围绕一个事实：App Clip 的用户通常站在真实场景里，只想完成当下任务。停车、点餐、租车、加油都适合把付款放到最短路径里。表单、完整账号系统和大资源包会把用户从任务里拖走。

Web 和 Mac 上的 Apple Pay

（05:08）Web 侧有两个体验补强。PKPaymentButton 在 Web 上支持自定义圆角，商户可以在默认圆角、胶囊形和更方的样式之间调整。数字商品和服务可以拿到 redacted billing address，用来计算税费等可变 line items，让用户在认证前看到完整价格。

（06:18）Mac 侧的变化更大。Apple Pay 支持 Mac Catalyst 和原生 Mac app，PKPaymentButton 也来到 Mac，包括新的 button types 和 automatic style。原生 App 获取 merchant session 时不再依赖 WebKit 给出的验证 URL，而是使用一个静态 URL；Apple 还建议 Web 支付也迁移到新方式，旧方式会在未来移除。

// PKPaymentAuthorizationControllerDelegate

func presentationWindow(for controller: PKPaymentAuthorizationController) -> UIWindow? {
    let purchaseWindow = yourViewController.view.window
    return (purchaseWindow) // The window presenting the payment sheet.
}


func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController, didRequestMerchantSessionUpdate handler: @escaping (PKPaymentRequestMerchantSessionUpdate) -> Void) {
    // Get merchant session to enable the user to authorize a transaction.
    var dict = try? JSONSerialization.jsonObject(with: data, options: .allowFragments) as? [String: Any] {
        let session = PKPaymentMerchantSession(dictionary: dict)
        let update = PKPaymentRequestMerchantSessionUpdate(status: .success, merchantSession: session)
        handler(update)
    }
}

关键点：

  • presentationWindow(for:) 返回发起购买的窗口，让 PKPaymentAuthorizationController 知道支付 sheet 该挂在哪里。
  • paymentAuthorizationController(_:didRequestMerchantSessionUpdate:) 负责向你的服务器请求 merchant session。
  • 服务器安全地从 Apple 获取 session 后，App 用 PKPaymentMerchantSession 包装结果。
  • PKPaymentRequestMerchantSessionUpdate 通过 handler 交回给系统，用户才能继续授权交易。

WKWebView 的限制变化

（08:33）很多原生 App 会通过 WKWebView 加载网页来收 Apple Pay。随着 tiered WebKit 引入，WKWebView 更接近 Safari View Controller：在 app-defined domains 之外，能调用的 API 会受限，JavaScript injection 也会被更多阻止。

Apple Pay 的实现方式没有变。以前 iOS 上如果 WKWebView 注入了脚本，就不能执行 Apple Pay 交易；现在更多 WKWebView 会被系统阻止脚本注入，所以更多加载页面可以执行 Apple Pay 交易。对混合 App 来说，这反而减少了网页支付被脚本注入拦住的机会。

联系人数据格式化和错误提示

（09:38）用户多年使用 Apple Pay 后，设备里可能积累了格式不一致的联系人信息。Apple 从最新 iOS 和 macOS 开始在支付 sheet 中提供基础格式化。美国商户可以期待街道和城市只包含字母数字、标点和空白，州字段是两个字母，邮编是五位或九位数字，ISO 国家代码是大写两位。

（11:08）错误也会更早出现在付款流程里。示例包括不完整邮编和无效电话号码，用户可以在 Touch ID 或 Face ID 认证前修正。Session 建议开发者使用 Error APIs，让用户知道哪一项需要改。首批地址格式化覆盖 Australia、Canada、United Kingdom 和 United States。

发卡行扩展把开卡入口放进 Wallet

（12:34）最后一项更新面向发卡行。Issuer extensions 让用户在 Wallet 内发现自己可以添加的卡。前提是发卡行 App 已安装，用户至少登录过一次，这样 Wallet 才知道有卡可以展示。

实现上分两层。非 UI extension 报告状态、可用 pass，并执行 card data lookup；它需要 subclass PKIssuerProvisioningExtensionHandler，也需要 entitlement。如果非 UI extension 报告需要认证，还要提供 UI extension，view controller conform to PKIssuerProvisioningExtensionAuthorizationProviding，并申请单独 entitlement。（12:58）

核心启发

  • 做什么：把 App Clip 的付款按钮改成场景动作。 为什么值得做：Session 明确提到 PKPaymentButton 新增 rent、tip 等具体类型，按钮可以直接表达当前交易。 怎么开始：梳理 App Clip 的触发场景；停车用付款/续时语义，租赁用 rent，打赏用 tip；样式优先试 PKButtonStyleAutomatic。

  • 做什么：为 Mac 版应用接入原生 Apple Pay。 为什么值得做：Apple Pay 支持 Catalyst 和原生 Mac app，照片书、商品订购等桌面交易不用再绕到 Safari。 怎么开始：使用 PKPaymentAuthorizationController，实现 presentationWindow(for:) 和 merchant session update delegate，把 merchant session 请求放到服务器。

  • 做什么：给数字商品结账补齐税费预估。 为什么值得做：Web 上可以使用 redacted billing address 计算可变 line items，用户在认证前能看到完整价格。 怎么开始：在 Apple Pay on the Web 流程中请求用于计算的账单地区信息，用它计算税费，再把最终 line items 返回支付 sheet。

  • 做什么：上线前清理 Apple Pay 联系人错误处理。 为什么值得做：新的格式化规则会更早暴露邮编、电话等错误；开发者配合 Error APIs，用户能在认证前修正。 怎么开始：检查 shipping 和 billing 的校验分支，把字段级错误映射到 Apple Pay 的错误 API，并覆盖美国、澳大利亚、加拿大、英国地址样例。

  • 做什么：发卡行 App 把「添加到 Wallet」入口搬进 Wallet。 为什么值得做：Issuer extensions 让已安装并登录过的发卡行 App 在 Wallet 内展示可添加卡，用户不必先主动打开发卡行 App。 怎么开始：实现 non-UI extension，subclass PKIssuerProvisioningExtensionHandler；需要重新认证时，再补 UI extension 和 PKIssuerProvisioningExtensionAuthorizationProviding。

关联 Session

评论

GitHub Issues · utterances