Overview
Use this page to learn how to enable Apple Pay on the web using Apple Pay JS or the Payment Request API. This demo preconfigures the Apple Pay button below with default values. Explore further by modifying values in the code blocks throughout the page to customize payment sheet experiences. This demo displays a transcript of server responses after each transaction for context. Click or tap the the "Show Transcript" tab to view the transaction transcript.
As well as letting you try out the Apple Pay JavaScript APIs, this demo can also serve as a tutorial for your own implementation. It assumes you have already set up your environment to process Apple Pay transactions, and are familiar with Apple Pay best practices. Before starting your integration, we recommend reviewing Getting Started with Apple Pay and the Apple Pay on the Web Human Interface Guidelines. For more information about supporting Apple Pay on your website, see Apple Pay on the Web.
This demo generates source code that you can copy into your own project. Click or tap the the "Show Source" tab to view the source code. The demo updates the source code as you change values in the code blocks through the page. Once you are happy with the configuration, click or tap the "Copy" button inside the "Show Source" tab to copy the source code to your clipboard.
Requirements
This demo uses Apple Pay JS version 3, and to run this demo you must be using:
- iOS devices running iOS 11 or later
- Safari 11 on macOS 10.13 or later
Display an Apple Pay button
To display an Apple Pay Button, first check that browser supports Apple Pay by using the following code:
if (window.ApplePaySession && ApplePaySession.canMakePayments()) // Display Apple Pay Button
WebKit provides many options for the look of the displayed button including style, kind of payment, language, size, and corner radius. Using the official WebKit buttons ensures your site will display the latest style, render correctly across devices, and follow Apple Guidelines. For more guidance on how to display the button in different situations, see Displaying Apple Pay Buttons.
Try it: Display Settings
Use the following tools to try the different display settings on the button shown below:
Button Style
Button Type
Button Language
style="-webkit-appearance: -apple-pay-button;
-apple-pay-button-type: plain;
-apple-pay-button-style: black;
width: 150px;
height: 30px;
border-radius: 3px;"
lang="en"
Create a Payment Request
When your customer clicks or taps the Apple Pay button, you must first construct an ApplePaySession object which
includes the ApplePayPaymentRequest dictionary detailing the
transaction details the payment sheet will display.
The ApplePayPaymentRequest requires details
including: the total payment for the transaction, the currency, and the supported payment networks. You can
optionally pass lineItems to show additional charges and discounts, and
shippingMethods to allow the customer to choose from
different shipping options. If you require address or contact details from your customer, request them by
passing values in the requiredShippingContactFields or requiredBillingContactFields.
Try it: ApplePayPaymentRequest
Modify the values in the ApplePayPaymentRequest shown below and click or tap the
Apple Pay button to view the payment sheet. Choose Basic Request to see a payment sheet with only the
required fields. Choose Detailed Request to show code including optional fields, such as lineItems.
Complete Merchant Validation
Before being able to display the payment sheet to the customer, you must generate a valid payment session by
interacting with Apple Pay Servers. For security reasons, your server must do this, not your browser client
code, unlike everything else in this demo. To start the merchant validation process, call the begin method on the session object you created above.
Once you do, the browser will invoke your onvalidatemerchant handler, which must fetch a merchant
session from your server.
Refer to the instructions in Requesting an Apple Pay Payment Session document to implement your server endpoint responsible for fetching the merchant session object from Apple Pay servers. If successful, Apple Pay servers will return a merchant session object, which your server must then pass back as the response to the browser.
Once you have the merchant session response object in the browser, you must complete your
onvalidatemerchant handler by passing that object to the
completeMerchantValidation method on the session object.
The browser will then display the payment sheet.
The following code shows an example of how to validate merchant:
session.onvalidatemerchant = event => {
// Call your own server to request a new merchant session.
fetch("/authorizeMerchant")
.then(res => res.json()) // Parse response as JSON.
.then(merchantSession => {
session.completeMerchantValidation(merchantSession);
})
.catch(err => {
console.error("Error fetching merchant session", err);
});
};
Respond to Payment Sheet Interactions
After merchant validation is complete, Apple Pay provides the information about your customer’s payment sheet
selections so that you can calculate the final transaction cost. The final details of a transaction may depend
on user payment method, billing address, shipping address, or shipping method.
To handle these adjustments, implement the optional handlers onpaymentmethodselected,
onshippingmethodselected,
and
onshippingcontactselected. When the browser calls one of
these handlers, you have 30 seconds to process it and call the corresponding callback function, otherwise the
transaction times out. All callbacks accept an object with newTotal (required) and newLineItems (optional) keys. In addition, you may
specify newShippingMethods to update shipping methods, and errors to indicate problems with the user's selected shipping address when calling completeShippingContactSelection. You may also call the
callbacks with an empty object or null value if the payment sheet needs no changes.
| Event Handlers | Callback Function | Update Structure | Update Properties |
|---|---|---|---|
onpaymentmethodselected
|
completePaymentMethodSelection
|
ApplePayPaymentMethodUpdate
|
newTotal (required)
newLineItems (optional)
|
onshippingmethodselected
|
completeShippingMethodSelection
|
ApplePayShippingMethodUpdate
|
newTotal (required)
newLineItems (optional)
|
onshippingcontactselected
|
completeShippingContactSelection
|
ApplePayShippingContactUpdate
|
newTotal (required)
newLineItems (optional)
newShippingMethods (optional)
errors (optional)
|
Demo Note: The test transaction always passes in a default success response when it calls
completePaymentMethodSelection. The test transaction passes in
newLineItems
and
newTotal
when it calls
completeShippingMethodSelection. See responses in the transcript.
Request a Shipping Address
If you pass requiredShippingContactFields in the
payment request with a postalAddress
value, Apple Pay provides redacted address information before the user
authenticates the transaction. After the user authenticates, Apple Pay provides the full contact information.
The redacted payment information includes only the data needed to complete required transaction tasks, such as calculating taxes or shipping costs, and may differ based on the user's geographic region.
The following code shows an example of a redacted payment information:
onshippingcontactselected:
{
"administrativeArea": "CA",
"country": "United States",
"countryCode": "US",
"familyName": "",
"givenName": "",
"locality": "San Francisco",
"phoneticFamilyName": "",
"phoneticGivenName": "",
"postalCode": "94114",
"subAdministrativeArea": "",
"subLocality": ""
}
Try it: completeShippingContactSelection
Choose 'Success' with or without updating line items and total below. Choose 'Failure'
to see completeShippingContactSelection response with custom
errors. You may edit the ApplePayShippingContactUpdate response object below to
experiment with different responses. Click or tap the Apple Pay button below to see how the payment sheet
displays updates or address errors.

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
