Apple Pay 的新功能

Hello! I’m Mia from the Wallet & Apple Pay team and today, I’m excited to share with you just some of our new features this year that I think you’ll love. We’ll be covering three main topics, enhancements to the merchant and payment experience, improvements on sharing orders with your customers and some great new capabilities coming to the FinanceKit API.

But first, let’s take a look at the merchant experience. We’ve continually sought more ways to improve the Apple Pay customer experience from streamlining payments to offering a multitude of ways for merchants to engage with customers beyond the purchase. And this year is no different.

We’re introducing a new and improved design for the Apple Pay button, a new way to view preauthorised payments, and a way for merchants to provide rich information to help your brand stand out. It’s been a decade since we launched Apple Pay and ever since then, users have looked to it for secure, trusted, and reliable payments. Now, I’m sure you’re all familiar with this: Customers love the easy checkout experience it brings, simplifying the process and letting them skip straight to the purchase. We wanted to bring an even better experience to merchants and customers alike, so this year, the Apple Pay button gets dynamic. Let’s have a look at it in action. When using your app, relevant customers may see their default payment method with their card art on display. The new button will help engage customers and bring them into the Apple Pay experience, making checkouts easier and faster than before. For the button to show the best card for the purchase, provide a Merchant Category Code and the supported payment networks as part of your payment request and pass it in to the button’s initialiser. If the default card is unavailable for a transaction, the next available card is shown instead.

As a refresher, a Merchant Category Code is one of a list of industry-standard, pre-defined codes that represent the various types of commerce a merchant can engage in. It lets customers know in advance whether a payment method is supported for your transaction, helping them choose the right one and avoid pesky failed payments. You can easily set a Merchant Category Code for payment requests both in-app and on the web, so, let’s see how that’s done. Here we have an existing in-app PKPaymentRequest that we’re going to add a Merchant Category Code to. We already indicate what payment networks are supported by the transaction using the supportedNetworks and merchantCapabilities properties. Cards using payment networks not in the supportedNetworks array are marked as unavailable, while merchantCapabilities can be used to specify which cryptographic protocols and card types are supported for the payment.

To allow these to affect which card is shown on the dynamic Apple Pay button, make sure to use an initialiser that takes a PKPaymentRequest. For Merchant Category Codes, all you need to do is initialise one with the relevant code for your business. and assign it to the merchantCategoryCode property. This one in particular refers to Pet Shops, Pet Food and Supplies. Now, you’re all set. Again, we encourage you to provide a Merchant Category Code whenever you create a payment request along with supportedNetworks and merchantCapabilities whenever it’s relevant, to enable the best experience for you and your customers. Anyway, let’s go back to the button. We prioritise user privacy and security, so just as before, card art and card details are inaccessible to apps that use Apple Pay.

SwiftUI and UIKit apps will adopt the new button for free, no extra development work required. However, if you did want to use the previous treatment, we’re adding a new view modifier to help with that.

Here we have an example Implementation of an Apple Pay button within an app. By default, the optimal appearance is chosen based on the users’ circumstances, but if you apply a payWithApplePayButtonDisableCardArt view modifier, the original button will always be shown. The modifier works on view hierarchies as well, so you can apply it to multiple views at once, or have it apply across the entire app. That was our update to the Apple Pay button. With that, we move on to our enhancements to merchant tokens and preauthorised payments.

We’ve created a unified view for preauthorised payments and, brought you more opportunities for customising your customers’ experience.

They can view all of their preauthorised payments in one place, and receive notifications about upcoming payments. Finally, you can now provide rich information to customise how you appear to users, and give them an engaging interaction with your brand.

Let’s see how this works. The new preauthorised payments view can be found in the Wallet app by selecting Payments from the new More menu, or via the card details view.

From it, you can see a list of every preauthorised payment and the merchants they’re from.

Now, let’s navigate into a merchant and see what it offers.

As you can see, the merchant presentation has been greatly improved. Before, you only had the merchant name as determined by the payment network. But now, you can provide an icon, a custom merchant name, a description and image for every payment, and more.

This will bring a much more engaging experience to your customers, helping them recognise your brand and understand their payments better.

You can also set your icon via Apple Business Connect, so, let’s take a look at that.

Apple Business Connect is a service that lets you register information about your business, such as your logo, name and email addresses. This lets you unify your brand by controlling how you appear in Maps, Mail, and more.

This provides a consistent experience to your customers wherever your brand appears across the system. To get started with Apple Business Connect, simply visit the website, register your business and fill in the details. Every entry is vetted by Apple, so customers have the peace of mind that your brand, is your brand. Next up, oop, looks like I just got a notification. Ah, my sock subscription is about to renew tomorrow, so let’s tap it to view more details. As you can see, it brings me right to the relevant view within preauthorised payments with all the lovely branding provided by the merchant. From here I can see all of the information I need and can manage the payment if there’s anything wrong. After all that excitement, I’m sure you’re wondering how to implement it. Well, preauthorised payments is built on top of merchant tokens, a capability we released in iOS 16 that allows for more reliable charging of customers on an ongoing basis.

For more information on how merchant tokens work, and how to adopt them, check out our "What’s New in Wallet & Apple Pay" talk from WWDC22. To enable rich merchant information for preauthorised payments, you’ll need to vend a bundle containing it from a bundle-vending endpoint. That endpoint is part of a Merchant Token API implemented on your servers that will be reached out to by your customers’ devices, using information that you provide. Let’s go through a brief overview of the web service flow and then take a closer look at how to construct and deliver a merchant token usage information bundle. Before starting the flow for any tokens, generate and persist a Merchant Public Private key pair. This will used be as part of the encryption for every bundle across all of your customers.

When starting a flow, first fetch a Merchant Token Public Key from the Apple Pay server. Then, combine the fetched Merchant Token Public Key with your generated Merchant Private Key using HPKE in auth mode to make a derived encryption Key.

Now generate an Authentication token and encrypt it along with your Web service URL using the derived encryption key to form your encrypted metadata. The web service URL is the base URL for your Merchant Token API implementation and the authentication token can be any value you want, but, it must be secure, private and unique to each customer, because you’ll use it to validate the originator of requests. Finally, take your encrypted metadata, your generated Merchant Public Key and additional encrypted metadata, create a Merchant Token Usage Information Package Availability Notification and send it to the Apple Pay server.

From there, the customer’s device will reach out to the merchant token usage information endpoint implemented on your server, substituting in the identifier of a merchant token you’ve provided.

Your endpoint will return a merchant token usage information package, encrypted using the Merchant Token Public Key, fetched from the Apple Pay server.

The package itself should be a zip file containing a usage information JSON file, a merchant logo, product images, and optional localization information. Be aware that each usage information package has a maximum size of 5MB, so keep in mind the size and compression of your images.

For more details on the web service flow, specification of the response format, and the encryption requirements for the package, visit the developer documentation.

Let’s take a closer look at the Merchant Token Usage Information Schema. While there are many parts to the schema, here we’ll focus on the most important fields. merchantTokenIdentifier must match the identifier of the merchant token for which you are providing the usage information. merchantName is the name or localization key for the merchant, and merchantLogoName is the file name of an image within the package. upcomingPayments and pastPayments lets you provide details about the various payments a customer has with you, including descriptions, amounts, line items, and more. If you do not provide Merchant Token Usage Information, customers will only see the default merchant name that comes from the payment network. As you can see, the difference is night and day.

As always, this data is private and secure.

All merchant token information is end-to-end encrypted between you and the customer’s device. This is so that nobody else not even Apple can see any preauthorised payment information. That was the enhancements coming to to the merchant and payments experience. With it we’ve brought you a fresh new Apple Pay button and a great way to control how customers interact with your brand in Wallet. Now, let’s see what’s coming next for order tracking. Since iOS 16, you’ve been able to track orders from supported merchants, right in the Wallet app, featuring automatic notifications, realtime updates and integrated management features. This has helped customers stay informed and up to date with their purchases, easing the support burden on merchants and reducing missed deliveries. Currently, there are three ways to provide an order to your customers: implement it as part of your Apple Pay flow, provide an order bundle as an email attachment or, place an add order to Wallet button in your app.

These have been great for users and merchants alike, so we wanted to streamline that experience even more with the addition of an automatic order tracking feature. Using the power of Apple Intelligence, Wallet can now securely and privately detect order emails in the Mail app, automatically convert them into Wallet orders, and add them to Wallet, letting you view all of them together in one place. This makes it even easier for everyone from small businesses to large retailers to get in on the action.

Relevant emails from delivery companies will be also be linked to orders, ensuring customers get the most up to date information about their deliveries. Let’s take a look at an example.

Here, we have a delivery confirmation email from a merchant and its corresponding order, ingested into Wallet.

As you can see, the merchant name, delivery window and tracking number have been detected and placed into the corresponding order fields.

All emails related to the order can be viewed and opened from here as well.

Getting your order information in the right place is important, so let’s look at how you can optimize the process.

To ensure an optimal user experience, make sure you’re including all of the important order information in your emails. This includes a merchant name in the email body, an order number in every email and, a tracking number to link any carrier emails to the order. Also, verify your orders are appearing with the correct data by going through the ingestion flow with a test email and opening them in Wallet to make sure everything’s working as expected. However, if you wish to further enhance the experience, there are a few things you can do. As with preauthorised payments, your logo and other merchant details can also be set via Apple Business Connect. This will set the logo and merchant name across all of your email orders. For the best experience with order tracking, make sure to register any email addresses used for order confirmations or other related interactions. Automatic order tracking is slick, but if you want to provide information beyond what fits in an email, you can still attach an order bundle, or, set a webServiceURL on your web and in-app payment requests.

This offers the full suite of features including emailless order updates, integrated receipts and returns and an easy way to direct users to download or open your app. That was our new automatic order tracking feature coming to Wallet and Mail.

To get started with that or any of our other order tracking features, visit Apple Business Connect, or, read the documentation for Order Tracking bundles and check out "What’s new in Wallet and Apple Pay" 2023 for FinanceKit’s Order Tracking API. Speaking of FinanceKit, we have some exciting new functionality coming this year that’ll enhance your apps capabilities and help you bring a whole new set of features to your users. But first, let’s have a look at a new expansion to the FinanceKit market. Since the release of the FinanceKit API in iOS 17.4, we’ve loved seeing all the ways developers have been able to use them with Apple Card and Apple Cash.

That year, we also launched Connected Cards in the UK, utilising the Open Banking Standard to allow users to see all their transactions right on their devices. So this year, we’ve brought the two together and made the FinanceKit API available in the UK.

Your finance apps now have access to a whole new market, expanding your reach and increasing your potential user base. As always, we’ve made no compromises on privacy and security. Users can control which apps have access to their data and, how much data each app can access, exactly the same as before. If you’re unfamiliar with FinanceKit, it allows apps to query financial data stored on the device, including accounts, account balances and transactions. Data can be accessed either through individual queries or, received over time via an AsyncSequence. For more information on how FinanceKit works, check out "Meet FinanceKit" from WWDC24 or, browse the developer documentation.

Now onto the new FinanceKit API, background delivery.

There are many great ways to use the FinanceKit API, so we wanted to build on that and bring you an easy way to utilize it outside of the regular app life cycle.

This comes in the form of a new extension type that you can add to your app a background delivery extension.

When you create one, your extension will be notified whenever data changes in the finance store and it can process that information, however you like.

This happens regardless of if your app is running or not, making it easy to do things, like update a widget as users shop or produce regular spending reports on-device. Now, let’s take a look at how a background delivery extension works and how we can add it to an existing app. Here we’ve got our simple spending tracker already set up with FinanceKit, to which we want to add a widget so our users can more easily keep on top of their spending habits.

As it currently stands, the app interacts with the finance store, calculates our spending total and writes that into persistent storage, using it to update the app’s UI.

Adding in our widget, we now need to move our data store into an app group to allow it to be accessed across all of our targets. Currently, the app is needed to trigger a widget update whenever its stored data has changed, which the widget then reads from the app group or receives via an AppIntent. However, by adding a background delivery extension to our project, we can decouple our widget’s updates from our app and tie it more directly to the finance store itself, letting it independently update in the background.

Our background delivery extension will be notified when changes occur in the finance store and calculate an up-to-date spending total, which it saves to storage. It then triggers a widget update in the same way as our app, causing the widget to read our data and display it, no app code required.

Let’s go through the extension’s API, then implement it to power our widget. There are two endpoints that need to be implemented in your extension: didReceiveData and willTerminate.

didReceiveData is the entry point of the extension and receives an array of BackgroundDataType, indicating which types of data in the FinanceStore have changed. These data types are directly equivalent to the queryable FinanceKit data types: Accounts, AccountBalances and Transactions.

When the extension returns from didReceiveData, its work is considered finished and the extension will close.

Your extension has a limited time window in which to operate and you are expected to write your extension with that in mind. willTerminate is called when your extension has reached the end of its time window and it gives an opportunity to gracefully stop and save any ongoing work. Now for some example code. From within didReceiveData, you can use the FinanceKit API to query and process data from the FinanceStore.

We know our extension will only be called if transactions have changed, so we query all transactions since the start of the week and total their amounts.

Once that’s done, we add it to our store, update our widget and exit the function. If our extension is about to terminate, we save the changes we’ve made to the store so far.

This isn’t as important in a simple example like this, but it’s crucial to avoid data loss if you’re processing large amounts of data at once. Now, let’s see what we need to do, in our app.

All our app needs to do is indicate to the FinanceStore which data types we want to receive updates for and at what frequency we want to receive them. We have the option to enable delivery for data types, disable delivery for them or disable delivery for all data types. Subsequent calls with the same data types will update their values accordingly.

Every data type can have one of three update frequencies: hourly, daily, and weekly.

These represent the expected minimum Interval between extension launches and, if no data changes, your extension won’t be called. For example, if you select an hourly window, your extension may be called right after data changes, but if data changes within the subsequent hour, your extension won’t be called again until that hour has elapsed. If more than an hour has passed since the last extension call, your extension will be called the next time data changes. The window of time for your extension to process data is larger for longer update frequencies, so make sure to choose an appropriate one for your use case. Here, we have an example of a more complex app that fetches all of an account’s transactions when the account is connected to FinanceKit, then processes further transactions, as they come in.

Before it can enable background delivery, it needs to request authorisation from the user to access their accounts’ transactions. Authorizations made in the main app are inherited by the extension, so you only need to worry about it once.

The app then registers for transactions with an hourly frequency and accounts with a daily frequency.

This means that by checking the types passed to didReceiveData, the extension can utilize a longer window to fetch and process historical transaction data when an account is added, but stick to more frequent updates when new transactions appear. Now we’ve created our extension, let’s go to Xcode to finish off our app.

Our app’s category is set to Finance and we’ve already set up a Financial Data entitlement through the developer website, so we’re authorised to use FinanceKit. That Financial Data entitlement has been added to both our app, and our background delivery extension so they can access the FinanceKit API. The last step is to add our widget. Go to File, New, Target, and select the Widget Extension template from the list. Now that’s done, we can add in our widget code and make sure it builds.

Looks like it’s good, so let’s install it to our device and see it in action! Our app needs to run once to make sure everything’s enabled, but after that we can add our widget to the home screen. Now we’ve set up our app extension and widget, we can go buy something and watch it work its magic.

I haven’t eaten today, so let’s grab some food.

After I’ve made a purchase and the transaction comes through from the card issuer, we can see our widget is now showing our updated weekly spend. Ouch! And widgets are just the beginning. We can’t wait to see all of the awesome features you create, leveraging the power of background delivery! That brings us to the end of FinanceKit, and the end of our presentation today.

That’s been What’s new in Apple Pay. We’ve covered lots of great features that you can use to enhance everything from your customers’ experience to your app’s features and capabilities.

To unify your brand presence in preauthorised payments, extracted orders and more, visit the Apple Business Connect website and register today. If you want to provide rich merchant information and more in preauthorized payments, take a look at the documentation and check out WWDC22 "What’s new in Wallet & Apple Pay" for a merchant tokens refresher.

To start providing your customers with the best orders experience, register your email addresses in Apple Business Connect and double check your orders’ information appears as expected in Wallet. Or, integrate order tracking bundles into your purchase flow to offer detailed information and functionality that extends beyond the email. To get started with background delivery, you can dive right in from Xcode or check out WWDC24 to get your hands dirty with FinanceKit. Thank you all very much for watching! Cya!