Apple Pay allows customers to authenticate card payments using Touch ID or Face ID, eliminating the need to enter card and shipping details manually. It is available on all iOS devices equipped with a Secure Element, a certified chip that securely stores payment information. On macOS, users can authorize payments using an iPhone, Apple Watch, or a Mac with Touch ID.

When a payment request is made through an app or website, the Secure Element generates an encrypted Apple Pay token containing transaction details. This token allows you to handle decryption on your side or securely transfer transaction details to Solidgate.

Let Solidgate handle decryption

If you are not compliant with PCI DSS, you should use the Solidgate service to decrypt the token. Once the payment is initiated, you will receive a token either from your application or website, which you will need to include its payment data in the Apple Pay API payment request.

For this to work, you need:

• Integration with Solidgate
• Integration with Apple and button configuration:
  • Apple Pay Web Reference
  • Apple Pay Mobile Reference
• Payment Processing Certificate Reference from the Apple Developer account

Payment flow

For further information about payment parameters, refer to the Apple Pay API method.

Handle decryption on your side

If you are PCI DSS-compliant, you can decrypt Apple Pay tokens on your side. For that, you will also need to:

• Have an Apple Pay developer account Reference
• Have a H2H integration
• Follow Apple’s guidelines to decrypt the token

To decrypt Apple Pay tokens, follow the steps on the Apple developer portal Reference . Please note that you need to verify the Apple Pay certificate before proceeding to token decryption.

Payment flow

The use of is_decrypted: true implies that the data sent is decrypted and this parameter defines the required fields in the request.

If is_decrypted: true , the request must:

• include the decrypted_data object
• specify type: auth
• exclude data and signature

Additionally, the version parameter becomes optional, and the paymentData object depends on the paymentDataType value, which can be either:

• 3DSecure : for transactions that use 3D Secure authentication.
• Highly recommended to provide with paymentDataType: 3DSecure the eciIndicator Guide
  ECI value represents authentication, affects authorization and liability protection. value for better transaction success rate
• EMV : for EMV chip-based transactions, which require emvData

Example with 3DSecure :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
  "is_decrypted": true,
  "decrypted_data": {
    "applicationPrimaryAccountNumber": "537421XXXXXX4037",
    "applicationExpirationDate": 270131,
    "currencyCode": 840,
    "transactionAmount": 499,
    "cardholderName": null,
    "deviceManufacturerIdentifier": "050110XXXXXX0273",
    "paymentDataType": "3DSecure",
    "paymentData": {
      "onlinePaymentCryptogram": "MDnQeplHdAB8AXLU5I",
      "eciIndicator": "05"
    },
    "type": "auth"
  }
}