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

What’s new in Apple Pay

MetalGPUMetalFXShadersvisionOS
Watch original video

Highlight

The Apple Pay button is dynamic this year: in SwiftUI and UIKit apps, eligible users see the card art of their default bank card, as long as the payment request includes a Merchant Category Code and supported payment networks.

Core Content

For the past ten years, Apple Pay has focused on making users pay faster, but the merchant-side experience has barely changed: the button is a black button, preauthorised payments can only show the default merchant name supplied by the payment network, and order tracking either runs through the Apple Pay flow, or relies on email attachments, or shows an “Add to Wallet” button. The result is that users cannot tell which merchant charged them, and developers cannot extend their brand into Wallet.

This year’s WWDC fixes all three at once. The Apple Pay button becomes a dynamic button that shows the card art of the bank card the user is about to use. The preauthorised payment page is unified, and merchants can supply a custom logo, name, description, and image. Order tracking taps into Apple Intelligence, so Wallet can detect order emails in Mail and turn them into Wallet orders automatically. Together with the new background delivery extension in FinanceKit, finance apps can keep their data fresh while the app is not running. This matters for developers who build budgeting tools, spending analytics, or live-updating widgets.

Detailed Content

The dynamic Apple Pay button (01:11) lets the button pick the best card for the current transaction. To tell the button which cards fit, set merchantCategoryCode on PKPaymentRequest:

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

// Use the initializer that takes PKPaymentRequest, so the button picks a card based on these fields
PayWithApplePayButton(paymentRequest: paymentRequest) {
    // handle payment
}

Key points:

  • supportedNetworks decides which payment networks are allowed; cards outside the array are marked unavailable.
  • merchantCapabilities specifies which encryption protocols and card types are supported.
  • merchantCategoryCode is an industry-standard code (for example, 5995 is pet supplies). It tells the user which card will work before checkout, which avoids failed payments.
  • You must use the initializer that takes PKPaymentRequest. Otherwise the button falls back to the original style.

If you do not want the new card art look — for example, your brand spec demands a solid black button — turn it off with a view modifier (03:25):

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

Key points:

  • payWithApplePayButtonDisableCardArt forces the original button style.
  • The modifier applies to the whole view hierarchy, so you can apply it to many buttons or the entire app at once.
  • SwiftUI and UIKit apps get the new button for free, with no extra work.

Preauthorised payments (03:55) get a bigger overhaul. Wallet now has a unified preauthorised payments view that lists all subscriptions and recurring charges, and can push notifications for upcoming charges. To show your logo, name, and payment details, implement the Merchant Token API: your server exposes a bundle-vending endpoint that returns a zip file (with usage information JSON, merchant logo, product images, and optional localization files). The whole bundle is end-to-end encrypted to the customer’s device with HPKE in auth mode, and each bundle is capped at 5MB. The schema’s key fields are merchantTokenIdentifier, merchantName, merchantLogoName, upcomingPayments, and pastPayments.

Automatic order tracking (10:19) uses on-device Apple Intelligence to detect order emails in Mail and convert them into Wallet orders. For accurate detection, the email body needs the merchant name, each email needs an order number, and there should be a tracking number that links shipping emails together. Merchants can register their email address and logo with Apple Business Connect, so the detected order carries the brand. For deeper features — order updates without email, integrated receipts, returns flows — you can still use the traditional order bundle, or set webServiceURL on the payment request.

The FinanceKit background delivery extension (13:56) is the most practical new capability here. The new extension type implements two endpoints: didReceiveData receives a [BackgroundDataType] array (values are accounts, accountBalances, transactions) telling you which data changed; willTerminate is called when the time window ends, giving you a chance to save in-progress work. The app side only needs to declare the data types and update frequency it cares about (hourly / daily / weekly) to FinanceStore. When a charge happens, the system wakes the extension automatically, so you can update widgets or build daily spending reports while the app is not running. FinanceKit also expanded to the UK this year (12:55), connecting to Connected Cards through the Open Banking Standard.

Core Takeaways

  • What to do: Add Merchant Category Code and supportedNetworks to your existing Apple Pay integration.

    • Why it is worth doing: This is the prerequisite for the dynamic button. The change is only a few lines of code, but it directly cuts the payment failure rate, since users see which card will work before checkout. SwiftUI and UIKit apps get the new button look for free, but only if you fill these fields.
    • How to start: Find every place where you create a PKPaymentRequest. Add merchantCategoryCode, confirm supportedNetworks and merchantCapabilities are set, and make sure the button is initialized with PKPaymentRequest, not a simple callback.

  • What to do: Implement the Merchant Token Usage Information bundle for subscription products.

    • Why it is worth doing: Users in Wallet stop seeing strange merchant names from the payment network, and start seeing your logo, your custom name, and your subscription details. It is a new brand surface, and it suits SaaS, streaming, and fitness subscriptions that charge on a schedule.
    • How to start: Generate a Merchant Public/Private key pair on the server and persist it. Build the bundle-vending endpoint per the docs. Build a sample zip (≤5MB, with logo, JSON schema, and product images) and run the end-to-end encryption flow once.

  • What to do: Move budgeting and spending apps to the FinanceKit background delivery extension.

    • Why it is worth doing: Widgets no longer wait for the main app to launch before refreshing. As soon as the user buys something or a card posts, they see the latest balance. This is a real gap in retention and “live feel”.
    • How to start: Add a background delivery extension target. Implement didReceiveData and willTerminate. Move your data store to an app group. In the main app, register the data types and frequency you care about with FinanceStore (hourly/daily/weekly). Test with real transactions and confirm the widget refreshes while the app is closed.

  • What to do: Re-template your order confirmation emails for Wallet’s automatic tracking.

    • Why it is worth doing: Users see orders and shipping info in Wallet without doing anything. Support load drops, and missed deliveries become rarer. Once you register with Apple Business Connect, the detected order also carries your brand logo.
    • How to start: Audit the current order confirmation templates. Make sure the body has a merchant name and an order number. Make shipping emails carry the same tracking number. Register your business email and logo with Apple Business Connect. Send a test email to a test account, and confirm Wallet picks the fields up correctly.

Comments

GitHub Issues · utterances