Apple Pay
Apple Pay enables e-commerce merchants to capture conversions on iOS and macOS devices through hardware-bound biometric authentication. Cardflo orchestrates these encrypted wallet tokens across multiple acquirer partners to ensure high authorisation rates during Safari checkouts.
- Category
- Methods
- Capabilities
- 6
- Available on
- All plans
E-commerce platforms face significant cart abandonment rates when mobile shoppers encounter lengthy payment forms on small screens. iOS users expect instantaneous authentication without manual data entry, requiring checkout interfaces that natively read device hardware for identity verification while keeping payment credentials encrypted and inaccessible to interceptors.
Cardflo connects merchants to regulated acquirer partners capable of processing tokenised Apple Pay payloads. The orchestration layer routes decrypted device account numbers based on transaction currency and risk profiles, handling Face ID and Touch ID authentication flows directly within Safari and native iOS applications to secure fast authorisations.
Apple Pay transactions, secured through biometric authentication, help merchants reduce PCI DSS scope and remove checkout friction, boosting approval rates. The process ensures high levels of security and user convenience, promoting higher conversion.
Apple Pay overview
Implementing an Apple Pay integration requires merchants to exchange standard card forms for cryptographic tokens tied to individual Apple devices. This checkout mechanism leverages native Safari WebKit APIs to bypass manual data entry, passing hardware-authenticated encrypted payloads directly to the payment gateway.
Cardflo structures these integration points and orchestrates the resulting network tokens across a curated acquirer partner network. The orchestration engine targets optimal conversion paths for iOS users based on risk scores, transaction values and regional acquirer performance.
While platforms must accommodate other environments by maintaining a distinct google pay setup for Android users and exploring broader approaches on the digital wallets page, this specific infrastructure isolates the unique requirements of the Apple ecosystem.
Merchants rely on this token exchange to capture biometrically verified transactions without exposing primary account numbers during the authorisation sequence.
How apple Pay works
Device and browser validation
The merchant checkout initiates a session check using the Safari web development framework to verify whether the customer device contains an active Apple Wallet. If the system detects a compatible iOS or macOS environment, the interface displays the payment sheet overlay. The platform simultaneously retrieves supported card networks and regional acquiring capabilities from the orchestration layer.
Token payload generation
Shoppers authenticate the purchase amount and shipping selection using device-level biometrics. The Apple secure element generates a single-use cryptographic cryptogram and pairs it with the device account number. The operating system encrypts this payload using the merchant certificate, ensuring the primary account data remains obscured as it leaves the consumer device and travels to the gateway infrastructure.
Acquirer routing and decryption
Cardflo receives the encrypted payload and intelligently assigns the transaction to an appropriate acquirer partner based on currency, risk rules and routing preferences. The designated acquiring institution handles the final decryption in coordination with the tokenisation network, requesting authorisation from the issuing bank using the verified biometric cryptogram in place of a standard CVV check.
Why apple Pay matters
Reduced mobile checkout friction
Traditional online forms require manual data entry that often causes mobile shoppers to abandon their baskets. Implementing an ios web checkout replaces tedious keystrokes with an immediate biometric scan. This native interaction captures existing shipping profiles directly from the device, reducing the purchase sequence to a single hardware interaction and increasing overall mobile conversion rates.
Elevated authorisation rates
Transactions authenticated via hardware biometrics carry strong proof of identity, lowering the perceived risk for issuing banks. Because the payment payload uses network tokens rather than exposed primary account numbers, false declines for suspected fraud drop significantly. Finance teams benefit from higher acceptance ratios and lower chargeback liabilities, as the liability shift typically favours the merchant for biometrically verified payments.
Regulatory notes for apple Pay
Strong customer authentication
European banking regulations strictly mandate two-factor authentication for electronic e-commerce payments to mitigate consumer fraud. Device-level biometric authentication techniques, such as scanning a fingerprint or mapping facial geometry, simultaneously satisfy the possession and inherence factors required under the current Strong Customer Authentication framework.
By relying on hardware-based verification routines, merchants bypass the need for external SMS codes or app-based authentication protocols.
The issuing bank treats the embedded cryptogram as a fully compliant challenge response, preserving the frictionless consumer checkout while strictly adhering to regulatory scheme rules for identity verification.
Tokenisation liability and compliance
Storing primary account numbers directly on internal merchant servers creates a significant compliance burden under the Payment Card Industry Data Security Standard.
Network tokenisation replaces these sensitive details with surrogate values, ensuring the actual primary account number never touches the merchant database during the payment lifecycle.
This encrypted architecture drastically reduces the regulatory compliance scope for the merchant while securing a liability shift from the business to the card issuer.
When an order undergoes successful hardware authentication, network scheme rules generally protect the merchant against fraud-related chargebacks originating from that specific transaction.
Apple Pay use cases
Safari express checkout
Retailers using Apple Pay on Safari can replace card entry and account creation with a payment sheet containing tokenised credentials and delivery details. Cardflo supports Apple Pay web integration, merchant validation and gateway orchestration, while its acquirer partners authorise the resulting network token transactions.
Native iOS app payments
iOS app merchants need Apple Pay payment sheets to pass authenticated purchase data from Face ID or Touch ID without exposing primary account numbers. Cardflo connects native application flows to gateway APIs, applies payment routing and sends device-account-token transactions to suitable acquirer partners for authorisation.
Multi-domain merchant validation
Retail groups operating several branded websites must register and validate each eligible web domain before presenting Apple Pay within supported Safari checkout journeys. Cardflo coordinates domain-association setup, merchant validation sessions and certificate-dependent gateway configuration, then routes authorised token payloads through its acquirer partner network.
Biometric checkout recovery
Apple Pay checkouts can fail when Face ID or Touch ID is cancelled, the selected card is unavailable or the payment token expires before authorisation. Cardflo records wallet-specific response data, supports controlled retry logic and routes fresh Apple Pay token payloads to an appropriate acquirer partner.
Apple Pay by the numbers
Typical implementations show that biometric wallet checkouts can be completed significantly faster than manual card entry, though actual times vary by network latency.
Merchants often observe an uplift in mobile conversion when introducing wallet-based checkouts due to the removal of form-filling friction, based on standard industry benchmarks.
Standard industry ranges suggest that authenticated wallet transactions often maintain very high approval rates, as they are pre-verified by the issuer's biometric protocols.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with Apple Pay
- Direct Safari payment request API implementation to capture billing and shipping details within the native iOS overlay.
- Hardware-level Face ID and Touch ID authentication satisfying Strong Customer Authentication mandates without external challenge screens.
- Dynamic multi-acquirer routing of decrypted device account numbers based on real-time network acceptance rates and transaction currency.
- Support for merchant initiated transactions that utilise existing Apple wallet payments for subscription and recurring billing models.
- Automatic suppression of the Apple Pay button on unsupported devices to maintain a clean interface for non-iOS visitors.
- Reconciliation reporting that maps device-specific cryptographic tokens back to the original e-commerce order ID for finance teams.
A short scoping call, then a written plan for your MIDs.
Questions about Apple Pay
How does the Safari payment request API handle shipping addresses?
The web implementation allows developers to request specific contact and shipping details directly from the user device during the biometric authentication sequence.
When the merchant configures the payment sheet, they define the required fields, and the native overlay prompts the shopper to select their preferred delivery destination from their saved profile.
This data transfers alongside the encrypted payment payload, entirely removing the need for separate address forms on the merchant domain and accelerating the mobile purchase flow.
Do tokenised wallet payments require 3D Secure challenges?
Transactions verified via Face ID or Touch ID inherently satisfy the Strong Customer Authentication mandates under European PSD2 regulations. The device hardware handles the biometric check, meaning the issuing bank receives the transaction payload with an authentication cryptogram already attached.
Consequently, the payment network does not trigger a secondary 3D Secure challenge window, preventing authentication abandonment while still granting the merchant a liability shift for fraudulent chargebacks across supported acquiring networks.
How are refunds processed for transactions containing device account numbers?
Refunding a transaction processed through a tokenised device network operates identically to a standard card refund within the gateway orchestration layer. The merchant initiates the refund against the original gateway order ID.
Cardflo communicates with the relevant acquirer partner, who maps the internal transaction reference to the specific device account number. The funds route back through the tokenisation network to the underlying physical card linked to the shopper device, requiring no manual intervention from the customer.
Can the orchestration layer route hardware tokens to different acquirers?
Yes, the encrypted payload containing the transaction cryptogram can route to multiple endpoints based on the merchant configuration.
Cardflo manages the merchant certificate and handles the initial gateway interaction, passing the tokenised data to the optimal acquirer partner according to transaction currency, risk parameters or regional acquiring logic.
This multi-acquirer strategy prevents a single point of failure and allows merchants to optimise their processing costs while maintaining a unified biometric checkout experience on the front end.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.