Apple Pay

Cards Bundle

Biometric payment authentication with local acquiring across Latin America.

Apple Pay lets customers pay with Face ID, Touch ID, or a double-click, using cards saved to their Apple devices. Your checkout receives the encrypted token and sends it to EBANX. EBANX decrypts it and routes the charge to the local acquirer.

Why offer Apple Pay

No manual entry

Customers authenticate with biometrics. No card number, no CVV, no redirects. Fewer abandoned carts on mobile.

+11 p.p. auth rate

Apple Pay transactions carry a network token and a one-time cryptogram. Issuers approve them more often than raw PAN charges.

Reduced PCI scope

With EBANX-side decryption, your servers never handle raw card data or private cryptographic keys.

11 markets, one integration

EBANX routes Apple Pay to local acquirers across 11 Latin American markets via a single Direct API integration.

Integration models

EBANX supports two integration models. Choose based on where decryption happens and how much control you want over the Apple Pay setup.

Model 1: Merchant-side decryption

In Model 1, your servers own the full decryption stack. When a customer pays with Apple Pay, your checkout receives the encrypted PKPaymentToken directly from Apple. Your backend decrypts it using ECDH-ES, extracts the DPAN (the network token that replaces the card PAN), the one-time cryptogram, and the ECI indicator, then sends those values to EBANX via the network_token_* fields in the Direct API request. EBANX forwards the charge to the local acquirer using the data you provide.

You generate and own your Payment Processing Certificate in Apple Developer Portal. The private key never leaves your infrastructure. This gives you full control over certificate rotation, revocation, and key custody, which some security teams require.

Certificate management	Managed by you. You generate the key pair, create the Payment Processing Certificate in Apple Developer Portal, and control its lifecycle.
PCI scope	Your servers are in scope for the decryption step. The DPAN and cryptogram pass through your infrastructure before reaching EBANX.
Integration effort	Higher. You implement ECDH-ES decryption, map the token fields, and maintain the certificate independently.

When to use Model 1

Choose this model if you already operate Apple Pay decryption infrastructure, or if your security policy requires you to own the certificate and key management end to end.

Payment flow

Model 2: EBANX-side decryption

In Model 2, your checkout passes the raw encrypted PKPaymentToken directly to EBANX without touching its contents. EBANX decrypts the token on its own infrastructure using its private key, extracts the DPAN, cryptogram, and ECI, then routes the authorization to the local acquirer. Your servers never handle decrypted card data or cryptographic keys at any point in the flow.

To set this up, you create an Apple Merchant ID in Apple Developer Portal and generate a Payment Processing Certificate using EBANX's CSR. That certificate tells Apple to encrypt tokens with EBANX's public key, so only EBANX can decrypt them. You own and maintain the Merchant ID; you just never hold the private key. After Apple generates the certificate, contact your EBANX integration engineer to complete the configuration on EBANX's side before your first transaction.

Certificate management	Shared. You create the Merchant ID and Payment Processing Certificate in Apple Developer Portal using EBANX's CSR. EBANX manages the key pair.
PCI scope	Reduced. Decryption happens inside EBANX's infrastructure. Your servers transmit the encrypted blob but never process card data.
Integration effort	Lower. You serialize the token from Apple and forward it as a JSON string. No cryptographic implementation required on your side.

When to use Model 2

Choose this model if you're integrating Apple Pay for the first time, want to minimize PCI scope, or don't want to manage certificate key custody yourself.

Payment flow

Availability

Available in 11 Latin American markets. Visa and Mastercard are supported in all countries.

Argentina

Brazil

Chile

Colombia

Costa Rica

Dominican Republic

Guatemala

Panama

Paraguay

Peru

Uruguay

Key concepts

DPAN. The network token Apple assigns to replace the real card number in the authorization request. Apple Pay never exposes the actual card number.

MPAN. Merchant Token. A network token Apple issues for a specific merchant, scoped to that merchant rather than to a device. MPAN enables recurring and merchant-initiated transactions, including subscriptions and installments, across all of the customer's devices.

Cryptogram. A one-time value the Secure Element generates per transaction. It tells the issuer the payment came from a verified Apple device.

ECI. A two-digit code that signals how the payment was authenticated. EBANX passes it to the acquirer; when the issuer supports it, liability shifts to them.

CSR (Certificate Signing Request). A file you upload to Apple Developer Portal when creating a Payment Processing Certificate. In Model 2, EBANX provides the CSR so that the resulting certificate binds to EBANX's private key. Apple uses it to encrypt every PKPaymentToken your customers generate.

Still need help?

We hope this article was helpful. If you still have questions, you can explore the following options:

• Merchant support: Contact our support team at sales.engineering@ebanx.com for assistance.
• Not a partner yet? Please complete the Merchant Signup Form, and our commercial team will reach out to you.