Overview
About
Apple Pay allows users to pay securely using cards saved to their Apple Pay Wallet, in iOS apps and on websites.
Note - Supported by Checkout SDK
Apple Pay is supported by Mangopay’s Checkout SDK, which can power the payment page of your website or app. Read more →
Activation
To offer Apple Pay with Mangopay you need to set up an Apple Pay merchant identifier and Payment Processing Certificate as described in the certificates guide.
You also need to integrate directly with Apple Pay:
- Apple Pay on web (see also their demo)
- Apple Pay on iOS (PassKit)
If not using Mangopay’s Checkout SDK, you also need to adhere to their design guidelines.
Flow diagram
The basic flow of a one-time Apple Pay payment is given in the diagram below.
One-time payments
Present Apple Pay to user
The user selects Apple Pay at the checkout on your app or website and confirms payment.
The user’s card must be registered in their Apple Pay wallet (see testing information).
Request the payment from Apple Pay
Use the Apple Pay PKPaymentRequest to request the payment, specifying the visa and masterCard values as the supportedNetworks.
The order of the array determines the order of display to the user, and the first position in the array is the default network (see Apple Pay’s documentation).
Note – Platforms in France should send CB first
If your platform offers CB co-branded cards in France, you should also include the value cartesBancaires first in the array to comply with regional standards to present the co-branded network first.
For example:
In response, Apple Pay returns encrypted data specific to the payment.
Request the pay-in from Mangopay
Call the POST Create an Apple Pay PayIn endpoint, including the PaymentData object as received from Apple Pay. The amount and currency of your pay-in request must match your Apple Pay request.
Note - 3DS redirection not required for Apple Pay
With Apple Pay, SCA-compliant authentication is handled by the user’s device (iPhone or Mac), meaning that the payment data received from Apple Pay is already authenticated and no 3DS redirection is required.
Handle the outcome
The transaction is complete when the pay-in status changes from CREATED to SUCCEEDED or FAILED, indicating the outcome.
Set up webhooks for the PAYIN_NORMAL_SUCCEEDED and PAYIN_NORMAL_FAILED event types to be notified of this.
Recurring payments
Recurring payments with Apple Pay requires a pay-in registration object to set up the recurrence, before your platform can request pay-ins linked to the registration.
The first pay-in, a customer-initiated transaction (CIT), requires the user to be on session. Once the first payment is successful, your platform can then request subsequent pay-ins without the user present, known as merchant-initiated transactions (MITs), at the frequency and amount agreed by the user.
Payment flow
The steps are as follows:
Request the payment from Apple Pay
In the recurring flow, you need to obtain the PaymentData from Apple Pay before calling the Mangopay API.
Set up the recurring registration
Call the POST Create a Recurring PayIn Registration to register details about the user, the wallet, and the payments.
Set the PaymentType to APPLEPAY and provide the tokenized PaymentData object retrieved from the Apple Pay API.
The registration object contains the amount of the first transaction and details about the recurrence. It is also possible to specify the amount of subsequent transactions, but this can be overridden when requesting subsequent pay-ins.
In the response, the RecurringPayinRegistrationId allows you to link the recurring pay-ins to this registration object. The Status of the registration object is CREATED.
Process the customer-initiated transaction (CIT)
Call the POST Create a Recurring Apple Pay PayIn with the CIT payload to initiate the first transaction.
With Apple Pay, authentication is handled by the user’s device (iPhone or Mac), meaning no 3DS redirection is necessary – the PaymentData is already authenticated.
The CIT pay-in request therefore does not require redirection for the user and can pass directly to SUCCEEDED. When this happens, the registration object Status becomes IN_PROGRESS to indicates that you can debit subsequent payments without the user present.
Set up a webhook for the RECURRING_REGISTRATION_IN_PROGRESS event type to be notified of this.
Process merchant-initiated transactions (MIT)
For subesequent payments, call the POST Create a Recurring Apple Pay PayIn with the MIT payload to initiate the pay-in.
Reauthentication
If at any point reauthentication is required by the issuer, the Registration object Status changes to AUTHENTICATION_NEEDED, which you can be notified of thanks to the RECURRING_REGISTRATION_AUTH_NEEDED event type.
In this case, you need to:
- Obtain a new
PaymentDataobject from Apple Pay - Call the PUT Update a Recurring PayIn Registration with the new data
- Process a new CIT payment with the user on session
Ending the recurrence
The registration object Status can be set to ENDED to indicate that it can no longer be used. You can do this using the PUT Update a Recurring PayIn Registration endpoint.
Set up a webhook for the RECURRING_REGISTRATION_ENDED event type to be notified of this.