What’s new in Wallet and Apple Pay

♪ ♪ David: Hi, and welcome to "What's new in Wallet and Apple Pay." My name is David. Jon: And I'm Jon. David: Today, we'll talk through all the new features and enhancements we're introducing this year to the Wallet and Apple Pay experience. Wallet and Apple Pay encompasses a wide range of features and functionality, barcode passes, transit cards, car keys, and more. These are all important parts of our ecosystem, but today's focus will be on three areas: Payments, Order Tracking, and Identity. Let's start with Payments.

We'll first talk about Apple Pay Later and how you can integrate merchandising support for it within your platform. We'll talk about some enhancements to preauthorized payments and then walk through a brand-new API to support transferring funds with Apple Pay. Apple Pay Later was introduced earlier this year to customers in the United States and allows users to split purchases into four separate payments. Users can then conveniently track and manage these purchases within Wallet. While Apple Pay Later does not require any integration, we're introducing a new API that provides a dedicated merchandising view for inclusion within your UI. Using this view indicates support for Apple Pay Later, and details the experience a customer can expect. You'll have the ability to customize the style of the view to better suit it for the context it's displayed in. When a user selects this view to learn more, you have a choice of how Apple Pay Later is explained. And this view will be available to developers for both apps and on the web.

The merchandising view can be rendered in four different display styles, depending on context: The standard style, which briefly describes how Apple Pay Later can be used to split a purchase into multiple repayments. A badge style, indicating support in a concise way. A checkout style, designed to be placed alongside other payment options in your checkout flow. And a price style, for use alongside the total purchase price. When a user interacts with this view, they will be presented with more information. As a merchant, you have the ability to choose between two different actions. The "Learn More" action will present an overview of Apple Pay Later and explains the experience a user would go through if they select it as a payment method. The "Calculator" action will still present an explanation of Apple Pay Later, but with a focus on the repayment schedule the user would need to follow. Let's take a look at incorporating this view within your app.

Firstly, you'll want to check whether the user is eligible to use Apple Pay Later. You can use the validate function within PKPayLaterUtilities to do this. You'll need to provide the amount for the transaction, as well as the locale required. Once you've determined whether the user is eligible to use Apple Pay Later, you instantiate a PKPayLaterView, with the same details provided for the eligibility check. If you wish to customize the style and action of the view, you can do so by changing their respective properties.

We also provide a convenient SwiftUI view, that allows you to express Apple Pay Later acceptance within your SwiftUI apps. To use it, you instantiate a PayLaterView, and provide it with the same information as before. To customize the display style and action, use the appropriate view modifiers to do so. And it's as simple as that. If you want to support the merchandising view on the web, there are a few setup steps you will need to perform first.

The API for displaying the view is provided within the existing Apple Pay JavaScript SDK, but there are some new attributes you may need to set when including it. It's important to set the crossorigin attribute if you're required to support Cross Origin Resource sharing requests. Use the async attribute to ensure the script loads and executes independently from your page's loading progress. And lastly, a JWT is required to authenticate requests to the API. This token can be generated on the Apple Developer portal. Using the JavaScript SDK couldn't be simpler. Use the apple-pay-merchandising element to represent the view. The amount, country code, currency code, and locale are required fields.

Just like the native API, you can also customize other aspects of the view as required. Here are some best practices to follow if you're incorporating the Apple Pay Later merchandising view. For apps, an entitlement is required to use this view. This can be obtained on the Apple Developer portal. For websites, remember to register your domains and obtain a JWT for use when including the SDK. This can also be done on the Apple Developer portal. Where possible, try to import the SDK within the head element. This will allow it to run as soon as possible, so the merchandising view is ready for when your page has fully loaded. The size of the view can be customized for your needs, but ensure that you follow the sizing requirements. And lastly, if your website has a restrictive content security policy, follow the recommended guidelines to ensure the SDK can be loaded across domains. And that's a look at Apple Pay Later. Next up, we'll talk about preauthorized payments. In iOS 16, we introduced preauthorized payments. Users are able to view and manage payments they've preauthorized in Wallet, and merchants are able to charge the user according to the agreed terms. We initially provided support for recurring payments and automatic reload payments. We now also support deferred payments. All three preauthorized payment types are available for use in apps, as well as on the web. Deferred payments allow you to charge either a fixed or variable amount at a particular date in the future. If you have a free cancellation cut off date, you can specify this as part of the request as well. Examples where deferred payments may be suitable include when a customer is booking a hotel reservation or when they are pre-ordering an item.

Preauthorized payments take advantage of Apple Pay merchant tokens.

They are tied to a user's Apple ID, rather than an individual device. This means for example, if a user were to upgrade their device, the token would still be valid for use. Because of this, you will still be able to use the token to charge their account, making receiving payments at a later date more reliable. When performing a preauthorized payment, merchant tokens are automatically issued if the customer's payment card supports them. If the payment card doesn't support merchant tokens, the transaction will still go through but will use the traditional Apple Pay token that is tied to an individual device. To learn more about Apple Pay merchant tokens, check out last year's What's new in Wallet and Apple Pay. So let's take a look at how to incorporate deferred payments within your app. First, we create a PKDeferredPaymentSummaryItem, which outlines a description of the charge and the amount that will be taken. You also set the date for when the payment will be taken.

Next, we create a PKDeferredPaymentRequest. We provide it with the summary item we just created, along with other information regarding the management of the payment. If we have a billing agreement we need to display to the user, this can also be set on the deferred payment request. Once we have the request created and configured, we can then attach it to our PKPaymentRequest.

For the payment summary items on our request, we create another PKDeferredPaymentSummaryItem with the same amount and date as before. But this time with a label representing the name of the merchant. We set this on the request, and we're ready to present for payment.

As can be seen in this example, the Apple Pay payment sheet will present the deferred payment to the user with information on the billing agreement and when they can expect to be charged. Now, there are some important considerations to make if you specify a free cancellation date.

When you provide a free cancellation date, you are stating that any cancellations before that point in time will be done with no charge to the user. Because of this, both the date and time are important pieces of information. You need to explicitly state the time zone the cancellation policy applies in. We have provided a separate property to support this. In the example below, we have specified that the time zone is Pacific Standard Time. This is important because your customer's time zone might not match the cancellation policy's time zone. For example, when someone is based in the United Kingdom, booking a hotel in the United States. When working with deferred payments, here are some best practices to follow.

As mentioned previously, if you need to describe a free cancellation policy, carefully consider the date, time, and time zone provided to the deferred payment request. Remember to include the deferred payment within your summary items, and ensure you set the appropriate merchant name. This is not done for you automatically. When providing a billing agreement, remember to keep it short. The billing agreement text should only act as a summary of key facts to consider and should not replace any normal billing or legal agreements in place. Lastly, specify a token notification URL, so you can be kept up to date with lifecycle events of the Apple Pay merchant token if one has been issued. And that's deferred payments. Next, let's take a look at a brand-new way to transfer funds with Apple Pay. Traditionally with Apple Pay, the payment sheet has always been available for users to add funds to an account. New in iOS 17, we're introducing Transfer Funds with Apple Pay.

This offers the ability for users to transfer from an account to a card in their Wallet, completing the lifecycle for money movement. This uses the same secure and private Apple Pay infrastructure as payments, meaning customers will already be very familiar with the process. An example where transferring funds makes sense would be allowing a customer to withdraw funds from a bank account or a stored value account. To support Transfer Funds with Apple Pay, we have created a new request type that focuses on just the information required for a funds transfer. To use it, you simply define an amount you wish to be transferred to a user's payment card. If you require the contact details of the recipient, you are also able to request these. If you've used PKPaymentRequest before, this new API will feel very familiar to you. Because Transfer Funds with Apple Pay works on the same infrastructure as payments, you will need to register as a merchant within the Apple Developer portal.

To learn more on how to register as a merchant and get set up to use Apple Pay, check out our "Implement Apple Pay and order management" Tech Talk. To give you an illustration of how Transfer Funds with Apple Pay works, let's take a look at an example. Say we have a customer, Andrew, who wishes to withdraw money from their account. Using Transfer Funds with Apple Pay, they would trigger a transfer from within your app. Your app then creates a request, outlining the amount to be transferred. Andrew will then be presented with the Apple Pay sheet detailing the transfer, allowing them to select the card they with to receive funds to. Once Andrew securely authenticates the transfer, an encrypted payload is generated and returned to your app, ready for processing with your payment provider. Once the transfer has been processed, your app will then return the result to Apple Pay. If the transfer is successful, that's it. If an error has occurred, Andrew would be informed and may be able to take corrective action to fix the issue. Now that we've seen an overview of how a funds transfer works, lets take a look at how to implement it within your app. We first need to determine which networks and card capabilities we wish to support. Next, we'll check to see whether the user has an eligible card to initiate a funds transfer. This is done through PKPaymentAuthorizationController. Using the supportsDisbursements method, we provide the networks and card capabilities defined earlier. You can use the result of this check to adjust your user interface as appropriate. Now that we've checked for eligibility, we can start building our transfer request. Similar to payment requests, the amounts are defined through summary items. In this case, we create two different summary items. The first is a PKPaymentSummaryItem. This represents the amount being withdrawn from the user's account. It's important to note that the label associated with the item, should be the name of your business. The second item is a new type of summary item, a PKDisbursementSummaryItem. You must include one of these, and it should always represent the final amount received onto the recipient's payment card, net of any fees, charges, or adjustments. Whereas for payments, we have PKPaymentRequest, we have a new request type for Transfer Funds with Apple Pay, PKDisbursementRequest. In order to construct a PKDisbursementRequest, you need to specify certain details. It requires the merchant identifier you set when registering for Apple Pay, the currency of the transaction, the region of your business, as well as the networks and capabilities defined earlier. You also provide the summary items you just created. If you require the contact details of the transfer recipient, you can request those here as well. You can also limit which regions the recipient's payment card has been issued in.

Once the request has been built, we can now present it to the user. We do this by initializing an instance of PKPaymentAuthorizationController with our disbursement request. We set ourselves as a delegate, and then present.

As can be seen here, the user is presented with the option to select the payment card they wish to receive the transfer to and the amount they will receive to that card. Now, once the user securely authorizes the transfer to take place, there are some delegate callbacks that will need to be implemented to process the transfer. There are only two delegate methods that are required to be implemented to handle Transfer Funds with Apple Pay. The first is paymentAuthorizationControllerDidFinish. This will be called when the sheet is ready to dismiss. The responsibility is on the calling app to dismiss it. You can also use this method to change your own app's UI accordingly. Secondly, is the didAuthorizePayment delegate method. Because Transfer Funds with Apple Pay uses the same infrastructure as payments, you'll receive the same type of PKPayment object to use for processing. Here we've abstracted the processing of the token away into our own processFundsTransfer method. Depending on the result of processing, you would either return a success or failure.

If during the processing stage there are errors encountered, we have provided a set of convenience methods to represent these. You can use disbursementContactInvalidError for when there are issues relating to the contact information provided. If your payment processor determines that the user's payment card is unable to accept fund transfers, you can use disbursementCardUnsupportedError. Some financial institutions support instant funds transfers, where funds can be sent to the recipient more quickly. These can also be represented with Transfer Funds with Apple Pay. Depending on the service, these instant transfers can sometimes include fees, which can also be represented. Typically, a user will be given a choice of transfer speed within your app. When a user chooses to transfer funds instantly, provide the capability to require support for them. When doing so, the user's choice of cards will be limited to those that are known to support instant transfers.

And this is what an instant transfer would look like.

The sheet looks very similar to before, but now we highlight the fact the transfer is instant, as well as any fee the user will be paying. The transfer amount has also been adjusted to take into account the fee. Let's see how to make the previous transfer request an instant one. Firstly, we add instantFundsOut, to our list of supported capabilities. We can then check within supportsDisbursements whether the user has any cards that support instant transfers. You can then adjust your transfer method options and user interface accordingly. As for summary items, we have a dedicated item to represent instant transfer fees, PKInstantFundsOutFeeSummaryItem. With this item, you specify the amount that will be charged for the purposes of performing an instant transfer. Even if you don't charge a fee, this summary item is still required. In this case, you would set an amount of zero. Because in this example, we are charging a fee, we need to update the disbursement amount accordingly. This won't be done automatically for you. Creating the PKDisbursementRequest isn't too different from before. The only difference is to ensure you provide the capabilities and summary items defined earlier. And that's all that's required to represent an instant transfer. Here are some best practices to keep in mind when implementing Transfer Funds with Apple Pay.

Note that Transfer Funds with Apple Pay is only available for iOS and iPadOS, and is unavailable for use on macOS or the web. If an error were to occur during the processing of a funds transfer, use one of the dedicated disbursement errors in order to communicate this to the user effectively. It's important to note that the first summary item should represent the amount that will be withdrawn from the user's account. The label of the first summary item should match that of your business. And the last summary item must represent the amount that will be received by the user's payment card, net of any fees, charges, or adjustments. And that's everything we have today regarding payments. To change tracks a little bit, let's talk about Order Tracking. Order Tracking was introduced in iOS 16 as a way for users to track orders placed with participating merchants. The response from users has been fantastic, and we have been hard at work making Order Tracking even better. We'll talk about how we've improved integration within the operating system to better represent and communicate orders. We'll then go through some enhancements we've made to Order Tracking. And lastly, we are introducing new ways to add Orders to Wallet. In iOS 16.4, we added support for sharing orders through Messages, providing an inline preview of the order, and the ability for the recipient to track it within Wallet. We also introduced an Order Tracking widget, where users can keep a track of orders at a glance. Users can already benefit from these new features without any additional work needed. We are continuing with system integration in iOS 17 with support for Maps. If a user is tracking an order with a specified pick up time and location, Maps will proactively suggest it through Siri Suggestions. Now let's take a look at some of the enhancements we've made to Order Tracking in iOS 17. To better support courier and food delivery use cases, you can now indicate the type of shipping being used. Through the new shippingType property, you can declare whether an order is being shipped or delivered.

We now have better support for associated applications, including enterprise apps. By declaring your associated application identifiers, you can improve the management of order notifications between your app and Order Tracking. In addition, we support custom product page identifiers, enabling a deep-link to your App Store product page most relevant for Wallet traffic.

Lastly, we are introducing new ways to represent payment information. Order packages now support an array of transactions associated with it, with each having its own detailed information, such as payment method and amount. You can also attach receipt files to transactions, so your customer has a record of payment. This receipt file can either be a PDF or an image such as JPEG or PNG. Keep in mind that order packages are limited in size, so be considerate for the size of the receipt files you include. You can now also describe whether a transaction is for a purchase or a refund. With iOS 17, adding Orders into Wallet has never been simpler. You can now attach order packages to emails, such as the order confirmation email. The user will then be able to add the order to Wallet right then and there. In addition, you can also add a “Track with Apple Wallet” button within your apps and websites. Let's take a look at the new Order Tracking API that supports adding orders to Wallet. This API is included within two new frameworks, FinanceKit and FinanceKitUI. These two Swift exclusive frameworks will allow developers to handle order data within Wallet. Access to order information is achieved through a shared instance of FinanceStore, providing a central resource for handling order tracking queries. With this API, you will be able to check for the existence of an order, as well as a way to add or update an order. Let's take a look at how you check for an existing order. You first query the FinanceStore to check whether it contains an order with a fully qualified order identifier. You will then receive one of two responses, either it exists, or it has not been found. You can then respond in your app as appropriate. It's as simple as that. If you want to add or update an order, you can do this in one of two ways. We'll first show how you use FinanceKit to do this. You will first need a Data serialization of the signed order package you wish to add to Wallet. You then provide this to FinanceStore's save order method. When you do this, a screen is presented to the user to verify the order's contents and whether they wish to track it within Wallet. Once a user has either confirmed or denied the request, you will receive the result asynchronously, and it can take three forms. Either they've added the order to Wallet, they cancelled the request, or a newer order already exists. If your app is written with SwiftUI, you can use FinanceKitUI. This provides a dedicated "Track with Apple Wallet" button and allows you to process the result of adding the order. Like with FinanceKit, you will first need a serialized instance of your signed order package. You then include AddOrderToWalletButton within your view. When a user selects this button, they will be offered the ability to add the order to their Wallet. You are then able to respond to the three results states, just like before. For merchants who want to support customers tracking an order on the web, we offer a version of this button in the JavaScript SDK. To use this, you insert an apple-wallet-button and configure it using attributes. The type of button should be set to track-order. When using this button, it's important to set the onClick callback to point to the location of the signed order package you wish to add. And that's what we have for you today on Order Tracking. We can't wait for you to adopt these new APIs in your apps and services. And now for something completely different, we have some exciting updates to share regarding Identity, and for that, I'll hand over to Jon. Jon: Thanks, David. Hello again. I'm Jon, an engineer on the Apple Pay and Wallet team. I'm so excited to talk about the new functionality we've added for Identity in iOS 17. We introduced IDs in Wallet back in iOS 15.4, enabling users in supported U.S. states to add their driver's license or state ID to Wallet. Last year, we introduced Verify with Wallet. With this API, businesses can streamline their onboarding and account verification flows by requesting information from a user's ID stored in Apple Wallet. This year, in iOS 17, we're introducing Tap to Present ID on iPhone.

With this API, your apps can seamlessly and securely verify IDs in Wallet or other mobile driver's licenses using just your iPhone. This builds on top of the Tap to Pay on iPhone API, which we added to the ProximityReader framework in iOS 15.4. Tap to Pay on iPhone provides a secure, private, and easy way to accept contactless payments without the need for additional hardware or payment terminals. Now, let's take a look at Tap to Present ID in action. Suppose I work for Spaceship Rentals and that David would like to rent a spaceship from us. He needs to be at least 21 years old to do this, so I'm going to perform an age verification using Tap to Present ID. First, the Spaceship Rentals app invokes Tap to Present ID.

My iPhone will show the business' name, logo, and the type of request being performed, in this case, proof of age. I'll now invite David to hold his iPhone near mine.

David: My iPhone now displays a consent sheet that I can review. I can see that I'm presenting my ID to Spaceship Rentals, and they are requesting my ID photo and whether I'm over 21. I'm willing to present this information, so I'll double click and confirm with Face ID.

Jon: My iPhone now shows the information David presented. I see that he matches his ID photo and that he's over 21. So now he's ready for takeoff.

I've just successfully verified David's ID using the Tap to Present ID API. This experience offered some key benefits compared to checking a physical ID.

First, the ID information itself is verified. Unlike physical IDs, which are susceptible to tampering, mobile driver's licenses are cryptographically signed by the issuing authority, and iOS verifies the signature, so you can trust the response. Second, the experience was wireless and secure. At no point did David need to hand over his iPhone to me or even unlock it, and the data was sent securely using NFC and Bluetooth.

Finally, this is a more private way to verify an ID. David only needed to share the information necessary to verify his age, unlike with a physical ID, where everything is shared. Let's talk about the types of requests you can perform with this API. We just demoed the display request. This is suitable for when you need to verify a person's name or age. The result is shown in the system UI, and no ID information is returned to your app.

The API also supports data requests. These can request a wider set of document elements, such as address, date of birth, and driving privileges, and the result is returned to your app to process. To perform data requests, your app will need an additional entitlement. Check the documentation for more information.

Now, let's have a look at how to implement this in code, starting with a display request.

First, use the isSupported class property on MobileDocumentReader to check whether the current device supports this API. If it does, instantiate a reader object and call its prepare method.

This will return a MobileDocumentReaderSession object. Next, create a driver's license display request with the elements you want to verify. Here, I'm verifying whether the holder of the driver's license is at least 21 years old. Then call requestDocument on the session, passing in the request. The reader UI will then be shown, first prompting the ID holder to present their device, and then displaying the result of the request.

Keep in mind, as this is a display request, nothing is returned from the requestDocument method. And with just a few lines of code, you've added mobile document reading capability to your app.

By default, the name and logo of your brand isn't displayed on either the reader iPhone or ID holder's device. However, if you wish to display your brand information during a document request, you can. This can be configured through Apple Business Register and with a few more lines of code. To show your brand information during document requests, you'll need to pass in a reader token when preparing your device. You'll need to create this token on your server. A reader token is a JWT, signed with a key pair you've configured through Apple Business Register. Your server will create the reader token with your brand ID, key ID, and a reader instance identifier. The brand and key IDs can be obtained through Apple Business Register and are the same across all instances of your app. Your app will provide the reader instance identifier to your server.

Back in the code, your app will fetch the reader instance identifier from MobileDocumentReader's configuration object and send it to your server in exchange for a reader token. Pass this token into the prepare method to obtain a reader session. Then create a request and call requestDocument just as before. And now your brand's name and logo will be displayed on both the reader iPhone and ID holder's device. And that covers the display request. So far, we've looked at how to prepare a session, request a document, and how to use a reader token to show your branding information. Now let's look at how to perform a data request. These requests support a wider range of document elements, and the API returns the result to your app, instead of just displaying it.

To use this request type, you'll first need to prepare your device with a reader token, just like before. Then create a driver's license data request, specifying the document elements to be requested and whether you intend to retain the information.

Calling requestDocument will show the reader UI just like with the display request, but once the read has completed, the UI is automatically dismissed. The response is then returned to your app to process. And that's Tap to Present ID on iPhone, an exciting new API we've added to the ProximityReader framework. And now, back over to David. David: Thanks Jon! So what have we learned today? We've taken a look at enhancements to payments with support for Apple Pay Later and new use cases. Order Tracking's new APIs allow you to add Orders to Wallet from within your apps and services, and there's a new way to verify mobile driver's licenses with Tap to Present ID on iPhone. To wrap up, if you're a business, consider enrolling on Apple Business Register. This will help enrich the Wallet and Apple Pay experience for your customers. You can visit the Apple Developer forums, where you can ask questions and get help all year round. And lastly, if you have any feedback, we'd love to hear from you. You can do this by using Feedback Assistant. And that's it. We hope you've enjoyed this session. both: Thanks for watching. ♪ ♪