How to set up Apple Pay for business without losing control of it

If your provider holds the decryption keys, Apple Pay traffic carries no BIN, no issuer country, and no card brand into your routing engine — which means no routing rules, no cascading, and no way to move that volume to a second acquirer.

This guide covers the certificates you need, the four integration paths and what each one costs you, the real fee structure, where the conversion gain comes from, and the recurring-billing rule that breaks subscriptions after launch.

What you're actually accepting when you accept Apple Pay

Every Apple Pay transaction is a card transaction. What changes is the credential: a scheme-issued token and a one-time cryptogram in place of the card number, which means the question is never ‘should we add Apple Pay or improve card acceptance’ — it's the same volume, delivered with better credentials.

The card networks, not Apple, act as the token service provider. When a customer adds a card to their Wallet, the scheme issues a token that stands in for the primary account number, and every transaction carries a one-time cryptogram proving the payment was authorized on that device by that person. Your processor never sees the real card number.

Two token types exist, and the distinction matters more than most merchants realize at setup:

The commercial argument for tokenization is measurable. Visa reports a 4.6% lift in authorization rates⁠ on tokenized card-not-present transactions against raw PANs, alongside roughly a 30% reduction in online fraud. Mastercard puts its equivalent average uplift⁠ at 2.1%. Issuers approve tokenized transactions more readily because the network pre-validates the token before the authorization ever reaches them.

4 ways to put Apple Pay into your checkout

This is the section that determines what you can do with Apple Pay for the next three years. Corefy supports 4 integration paths⁠, and they differ on one axis that matters: whether card data becomes available inside your platform.

• Native, decrypt. The Apple Pay button sits directly in your checkout. The encrypted token is transmitted to the platform, decrypted there, and processed. Because decryption exposes card attributes, routing rules that reference card data become usable. Without decryption, routing on those attributes cannot be initiated at all.
• Native, non-decrypt. Same in-checkout button, same customer experience. The encrypted token passes straight through to your acquirer or PSP, which handles decryption and processing. Integration is simpler, and there's less for your team to maintain. The tradeoff is that the token is opaque to you, so Apple Pay traffic sits outside any routing logic that depends on card attributes.
• Redirect. The customer leaves your checkout for a hosted page owned by the acquirer or PSP and completes the payment there. Token handling is entirely the provider's problem, which makes this the lowest-effort path. It also reintroduces the redirect that Apple Pay was supposed to eliminate.
• In-app. For iOS applications, the same certificates and merchant identifier apply. Apple recommends⁠ using one merchant ID and certificate across both your app and website rather than maintaining separate sets.

The decrypt path is what Corefy's token decryption service was built for. You use your own Apple merchant identifier and your own payment processing certificates to decrypt tokens independently of any single provider, then transfer card data rather than opaque tokens downstream. Practically, that means Apple Pay stops being a single-provider silo: the same volume can be routed and cascaded across 600+ connected providers using the same routing and cascading rules you already run on card traffic. A declined Apple Pay authorization gets a second attempt instead of becoming a lost sale.

There's a design benefit to the native paths as well. You control where the Apple Pay button sits on the page and can style it within Apple's acceptable use guidelines⁠, which matters more than it sounds — see the conversion section below.

How to set up Apple Pay for business, step by step

The setup produces four artifacts: a merchant identifier, a payment processing certificate, a merchant identity certificate, and a validated domain. Each does a distinct job, and knowing which is which saves considerable time when something breaks.

1. Generate a merchant identifier. In your Apple Developer account, register a new identifier and select Merchant IDs. This is your Apple Pay merchant identification: it identifies your business to Apple as an entity able to accept payments, never expires, and can be reused across multiple apps.
2. Request a payment processing certificate. Generate a certificate signing request in Keychain Access using a 256-bit elliptic curve key with ECDSA. Upload the request against your merchant ID and download the signed certificate. This certificate is what encrypts and decrypts the payment data in Apple Pay transactions.
3. Retrieve the private key. Export the key you generated as a .p12 file, then convert it to a PEM-formatted private key. Without this key, the certificate is useless.
4. Create a merchant identity certificate. A second certificate signing request, a second signed certificate. The Apple Pay merchant identity certificate authenticates your server to Apple during merchant validation on the web. Mobile apps don't need it.
5. Register your domains. Add each domain to your merchant ID and host Apple's verification file at https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association. For validation to succeed, domains can't sit⁠ behind a proxy or redirect and must be publicly reachable. This is where most integrations stall.
6. Activate on the platform. Connect a provider that supports Apple Pay, add the method, then supply your merchant identifier, merchant certificate, and private key. Add Apple Pay to your payment scheme and write routing rules for it.
7. Switch it on at checkout. Enable express methods in your Checkout settings and toggle Apple Pay on. The button appears immediately.

The exact commands for certificate conversion are in the Apple Pay setup guide⁠ in our documentation. Two operational notes worth planning for: payment processing certificates expire and need to be rotated on a schedule, and if you run a white-label domain, domain verification details need to be agreed with your account manager before you begin.

What Apple Pay costs a merchant

Apple charges no per-transaction fee, no setup fee, and no monthly minimum. Apple's own developer guidance states it doesn't charge users, merchants, or developers to use Apple Pay, and your card transactions continue to be handled by the payment networks as normal.

The costs sit elsewhere, and they're worth pricing honestly:

• $99 per year for Apple Developer Program membership — the only fee Apple actually charges, and it applies⁠ even to web-only integrations with no iOS app.
• A few days of engineering for certificates, domain validation, and integration, then certificate rotation as a standing operational task with an owner's name against it.
• Scheme fees on tokenized traffic, passed through by your acquirer. Not an Apple Pay charge, but Apple Pay volume sits inside it.

Where the conversion gain comes from

Apple Pay's conversion gain comes from three separable effects. Each one is measurable on your own traffic, and they don't move together — a merchant can gain heavily on one and nothing on the others.

• Fewer fields. Apple Pay removes the card form, the billing address, and the shipping address in a single authentication. The size of this effect depends almost entirely on placement. Stripe found⁠ that businesses see roughly a 2x increase in conversion when Apple Pay appears early in the flow via an express checkout element, compared with showing it at the end. Same wallet, same customers, different result. An Apple Pay button on the cart page removes the entire form; a fourth button on the final payment step removes almost nothing.
• Fewer fraud declines and fewer chargebacks. Apple Pay satisfies strong customer authentication requirements in most regions through Face ID or Touch ID, so transactions often benefit from a liability shift without a separate 3DS challenge. Where the issuer returns an ECI confirming successful authentication, the liability for fraud rests with the issuer. Two caveats: the shift covers fraud disputes only, not service or delivery disputes, and it depends on the cryptogram and authentication data reaching the authorization intact.
• Higher approvals. The tokenization uplift covered above, applied silently to every transaction.

One detail that changes the placement calculation: the Apple-provided button isn't wasted on non-Apple traffic. On iOS devices, it opens Wallet; on other devices, it displays⁠ a QR code that the customer scans with an Apple device to continue the payment. Giving Apple Pay a prominent express slot doesn't cost you anything on desktop Chrome.

The recurring billing trap most merchants hit late

If you bill subscriptions through Apple Pay, device tokens will fail you, and the failure won't give you any warning.

Visa has twice postponed the rule that would decline standing-instruction merchant-initiated transactions on device tokens, and it remains delayed⁠ until further notice. That's why teams keep deferring the migration, and why it's worth doing anyway. The rule declines any standing instruction on a device token provisioned after 30 July 2025⁠ — the scope is set by the provisioning date, not the transaction date. Every subscriber you sign up on a device token today is an exposure that activates whenever the deadline lands. Visa honors grandfathered tokens but doesn't guarantee⁠ they keep working, and Apple recommends⁠ merchant tokens regardless.

The second failure mode catches teams with otherwise correct integrations: cryptogram expiry.

Every Apple Pay tokenization arrives with a single-use cryptogram that the first authorization must consume. If it expires before you charge, you don't just lose that payment — the merchant-initiated transactions chained to it fail as well, taking the entire subscription with them. Free trials, deferred first charges, and any gap between authorization and capture are where this bites hardest.

The fix is straightforward and belongs in the billing flow before launch, not after the first wave of failed renewals. Consume the cryptogram immediately with a zero-amount validation, then store the network transaction ID the scheme returns. That ID is what links every later off-session charge back to the customer's original authorization.

Both failures share a characteristic that makes them expensive: no alert, error queue, or obvious signal. They surface as ordinary subscriber decay in a dashboard, months after the cause, by which point the affected customers are long gone and unrecoverable.

This is where holding the credential yourself stops being an architectural preference and starts being revenue. A platform that stores the network transaction ID rather than leaving it inside one provider can retry a failed renewal through a different acquirer instead of losing the subscription. That's the same decrypt-path argument from earlier in this article, applied to recurring volume: without it, every renewal gets exactly one attempt.

Apple Pay pre-launch checklist

Before you schedule the go-live, run this list. Groups one and two are launch blockers. Group three is the one teams skip and then rediscover in a churn report.

Final thoughts

Apple Pay is relatively easy to add. The more consequential decision is where the payment credential lives once the customer taps the button. That choice determines whether Apple Pay remains tied to one provider or becomes part of the same routing, cascading, and recovery logic as the rest of your card traffic.

There is no universally best integration path. If you operate with one PSP and have no reason to move traffic between acquirers, letting the provider handle decryption may be the simpler setup. But once you work across several providers or markets, or want another route when an authorization fails, keeping control of the credentials starts to justify the extra operational work.

This is where Corefy’s Apple Pay token decryption becomes relevant. With your own merchant identifier and certificates, Corefy can decrypt Apple Pay tokens before they reach the provider, making the underlying card attributes available for routing. Apple Pay traffic can then be routed and cascaded across Corefy’s 600+ connected providers instead of remaining locked to the PSP that handled token decryption.

The same control matters for recurring payments. Merchant tokens, timely cryptogram consumption, and storing the network transaction ID should be designed into the billing flow before launch; otherwise, issues can surface months later as apparently ordinary churn.

So, before treating Apple Pay as another checkout button, decide what you want to do with that payment volume a year or two from now. The quickest integration may be enough today; the right architecture is the one that still gives you options as your payment setup grows.