Skip to main content

​
Setting up Apple Pay on the web

Before you configure your dashboard or write any code, you need to decide how Apple Pay fits into your tech stack. Every integration comes down to three choices:
  • The Checkout UI - Where does the payment button live, and whose code runs it? (e.g., lite Hosted Checkout vs. your own custom built UI).
  • The Apple Account - Who owns the Apple Developer account and registers the domains? (lite or you).
  • Token Decryption - Who holds the private keys to unlock the encrypted payment data? (lite or you).
To make this simple, these choices combine into three standard merchant use cases. Find the one that matches your business below.
Merchant use caseIntegration modeApple accountToken decryptionWhat you need to know
Quickest Web Setup
Best for web-only businesses that want no administrative friction.		lite Hosted Checkout - or - lite Web SDKlite-ownedlite decryptsNo Apple developer accounts needed. You just host a quick verification file on your site (SDK only). Not for iOS apps (only for web).
Brand Control & iOS
Best for mobile apps or web merchants who want to own their Apple setup without handling raw card data.		Direct API (Web) - or - Native iOS AppMerchant-ownedlite decryptsRequired for all iOS apps. Requires a merchant-owned Apple Developer Account. You will upload a lite-provided CSR to Apple to link the accounts.
Full Enterprise Control
Best for large businesses routing payments across multiple platforms.		Direct API (Web) - or - Native iOS AppMerchant-ownedMerchant decryptsRequires PCI-DSS Level 1 compliance. You manage your own keys and decrypt the data on your servers. No Apple setup is required in the lite dashboard.

​
Core technical constraints

If you aren’t sure which setup to pick, keep these three system limits in mind:
  • iOS apps require your own Apple account. If you are building a native iOS app, you cannot use lite’s Apple account. Apple requires all iOS apps to be registered under the developer’s own Apple Developer account.
  • lite tools require lite’s Apple account. If you use lite Hosted Checkout or the lite Web SDK, you must let lite manage the Apple connection. Our tools are built to run the Apple Pay flow securely using our master credentials.
  • Decrypting your own tokens requires PCI Level 1. You can only unlock and decrypt Apple Pay tokens yourself if your company has active PCI Level 1 certification. This is because the process involves handling raw, unencrypted credit card data on your servers. Otherwise, lite has to do it for you.

​
Ready to build?

Select your integration method below to see the exact API flows, dashboard steps, and code requirements to go live.

​
1. lite Hosted Checkout

Best for the fastest launch. Customers are redirected to lite’s checkout page, meaning lite handles the entire Apple Pay browser flow, Apple Developer account, and token decryption. Domain registration: You do not need to register any domains or host verification files. Apple Pay runs securely on lite’s checkout domain. Merchant checklist
  1. Enable Apple Pay for your channel in the lite Dashboard.
  2. Create a checkout session from your backend.
  3. Redirect your customer to the lite checkout page.

​
Onboarding flow

​
Payment flow

​
2. lite Web SDK

Best when you want the Apple Pay button on your own website, but you want lite’s SDK to handle the complex browser flows and Apple account setup. lite decrypts the payment token. Domain registration: Because the button appears on your domain, Apple needs proof you own it. You will host a lite domain association file on your server, and lite will automatically register your domain with Apple. Your checklist
  1. Add your website domain in the lite Dashboard.
  2. Download lite’s verification file and host it at /.well-known/apple-developer-merchantid-domain-association.
  3. Click “Check domain” in the lite Dashboard to trigger the Apple scan.

​
Onboarding flow

​
Payment flow

​
3. Direct API (lite-managed Apple account)

Best when you want full control over the checkout UI and browser behavior using Apple’s native APIs, but you still want lite to handle the Apple Developer account and decrypt the payment token. Domain registration: Identical to the Web SDK flow. You host lite’s verification file, and lite registers your domain with Apple. Your checklist
  1. Host lite’s domain verification file to verify your website.
  2. Render the Apple Pay button and create the ApplePaySession in your frontend code.
  3. Send Apple’s validation URL to your backend, and request an Apple merchant session from lite’s API.
  4. Pass the session back to the browser to complete merchant validation and receive the Apple Pay token.

​
Onboarding flow

Uses the same lite-managed domain registration flow as the lite SDK.

​
Payment flow

​
4. Direct API or an iOS app (merchant Apple account)

Best for native iOS apps, or enterprise web merchants who want to own their Apple Merchant ID for portability. Domain registration: You handle this yourself. You add your domain in your own Apple Developer Portal. Token decryption (the CSR flow): Registering with Apple does not mean you have to decrypt the credit card data yourself. You can authorize lite to decrypt your app’s traffic:
  1. You generate a lite Decryption CSR (Certificate Signing Request) inside the lite Dashboard.
  2. You upload that file into your Apple Developer Portal.
  3. Apple gives you a public .cer file.
  4. You upload that .cer file back to lite. (lite keeps the private key safe on our servers, ensuring we can decrypt your tokens without you ever touching raw card data.)
PCI Level 1 decryption: If your company is PCI Level 1 certified, you can skip the CSR flow above. You generate your own keys, decrypt the tokens on your own servers, and simply pass the decrypted network tokens to lite’s API. Your checklist Set up your Apple account
  • Create your Apple Merchant ID in your own Apple Developer Portal.
If you’re accepting Apple Pay on the web
  • Verify each web domain directly in your Apple Developer Portal: add the domain, download Apple’s verification file, host it at /.well-known/apple-developer-merchantid-domain-association, and click Verify.
  • Generate a Merchant Identity Certificate (your own CSR) and install its private key on your backend. This is what authenticates your Create Apple merchant session call to Apple. (Web only, native iOS doesn’t use it.)
Choose who decrypts the token Option A - lite decrypts (default)
  1. Generate a lite Decryption CSR in the lite Dashboard.
  2. Upload it to Apple, create a Payment Processing Certificate, download the .cer, and upload that .cer back to lite. lite keeps the private key and decrypts your tokens; you never handle raw payment data.
Option B - You decrypt
  1. Generate your own Payment Processing key pair and CSR, upload the CSR to Apple, and keep the private key on your servers.
  2. Decrypt tokens on your servers and send lite the decrypted payload. No Apple Pay setup is needed in the lite Dashboard for this path.
Note: Option B puts the decrypted Apple Pay payload (DPAN + cryptogram) in your environment, which brings those systems into PCI DSS scope.

​
Payment flow

This diagram shows the web flow. A native iOS app is simpler: there’s no domain verification and no “prove who you are” handshake with Apple (the iPhone already trusts your signed app), so you don’t need a Merchant Identity Certificate. The only part that’s the same is decryption: you still choose whether lite or you unlocks the token.