Setup RequiredBefore implementing Apple Pay payments, ensure you have completed the prerequisites.
Testing EnvironmentApple Pay is not supported in the iOS Simulator. To test Apple Pay functionality, you must use a physical iOS device.
Apple Pay overview
- Customer initiates payment on their iOS device
- Receive
payment_tokenvia Apple SDK - Create a checkout session with Yuno
- Yuno processes with your configured provider(s) and returns a response
- Monitor response status via webhooks
Add Apple Pay capability
To add Apple Pay capability to your iOS app:- In Xcode, select your project in the navigator
- Select your app target
- Go to the Signing & Capabilities tab
- Click + Capability and search for “Apple Pay”
- Add the Apple Pay capability
- Configure your Merchant IDs in the Apple Pay section
One-time payments with SDK
One-time Apple Pay payments using the Yuno SDK provide a streamlined integration experience for immediate transactions.Create checkout session
Use the create checkout session endpoint to create a payment session for one-time Apple Pay transactions:Process the payment
The SDK handles the Apple Pay flow automatically. When the customer completes the Apple Pay authorization, the payment is processed immediately.Requesting Contact Information
You can configure which contact fields Apple Pay requests from the customer directly from the Checkout Builder. The available fields are:- Phone
- Holder name
- Billing address
- Shipping address
Each additional required field adds an extra step to the Apple Pay payment sheet, increasing friction for the customer. This can negatively impact conversion rates. We recommend enabling only the fields that are strictly necessary for your business or regulatory requirements.
| Platform | Minimum version |
|---|---|
| Web | 1.8.0 |
| iOS | 2.15.0 |
Recurring payments with SDK
The SDK streamlines recurring payments by managing both Customer‑Initiated (CIT) and Merchant‑Initiated (MIT) transactions while securely handling payment tokens. The overall flow is:- Create a checkout session with the
recurring_paymentobject. - Perform a CIT to authorize and vault the customer’s payment method.
- Then use the returned
vaulted_tokenfor subsequent MIT charges.
Create checkout session for recurring payments
Before creating the transaction, you need to create the checkout session with therecurring_payment object populated in your checkout session request:
Free trial: When offering a free trial period, set the root amount.value to 0 and include the trial_billing object as shown in the example below. The actual recurring charge is defined in regular_billing, which informs the customer of the amount they will be billed once the trial ends.
Customer Initiated Transaction (CIT)
The CIT is the initial transaction where the customer authorizes recurring payments, such as when they subscribe to a monthly service. This transaction requires customer interaction and generates a token for future MIT transactions. The following example shows a complete CIT request:vault_on_success: true: This parameter indicates this is a recurring payment setup and generates the token for future MIT transactionsstored_credentials.usage: "FIRST": Indicates this is the initial transaction in a recurring seriesverify: Whentrue, enables a card verification flow through the wallet (e.g., a zero-dollar authorization) instead of a regular payment charge.
Set
verify: true for free trial flows where amount is 0. Omit the field for standard paid CITs.Merchant Initiated Transaction (MIT)
MIT transactions are processed automatically for subsequent billing cycles using the token generated during the CIT. The following example shows a complete MIT request:vaulted_token: The token returned in the CIT response; used to charge the customer in subsequent billing cycles without requiring re-authorizationstored_credentials.usage: "USED": Indicates this is a subsequent transaction in a recurring series- No
payment_tokenrequired: Uses the stored token instead
Obtain DPAN BIN in OTT response
When a payment is completed with Apple Pay, the iOS SDK returns the full OTT (One-Time Token) service response. Within this response, thecard_data object contains card-related information associated with the Apple Pay payment, including the DPAN BIN (the first digits of the Device Primary Account Number used in the transaction).
Merchants can use this object to retrieve card details such as brand, type, issuer, and the iin field, which represents the DPAN BIN.
Example OTT response (iOS SDK)
The following example shows the SDK response containing thecard_data object with the iin field:
Apple Pay Cancel Flow
When a user cancels the Apple Pay flow, the SDK reports the statusCANCELED_BY_USER.
Metadata and paymentCreated
TheoldClosePaymentFlow method (and related cancel events) now includes an optional metadata parameter with the paymentCreated field. This allows merchants to know if a payment was already created on the backend before the user canceled the flow.
paymentCreated: true: A payment was created (e.g., during OTT creation phase). Merchants should check the payment status and potentially trigger anabandonPaymentcall.paymentCreated: false: No payment was created before cancellation.
paymentCreated = true during the onvalidatemerchant phase to ensure correct tracking and abandonment of pending payments.