What’s new in Wallet and Apple Pay

Hi, and welcome to "What's new in Wallet & Apple Pay". My name is Tanya. And I'm Masha. Today, we'll talk through all the new features and enhancements we're introducing this year to Wallet and Apple Pay. In past years, you've seen new features like Apple Pay Later and order tracking and updates to make existing features even better for developers.

This year, we'll focus on updates to using Apple Pay and upgrading the user experience for ticketing. The first payments update today is for Apple Pay on the web. You already know that Apple Pay is the most seamless, secure and private way to pay in-store, in-app and on the web. With iOS 18, you'll be able to improve conversion performance and extend the Apple Pay user experience to any device with a browser, including those outside the Apple ecosystem. Users on iOS 18 will be able to use Apple Pay on any non-Safari browser by simply scanning a code with their iPhone to securely and privately complete the payment. After just a few small code changes, you'll see how this new transaction flow works.

To make this update as simple as possible, you'll just need to check two items in your code. First, make sure you import the Apple Pay JavaScript SDK or update your existing version to 1.2.0 or higher. It's recommended to place this in the head tag of your HTML document to ensure that Apple Pay is ready to go as soon as your page loads. If you want to test your integration, refer to the link developer docs regarding beta testing.

Next, it's important that you use the JavaScript SDK Apple Pay button instead of the CSS implemented variant. Using this component, will ensure that non-Safari browser support works. You can check the link to developer docs for more details on how to display and customize the Apple Pay button.

One more thing to note about this feature is that canMakePaymentsWithActiveCard() is being deprecated in favor of the new applePayCapabilities() API. If you've used browser or user agent detection in the past to determine whether or not to show Apple Pay on your website, this API provides a cleaner, universal solution to that problem. If you only use the canMakePayments() API today in your payment logic, you may continue to use that without further changes.

If canMakePayments() returns true, the Apple Pay button must always be shown. You should use the new applePayCapabilities() API if you want to prioritize or default the Apple Pay button on your checkout and product pages. For more accurate and detailed responses, the applePayCapabilities() call will return an object containing a paymentCredentialStatus key with one of the following values. The first value, paymentCredentialsAvailable, indicates that the device supports Apple Pay and has an active card on Wallet that qualifies for web payments. In this case, Apple Pay should be shown as the first payment option.

The second value, paymentCredentialsUnavailable, indicates that the device is capable of making payments, but there are no active cards in Wallet that can make this payment. So the Apple Pay button should not be shown.

The paymentCredentialStatusUnkown value indicates that Apple Pay is supported, but specific card information is not available, which will happen on non-Safari browsers or devices outside the Apple ecosystem. The Apple Pay button should still be shown here, but the ordering is left up to the developer.

The last scenario where the Apple Pay button should not be shown is when the paymentCredentialStatus explicitly says applePayUnsupported. More details about when and where to show the Apple Pay button can be found under “Acceptable Use Guidelines for Apple Pay on the Web” or the Human Interface Guidelines. Now to show you what this looks like in action, let's go to the pet store.

Here, you'll see the website for a local pet shop in Cupertino. Notice how I'm not in the Safari browser right now, and this is not a Mac. I'll just go to the checkout page...

...and once I click on Apple Pay during checkout, a scanable code will pop up on the screen. I'll just take out my iPhone and scan it with the camera.

Behind the scenes, this will use the same payment systems as a typical iPhone Apple Pay transaction. What this means is that you, as a developer, don't need to worry about the device or browser choices of your customer. And you will still receive the same payment response date as you would for a typical Safari web transaction. Any code you've previously written for Safari will now work on all browsers, no modifications required. I'll just double click to confirm.

And there you go. Transaction complete.

Now, for some tips and best practices. Like I mentioned before, it's important that you import the JavaScript file within the head tag so that it runs as soon as possible. Be sure to use the Apple Pay button provided in the JavaScript SDK. CSS implementations of this button will not support non-Safari browsers. If you've implemented Apple Pay using the W3C API instead of Apple Pay JS, keep in mind that not all browsers support the Payment Request API.

Finally, you should either use the existing canMakePayments() API or the new paymentCredentialStatus object from the Apple Pay capabilities API to determine when and where to display the Apple Pay button.

The next update for this year is an expansion of funds transfer capabilities to the web. You may recall this diagram from last year's presentation, where Apple Pay introduced APIs to add funds to an account. This year, with iOS 18 and macOS 15, funds transfers will be made available on the web.

As a reminder, you can use funds transfers to allow users to withdraw money from a stored value or bank account to any user card registered with Apple Pay. You'll need to check first with your payment processor to ensure that they support disbursements. If you're familiar with the Apple Pay on the web APIs, the disbursementRequest will function similarly to other types of PaymentRequest. The same rules apply as for funds transfer on iOS, which you can review in last year's “What’s new in Wallet and Apple Pay” talk. Now for a quick code example. Supporting a typical funds transfer doesn't require any new capabilities, as long as you have “supports3DS” in the capability list.

If you want to support an instant funds transfer option, you'll need to add "supportsInstantFundsOut” to your merchant capability list within the paymentMethodData. This will also allow you to specify any additional fees associated with instant funds transfer later on.

Since funds transfer does not involve shipping of any goods, make sure to set requestShipping to false in your payment options to avoid confusing users.

To build your payment request, you'll need to specify the disbursementRequest object inside the modifiers list.

You can optionally include requiredRecipientContactFields within the request to specify what information is needed from the user on the payment sheet. Even if you don't need requiredRecipientContactFields, an empty disbursementRequest object is still required to be present.

The additionalLineItems under the disbursementRequest object will follow the existing structure for payment requests. The first item is a summary of the total amount to be deducted from the user's account.

The second only applies to instant funds transfer requests, which specifies the fee for the transaction. The line item type should be “instantFundsOutFee”. Remember, even if you don't charge a fee for an instant funds transfer, this item should still be present, but with the amount set to zero.

The final item is the amount to be transferred to the user's card, where the item type will be "disbursement".

From a user perspective, this is what the payment sheet will look like for a funds transfer request. Users can select which payment card to transfer to and see the amount they'll be receiving on that card.

If you encounter an error in processing, you can use the ApplePayError object with an additional fourth field, which specifies the type of transaction the error applies to.

If your payment processor determines that the user's payment card is unable to accept funds transfers, you should use the unsupportedCard error.

If there is any issue relating to the user's contact information, use the recipientContactInvalid error.

Now, for the final payments update of today, support for Merchant Category Codes.

Merchant Category Codes are used to classify businesses by what type of goods or services they provide. Not all transaction categories are supported on a given payment card. Usually, this results in transaction processing failures on the merchant side. New this year, you can specify your merchant category code within a payment request. When you do, the payment sheet can make smarter decisions and show only valid payment cards to the customer, making your transaction more likely to succeed.

Apple Pay supports Merchant Category Codes that follow ISO standard 79450. If you're unsure what your business’ Merchant Category Code is, you can check with your payment processor.

Well, that's it for today's payments updates, but we're not done yet. Masha's got some really cool new ticketing updates to show you. Thanks, Tanya.

Let's talk about what's new with event tickets in Wallet this year.

We're introducing a richer ticketing experience, including visual upgrades to tickets in your wallet, a new event guide to access detailed information about your event, and stronger system integration with apps like weather, calendar, and more.

PKPasses can represent a wide range of events, including concerts, sports games, or longer running events, such as festivals and conferences. This year, we focused on improving the experience for the NFC event tickets representing these events. In order for your pass to receive the new treatment, there's a few requirements for the structure of your pass content.

First, the pass.json must provide a set of required semantically tagged information. Semantic tags are a form of machine-readable metadata, which helps the system better understand the data provided in the pass.

To read more about semantic tags, check out the links associated with this session.

Next, in order to specify whether you want passes rendered with the new style, add the preferred style in the pass.json.

Just like today, you'll need your pass to be signed with the NFC entitlement in order for ticket holders to be able to use their passes for contactless entry. Check out the Wallet developer site for more information on requesting this entitlement.

You should continue to include the required pass bundle content and consider including the newly introduced assets. Let's take a closer look at what could be included in the pass bundle.

Like before, a PKPass bundle needs the pass.json file, which contains the bulk of the pass content, along with an icon, logo and background image.

For these new tickets, we've also introduced an artwork asset and a secondaryLogo. Use the artwork asset if you want previous OS versions to continue rendering your pass with a strip image or the background asset if you want the same background on all OS versions.

Let's step through how each of these will be displayed on the pass.

On the top, you'll see the event logo or logo text. On the other side, we'll have a date and time of the upcoming event, which could be a single point in time or can span over several days.

These labels are strategically placed to give more focus and space to the event artwork, helping make each pass more unique and representative of your event.

Finally, at the bottom, we have a new footer used to display the primary seating information. PassKit will take into consideration the event and venue type, and display whatever seating information is most valuable. This footer will also display the secondary logo.

This new layout will enforce consistency across passes, making it easier for both ticket holders and ushers to quickly locate seating and entry information for an event. I'll walk you through an example of what's needed in the pass.json to create this pass.

The event start date and time is used for the labels at the top.

The seat dictionary is used to populate the information in the bottom footer, displaying up to four elements of entry and seating information.

For events spanning multiple days, such as music festivals, you can now provide a relevant time interval rather than a singular day.

If there's no assigned seat, an admission level can be shown in the footer instead, such as general admission.

Next, let's take a look at the new experiences that are provided below the pass. We've added a few new entry points to view more information about your event. First, there's a new maps tile which when tapped, will redirect users to the maps app and can provide easier access to navigation to the event venue.

And on the right, we've added an entry point to the new event guide.

The event guide provides ticket holders a space to view a range of information to better prepare for an upcoming event, along with quicker access to actions that might be useful during the event.

At the top, you'll see a set of actions that will link out to experiences in the app. These will provide users quick access to functionality like ordering food, buying merchandise, viewing a detailed bag policy, and more.

Below that, there's forecasted weather for the day and location of the event.

Next, there's space for additional venue details, which can include a venue map along with freeform queue label information.

The event guide can also include a link out to any relevant playlist. Let's take a look at what some of these changes will look like in the pass.json.

The semantically tagged URLs are used to create the tapable tiles at the top that link out to external experiences. The venue location provided using latitude and longitude coordinates will help drive the map's redirection and the weather experiences. If there is no coordinate location provided, we'll use the venue name to fetch the map's location.

For a concert ticket, including performer names or artist IDs will help support the music integration experience. For more information on how to find your artist ID, check out the associated links.

For other ticket types, we'll use the event name to check for any relevant curated music content to display.

Now, I'll go over some best practices for creating your tickets.

We encourage adapters to use semantic tags wherever possible. This will help surface past information in the event guide and the pass itself.

In order to make sure your ticket appears on the devices regardless of the OS version, make sure to still include the primary, secondary, and auxiliary fields in your pass.json as you would previously. If these fields aren't present, your pass will fail to validate or will appear empty on older OS versions.

Don't forget to specify the poster event ticket as your preferred style version to make sure your past renders with the new event style. I'll show you what that looks like next.

The poster event ticket represents the new ticket style I showed earlier. While event ticket represents the existing style, specify the order in which you would like PassKit to attempt to render your passes.

This pass includes the header and primary fields that are used to render the legacy ticket type for previous OS versions.

And below that, in the same pass, we have the semantically tagged data to render the new ticket style.

Finally, with just these changes to the pass.json, your pass will also start a live activity on iPhone and Apple Watch at the time the pass is deemed most relevant. The live activity will display the primary seating and entry information, making it easier for users to see the most important information directly on their lock screen or smart stack.

The seating information displayed here is similar to what we show in the pass footer and will be driven by the same seats dictionary provided in the pass.json.

That's all for ticketing updates. I hope these new Wallet pass updates help ticket holders more easily find all the information they need for any upcoming events. Now, back to Tanya for a quick summary of what we've shared. Thanks, Masha. This year, we've introduced several great new features to Wallet and Apple Pay. You can now transfer funds from both in-app and web, use Apple Pay for transactions across ecosystems and provide a richer ticketing experience for users. Now, here are a few reminders and action items for you.

If you've previously used browser detection to determine Apple Pay availability, make sure to leverage the canMakePayments API or the new applePayCapabilities API, which have been designed specifically to solve the problem of browser support for Apple Pay. Remember to download the sample code below to see all the new pass ticketing updates in action, and of course submit your feedback on the features presented today via feedback assistant. Finally, if you're completely new to Apple Pay on the web, check out the "Getting Started with Apple Pay on the Web" tech talk from last year.

And that's it. We hope you've enjoyed this session and enjoy the rest of WWDC. Thank you for watching.