Digital wallet integration connects three technical layers: a device layer, where a network token replaces the card’s PAN using EMVCo tokenization; a payment gateway layer, where the token is transmitted via SDK or API alongside cryptographic payment data; and a bank authorisation layer, where the issuing bank validates the token and cryptogram before approving the transaction. The architecture differs by wallet type: pass-through wallets (Apple Pay, Google Pay) use network tokens provisioned by the card scheme, staged wallets (PayPal, Cash App) hold funds independently, and bank-linked wallets connect to a bank account via open banking.
Tapping a phone or card has become the default way people pay. Contactless made up more than 75% of all transactions on Mastercard’s network in 2025. So, for any platform processing payments, supporting digital wallets is now a baseline requirement. But digital wallet integration isn’t a uniform process. Pass-through wallets like Apple Pay, staged wallets like PayPal, and bank-linked wallets each connect to payment gateways and banks differently: different SDKs, token standards, and certification paths. This guide breaks down what that integration involves across three layers: the device, the payment gateway, and the bank.
Digital Wallet Types: Technical Integration Differences
Digital wallets differ by type, resting on three different money-movement models rather than three versions of the same one.
- A pass-through wallet — the near-universal default, with Apple Pay and Google Pay now compatible with roughly 92% of smartphones globally — carries a tokenized card credential over existing card rails.
- A staged wallet holds value in its own ledger and settles with the merchant separately.
- A bank-linked wallet moves money directly between bank accounts.
That underlying model is what makes the integrations in fintech development fundamentally different, since each model touches a different part of the payment infrastructure and a different set of rules.
The table below breaks down each type by how it stores value, how it connects to the gateway, how it reaches the bank, and what that means for integration complexity.
Wallet Type | How Value Is Stored | Gateway Connection | Bank Connection | Integration Complexity |
|---|---|---|---|---|
Pass-Through Wallet (Apple Pay, Google Pay, Samsung Pay) | No stored value; tokenised card credential provisioned by card scheme via push provisioning | Wallet SDK generates payment token + cryptogram; passed to gateway via Payment Request API or in-app SDK | Token sent to card scheme network; issuer validates cryptogram and authorises; standard card-present flow | Medium: SDK integration + merchant certificate registration + payment gateway support required |
Staged Wallet (PayPal, Cash App) | Funds held in wallet provider’s own ledger; may be funded by card, bank account, or balance | Wallet provider’s own payment API or redirect flow; gateway processes a tokenised representation of the wallet payment | Wallet provider settles with merchant via their own rails; bank involved only in wallet funding, not per-transaction authorisation | Low-Medium: wallet provider API integration; no card scheme tokenization required; settlement reconciliation complexity |
Bank-Linked Wallet (Bank app wallets, open banking wallets) | Directly linked to bank account; no stored value; payment triggers bank transfer | Open banking API (PSD2 / FDX) or bank-specific API initiates payment instruction | Direct bank-to-bank transfer via domestic payment rails (ACH, SEPA, Faster Payments); no card scheme involved | High: open banking API integration, bank authorisation redirect, payment status webhooks, reconciliation across rails |
Wallet Type
Pass-Through Wallet (Apple Pay, Google Pay, Samsung Pay)
Staged Wallet (PayPal, Cash App)
Bank-Linked Wallet (Bank app wallets, open banking wallets)
How Value Is Stored
No stored value; tokenised card credential provisioned by card scheme via push provisioning
Funds held in wallet provider’s own ledger; may be funded by card, bank account, or balance
Directly linked to bank account; no stored value; payment triggers bank transfer
Gateway Connection
Wallet SDK generates payment token + cryptogram; passed to gateway via Payment Request API or in-app SDK
Wallet provider’s own payment API or redirect flow; gateway processes a tokenised representation of the wallet payment
Open banking API (PSD2 / FDX) or bank-specific API initiates payment instruction
Bank Connection
Token sent to card scheme network; issuer validates cryptogram and authorises; standard card-present flow
Wallet provider settles with merchant via their own rails; bank involved only in wallet funding, not per-transaction authorisation
Direct bank-to-bank transfer via domestic payment rails (ACH, SEPA, Faster Payments); no card scheme involved
Integration Complexity
Medium: SDK integration + merchant certificate registration + payment gateway support required
Low-Medium: wallet provider API integration; no card scheme tokenization required; settlement reconciliation complexity
High: open banking API integration, bank authorisation redirect, payment status webhooks, reconciliation across rails
The wallet type selected at the architecture stage also determines which payment processing compliance framework governs the build. Pass-through wallets reduce PCI DSS scope because the PAN never reaches merchant infrastructure. Bank-linked wallets fall under PSD2 and open banking regulation in the EU, while staged wallets require reconciliation against the wallet provider’s settlement reports rather than standard card scheme reporting.
Network Tokenization: How Digital Wallets Replace Card Numbers
Network tokenization is the mechanism that lets a pass-through wallet transact without the real card number ever reaching the merchant. The card’s PAN is replaced by a device-specific token, so a captured payload is useless to an attacker and the merchant’s PCI DSS scope shrinks accordingly. Issuers also recognise these tokens as trusted card-present equivalents, which lifts authorisation rates and cuts false declines as Mastercard reports approval rates rising by up to 6% where tokenization is live, and Visa reports roughly 40% lower fraud on tokenized transactions versus the raw card number.
The mechanism behind this runs in two phases: provisioning the token once, then using it securely on every transaction.
Network Token Provisioning and Transaction Flow
Here is the full sequence of what happens when the card is first added, and what happens each time it pays.
Step | What Happens Technically |
|---|---|
Card registration | Users add cards to their wallets (Apple Pay, Google Pay). Device sends card PAN to the wallet provider’s Token Requestor system. |
Token Request | Token Requestor (Apple, Google, Samsung) sends tokenization requests to the card scheme Token Service Provider (Visa Token Service, Mastercard Digital Enablement Service, Amex Token Service). |
Identity & Risk Check | Card scheme routes request to issuing bank. The bank verifies card ownership, performs risk assessment, and may require cardholder step-up authentication (SMS OTP, biometric via push notification). |
Token Issuance | The card scheme generates a Device Primary Account Number (DPAN) — a 16-digit token unique to this device and wallet combination. DPAN is stored in the device’s Secure Element (hardware) or via Host Card Emulation (software). |
Payment Initiation | At payment, the device generates a single-use cryptogram (dynamic CVV equivalent) using the DPAN and a session key. The DPAN + cryptogram forms the payment credential presented to the merchant. |
Gateway Processing | Merchant’s gateway receives DPAN + cryptogram (not the real PAN). Gateway forwards to acquirer. Acquirer routes to card scheme. |
Token Detokenization | Card scheme’s Token Service Provider detokenizes the DPAN back to the real PAN, validates the cryptogram, and routes the authorisation request to the issuing bank. |
Authorization | Issuing bank receives real PAN + cryptogram validation result. Approves or declines. Response routes back through card scheme → acquirer → gateway → merchant in under 2 seconds. |
Step
Card registration
Token Request
Identity & Risk Check
Token Issuance
Payment Initiation
Gateway Processing
Token Detokenization
Authorization
What Happens Technically
Users add cards to their wallets (Apple Pay, Google Pay). Device sends card PAN to the wallet provider’s Token Requestor system.
Token Requestor (Apple, Google, Samsung) sends tokenization requests to the card scheme Token Service Provider (Visa Token Service, Mastercard Digital Enablement Service, Amex Token Service).
Card scheme routes request to issuing bank. The bank verifies card ownership, performs risk assessment, and may require cardholder step-up authentication (SMS OTP, biometric via push notification).
The card scheme generates a Device Primary Account Number (DPAN) — a 16-digit token unique to this device and wallet combination. DPAN is stored in the device’s Secure Element (hardware) or via Host Card Emulation (software).
At payment, the device generates a single-use cryptogram (dynamic CVV equivalent) using the DPAN and a session key. The DPAN + cryptogram forms the payment credential presented to the merchant.
Merchant’s gateway receives DPAN + cryptogram (not the real PAN). Gateway forwards to acquirer. Acquirer routes to card scheme.
Card scheme’s Token Service Provider detokenizes the DPAN back to the real PAN, validates the cryptogram, and routes the authorisation request to the issuing bank.
Issuing bank receives real PAN + cryptogram validation result. Approves or declines. Response routes back through card scheme → acquirer → gateway → merchant in under 2 seconds.
Network Token vs Gateway Token: Key Differences
The network token provisioning and transaction flow above is run by the card scheme, which is what separates a network token from the gateway token most engineers already use for stored cards and subscriptions. They look alike (both replace the PAN with a stand-in) but differ in who issues them, how far they reach, and what they do to authorisation rates and PCI scope.
Dimension | Network Token (EMVCo / Card Scheme) | Gateway Token (Stripe, Adyen, Braintree) |
|---|---|---|
Issued by | Card scheme (Visa Token Service, Mastercard MDES) | Payment gateway / processor |
Scope | Works across any merchant that accepts the card scheme | Works only within that gateway’s ecosystem |
PCI DSS scope impact | PAN never reaches merchant infrastructure; maximum scope reduction | Reduces storage risk but gateway still handles PAN at some point |
Authorization rate | Higher: issuer recognises token as a trusted card-present equivalent; fewer false declines | Standard: treated as card-not-present unless additional signals provided |
Portability | Portable: user can use same wallet at any merchant | Not portable: token is gateway-specific |
Use case | Apple Pay, Google Pay, Samsung Pay; in-app and tap-to-pay | Stored card-on-file for subscriptions, recurring payments within one gateway |
Dimension
Issued by
Scope
PCI DSS scope impact
Authorization rate
Portability
Use case
Network Token (EMVCo / Card Scheme)
Card scheme (Visa Token Service, Mastercard MDES)
Works across any merchant that accepts the card scheme
PAN never reaches merchant infrastructure; maximum scope reduction
Higher: issuer recognises token as a trusted card-present equivalent; fewer false declines
Portable: user can use same wallet at any merchant
Apple Pay, Google Pay, Samsung Pay; in-app and tap-to-pay
Gateway Token (Stripe, Adyen, Braintree)
Payment gateway / processor
Works only within that gateway’s ecosystem
Reduces storage risk but gateway still handles PAN at some point
Standard: treated as card-not-present unless additional signals provided
Not portable: token is gateway-specific
Stored card-on-file for subscriptions, recurring payments within one gateway
Payment Gateway Integration Layer: SDK, API, and Certification Requirements
On the payment gateway integration layer, the work shifts from how the system functions to what your team has to set up and get approved.
Each wallet exposes its own integration surface (a JavaScript API or a native SDK, sometimes both), but the code is rarely what holds a team up. The work that determines the timeline sits around the code: registering a merchant identity with the wallet provider, provisioning and rotating certificates, verifying domains, and passing the provider’s production-access review. These steps run on the wallet provider’s schedule, not the team’s, and can’t be parallelised away.
The table below maps each major wallet to its integration method, technical prerequisites, certification path, and realistic timeline.
Wallet | Integration Method | Technical Requirements | Certification / Registration | Timeline |
|---|---|---|---|---|
Apple Pay | JavaScript API (web) or PassKit SDK (iOS native) | Merchant domain verification via Apple; merchant identity certificate; TLS 1.2+ on all endpoints; payment processing certificate from acquirer | Apple Merchant ID registration; domain verification file hosted on merchant domain; certificate rotation every 25 months | 1–3 weeks including certificate provisioning |
Google Pay | Google Pay API (JavaScript for web, SDK for Android) | Google Pay API integration; payment gateway token request via gateway-specific gateway merchant ID; HTTPS required; no domain verification file needed | Google Pay production access approval (submitted via Google Pay & Wallet Console); typically 1–2 weeks | 1–2 weeks |
Samsung Pay | Android SDK (Native) or Web Checkout JavaScript SDK | Partner registration; Service ID and CSR (Certificate Signing Request); native Android environment. Web flow utilizes out-of-band push authentication to a Samsung mobile device. | Samsung Pay partner approval via Developer Console; registration of package names and secure keys linked to the gateway merchant profile. | 2–4 weeks (due to manual partner portal provisioning and verification) |
PayPal | PayPal SDK (JavaScript or mobile); PayPal REST API | PayPal client ID; webhook endpoint for payment confirmation; no card scheme tokenization; PayPal handles its own payment credential | PayPal developer account; no external certification; PayPal sandbox testing required before production | 3–5 days |
Bank-Linked (Open Banking) | Open banking API (Berlin Group, FDX, bank-specific); redirect or embedded flow | OAuth 2.0 / PKCE for bank authorisation redirect; payment initiation API; webhook for payment status; PSD2 SCA compliance for EU deployments | Open banking provider registration (Truelayer, Plaid, Yapily) or direct bank API access; each bank connection requires separate testing | 4–8 weeks per banking market |
Wallet
Apple Pay
Google Pay
Samsung Pay
PayPal
Bank-Linked (Open Banking)
Integration Method
JavaScript API (web) or PassKit SDK (iOS native)
Google Pay API (JavaScript for web, SDK for Android)
Android SDK (Native) or Web Checkout JavaScript SDK
PayPal SDK (JavaScript or mobile); PayPal REST API
Open banking API (Berlin Group, FDX, bank-specific); redirect or embedded flow
Technical Requirements
Merchant domain verification via Apple; merchant identity certificate; TLS 1.2+ on all endpoints; payment processing certificate from acquirer
Google Pay API integration; payment gateway token request via gateway-specific gateway merchant ID; HTTPS required; no domain verification file needed
Partner registration; Service ID and CSR (Certificate Signing Request); native Android environment. Web flow utilizes out-of-band push authentication to a Samsung mobile device.
PayPal client ID; webhook endpoint for payment confirmation; no card scheme tokenization; PayPal handles its own payment credential
OAuth 2.0 / PKCE for bank authorisation redirect; payment initiation API; webhook for payment status; PSD2 SCA compliance for EU deployments
Certification / Registration
Apple Merchant ID registration; domain verification file hosted on merchant domain; certificate rotation every 25 months
Google Pay production access approval (submitted via Google Pay & Wallet Console); typically 1–2 weeks
Samsung Pay partner approval via Developer Console; registration of package names and secure keys linked to the gateway merchant profile.
PayPal developer account; no external certification; PayPal sandbox testing required before production
Open banking provider registration (Truelayer, Plaid, Yapily) or direct bank API access; each bank connection requires separate testing
Timeline
1–3 weeks including certificate provisioning
1–2 weeks
2–4 weeks (due to manual partner portal provisioning and verification)
3–5 days
4–8 weeks per banking market
Apple Pay’s domain verification is the clearest example of why these requirements have to be mapped before the build.
While desktop web support has evolved (Apple now allows Apple Pay in third-party browsers like Chrome and Edge on modern macOS environments) the underlying security model remains rigid. Before Apple Pay will initialize in any browser, the merchant must host a domain association file at a specific path on their server. If that file is missing, Apple Pay simply doesn’t appear in the payment UI. There’s no error, no console warning, nothing for the developer to debug against, the button is just absent. A team that treats this as something to wire up post-integration loses days chasing a ghost problem, when the fix is a file that should have been hosted from day one.
Scoping these dependencies up front, including certificate lead times, domain files, production-access reviews, is what keeps a wallet integration on its fintech payment integration timeline.
Bank Integration Layer: Authorisation, Open Banking, and Account Linking
The bank layer is where the transaction is actually authorised or settled: where the money moves, or is approved to move. How much of it you build depends on the wallet type. For pass-through wallets, for example, there’s none to build at all, since the card scheme and acquirer handle the bank connection.
Each pattern below follows from the wallet type decided earlier, which is why that decision sets how much bank-side work the project carries, and how much of it falls to the digital banking solutions team building the integration.
Bank Integration Pattern | How It Works | Used By | Technical Requirements |
|---|---|---|---|
Card Scheme Authorisation(pass-through wallets) | Network token sent to card scheme; scheme detokenizes to PAN; authorisation request routed to issuing bank via standard card network rails; bank approves or declines | Apple Pay, Google Pay, Samsung Pay — any wallet using EMVCo network tokens | No direct bank API integration required; bank connection handled via card scheme infrastructure; acquirer must support network token transactions |
Open Banking Payment Initiation(bank-linked wallets) | OAuth 2.0 redirect to bank for payment authorisation; Payment Initiation Service Provider (PISP) API sends payment instruction directly to bank; bank initiates domestic rail transfer | Bank-linked wallet apps, account-to-account payment wallets, EU wallets under PSD2 | PSD2 compliance (EU) or FDX / bank-specific API (US); OAuth 2.0 / PKCE implementation; SCA redirect handling; payment status webhook; reconciliation against bank statement (no card scheme involved) |
Account Information(balance display / wallet funding) | Account Information Service Provider (AISP) API reads bank account data with user consent; used to display balance, verify account ownership for wallet funding, or enable bank-funded top-up | Digital banking wallets showing multi-bank account balances; wallet funding verification; BNPL income verification | Separate AISP consent flow from PISP payment flow; read-only bank API access; consent management infrastructure; data refresh schedule and token expiry handling |
Bank Integration Pattern
Card Scheme Authorisation(pass-through wallets)
Open Banking Payment Initiation(bank-linked wallets)
Account Information(balance display / wallet funding)
How It Works
Network token sent to card scheme; scheme detokenizes to PAN; authorisation request routed to issuing bank via standard card network rails; bank approves or declines
OAuth 2.0 redirect to bank for payment authorisation; Payment Initiation Service Provider (PISP) API sends payment instruction directly to bank; bank initiates domestic rail transfer
Account Information Service Provider (AISP) API reads bank account data with user consent; used to display balance, verify account ownership for wallet funding, or enable bank-funded top-up
Used By
Apple Pay, Google Pay, Samsung Pay — any wallet using EMVCo network tokens
Bank-linked wallet apps, account-to-account payment wallets, EU wallets under PSD2
Digital banking wallets showing multi-bank account balances; wallet funding verification; BNPL income verification
Technical Requirements
No direct bank API integration required; bank connection handled via card scheme infrastructure; acquirer must support network token transactions
PSD2 compliance (EU) or FDX / bank-specific API (US); OAuth 2.0 / PKCE implementation; SCA redirect handling; payment status webhook; reconciliation against bank statement (no card scheme involved)
Separate AISP consent flow from PISP payment flow; read-only bank API access; consent management infrastructure; data refresh schedule and token expiry handling
In-Person, In-App, and Web: Integration Architecture by Context
The same wallet behaves differently across deployment contexts, and each carries its own hardware, certification, and browser constraints. Supporting two contexts means two builds, and some combinations carry sharp ecosystem constraints (such as Apple Pay web deployments requiring distinct domain verification structures).
The context usually isn’t yours to pick because it follows from where the customer pays, so the integration has to match the product. The table below breaks down the four contexts by the technology each uses, what it requires, and the key constraint to plan around.
Context | Technology | Technical Requirements | Key Integration Consideration |
|---|---|---|---|
In-Person (Tap-to-Pay) | NFC (Near Field Communication) with Secure Element; or HCE (Host Card Emulation) for software-based NFC | NFC-enabled POS terminal; EMV contactless certification; terminal must support network token transaction type; payment terminal SDK integration | HCE reduces hardware dependency but requires a cloud-based token service and always-on network connection at point of sale |
In-App Payment | Apple Pay via PassKit framework (iOS); Google Pay SDK (Android); Samsung Pay SDK | Native SDK integration per platform; merchant certificate (Apple) or gateway merchant ID (Google); 3DS2 if required by issuer; biometric authentication handled by device OS | Payment sheet UI is rendered by the OS, not the app — no custom UI required; biometric auth is handled natively; reduces friction significantly vs card form |
Web (Browser-Based) | Payment Request API (W3C standard); Apple Pay JS API; Google Pay JavaScript API | HTTPS required; domain verification (Apple Pay); gateway-specific JavaScript integration; Payment Request API browser compatibility testing | Apple Pay now supports third-party desktop browsers (Chrome/Edge) on modern macOS, while Google Pay is natively cross-platform. Samsung Pay web checkout is rarely implemented as a standard desktop UI, as it requires the user to manually enter a Samsung ID or scan a QR code to authorize via an out-of-band mobile push notification. |
QR Code Payment | Wallet-generated QR (merchant scans) or merchant-generated QR (customer scans); varies by wallet provider | QR code generation or scanning library; wallet provider API for QR payload; typically no NFC hardware required | Common in APAC and emerging markets; less common in US/EU for card-scheme wallets; primary pattern for WeChat Pay and Alipay integrations |
Context
In-Person (Tap-to-Pay)
In-App Payment
Web (Browser-Based)
QR Code Payment
Technology
NFC (Near Field Communication) with Secure Element; or HCE (Host Card Emulation) for software-based NFC
Apple Pay via PassKit framework (iOS); Google Pay SDK (Android); Samsung Pay SDK
Payment Request API (W3C standard); Apple Pay JS API; Google Pay JavaScript API
Wallet-generated QR (merchant scans) or merchant-generated QR (customer scans); varies by wallet provider
Technical Requirements
NFC-enabled POS terminal; EMV contactless certification; terminal must support network token transaction type; payment terminal SDK integration
Native SDK integration per platform; merchant certificate (Apple) or gateway merchant ID (Google); 3DS2 if required by issuer; biometric authentication handled by device OS
HTTPS required; domain verification (Apple Pay); gateway-specific JavaScript integration; Payment Request API browser compatibility testing
QR code generation or scanning library; wallet provider API for QR payload; typically no NFC hardware required
Key Integration Consideration
HCE reduces hardware dependency but requires a cloud-based token service and always-on network connection at point of sale
Payment sheet UI is rendered by the OS, not the app — no custom UI required; biometric auth is handled natively; reduces friction significantly vs card form
Apple Pay now supports third-party desktop browsers (Chrome/Edge) on modern macOS, while Google Pay is natively cross-platform. Samsung Pay web checkout is rarely implemented as a standard desktop UI, as it requires the user to manually enter a Samsung ID or scan a QR code to authorize via an out-of-band mobile push notification.
Common in APAC and emerging markets; less common in US/EU for card-scheme wallets; primary pattern for WeChat Pay and Alipay integrations
Key Takeaways
- Choosing a wallet type determines the entire architecture. Selecting between pass-through, staged, or bank-linked wallets dictates the money-movement model, compliance framework, and underlying payment rails rather than just altering the frontend interface.
- Network tokenization improves performance. Replacing raw card PANs with device-specific EMVCo tokens lifts authorization rates by up to 6% and drops fraud by roughly 40% because issuers recognize them as trusted card-present equivalents.
- Network tokens offer greater interoperability than gateway tokens. Network tokens function across any merchant accepting the card scheme and keep PANs entirely off merchant infrastructure, whereas gateway tokens restrict use to a single processor’s ecosystem.
- Omitted non-code configurations halt deployment. Skipping administrative prerequisites like Apple Pay’s domain association file results in silent UI failures without error messages, extending integration timelines by days.
- Context dictates platform compatibility. Deploying web-based digital wallets introduces distinct browser behaviors. While Apple Pay now supports third-party desktop browsers (Chrome/Edge) on modern macOS environments, it still demands rigid domain association architecture. Google Pay remains the more flexible cross-platform standard across various OS and browser combinations.
- Bank-linked wallets increase development overhead. Opting for bank-linked wallets bypasses card scheme rails but introduces high integration complexity, requiring open banking APIs, OAuth 2.0 redirects, and manual reconciliation across domestic payment rails.
In short: Digital wallet integration speeds up checkout and cuts fraud, but teams must map out distinct token standards, compliance frameworks, and rigid certification pathways up front to avoid silent failures and deployment delays.
FAQ
How does digital wallet payment integration work?
Digital wallet integration connects three distinct layers: the device layer (where a token replaces the card number), the payment gateway layer (which transmits cryptographic payment data), and the bank authorization layer (where the issuer approves the transaction). The exact flow depends entirely on the wallet’s architecture. Pass-through wallets (like Apple Pay) route network tokens and dynamic cryptograms over standard card rails, staged wallets (like PayPal) utilize the wallet provider’s proprietary API and internal ledger, and bank-linked wallets leverage open banking APIs to initiate direct account-to-account transfers.
What is the difference between Apple Pay and Google Pay integration?
While both rely on EMVCo network tokenization and the W3C Payment Request API for web checkouts, their technical prerequisites and platform boundaries differ:
- Apple Pay: Requires domain verification (hosting an association file at a specific path) and an Apple-provisioned merchant identity certificate. While historically limited to Safari, it now supports third-party desktop browsers on modern macOS systems, though native iOS builds still strictly utilize the PassKit framework.
- Google Pay: Requires a gateway merchant ID registered via the Google Pay & Wallet Console. On the web, it works cross-browser across all major platforms (Chrome, Safari, Edge). Native Android builds utilize the Google Pay SDK.
Does digital wallet integration reduce PCI DSS scope?
Yes, significantly. When integrating pass-through wallets like Apple Pay or Google Pay, the customer’s real card PAN never reaches or traverses your infrastructure. Your servers only receive and process a device-specific token (DPAN) and a single-use cryptogram, which drastically minimizes your PCI DSS attack surface. While standard gateway tokens (like those from Stripe or Adyen) reduce card storage risks, network tokens offer maximum scope reduction because the raw PAN is completely abstracted from the transaction source.
What is Host Card Emulation (HCE) in digital wallet integration?
Host Card Emulation (HCE) is a software-based architecture for Near Field Communication (NFC) payments that stores payment credentials in the cloud rather than relying on physical, device-specific hardware. During a transaction, the device downloads a limited-use cryptogram from a cloud token service on demand.
HCE removes hardware dependencies, making it highly scalable across Android devices (and forms the basis of Google Pay’s Android architecture). However, unlike Apple Pay, which relies entirely on a hardware-isolated Secure Element, HCE requires a reliable network connection at the point of sale to fetch fresh cloud credentials.
How do open banking wallets integrate with payment gateways?
Open banking wallets bypass traditional card networks entirely by utilizing a Payment Initiation Service Provider (PISP) API to move funds directly from the payer’s bank account to the merchant’s account. To integrate this flow, your system must implement OAuth 2.0 with PKCE for secure bank authorization redirects and handle Strong Customer Authentication (SCA) prompts required by regulations like PSD2. Because transactions settle directly via domestic payment rails, your backend must rely on payment status webhooks for confirmation and reconcile against raw bank statements rather than card scheme reporting.
How long does digital wallet integration take?
Integration timelines vary heavily based on the underlying compliance, certificate provisioning, and testing requirements of each provider:
- PayPal SDK: Takes 3-5 days. Requires basic sandbox testing and developer account setup.
- Google Pay: Takes 1-2 weeks. Includes API integration and waiting for production console access approval.
- Apple Pay: Takes 1-3 weeks. Dependent on acquirer certificate provisioning and hosting the mandatory domain verification file.
- Samsung Pay: Takes 2-4 weeks. Unlike highly automated developer consoles, Samsung requires explicit partner portal registration, Certificate Signing Request (CSR) handling, and a manual partner approval process before issuing production credentials. Web checkout implementations are typically avoided due to complex cross-device user-authentication logic.
- Open Banking (Bank-Linked): Takes 4-8 weeks per banking market. This includes OAuth configuration, individual bank sandbox validation, and SCA compliance testing.
What is the Payment Request API and how does it relate to digital wallets?
The Payment Request API is a W3C browser standard designed to act as a unified, single entry point for digital wallets on the web. Instead of writing separate, fragmented JavaScript integrations for every individual wallet, developers implement this single API. The user’s browser then automatically checks device compatibility, detects which wallets are provisioned (e.g., Apple Pay in Safari, or Google Pay in Chrome/Edge), and natively surfaces the appropriate payment sheet to eliminate checkout friction.
What are the security requirements for digital wallet integration?
Maintaining a secure digital wallet architecture requires strict adherence to the following technical baselines:
- Transport Security: Enforced TLS 1.2+ across all merchant endpoints. HTTPS is strictly mandatory for web checkouts; Apple Pay will fail to load entirely over standard HTTP.
- Data Handling: Zero local storage of Device Primary Account Numbers (DPANs) or single-use transaction cryptograms post-authorization.
- Authentication & Verification: Merchant domain verification via a hosted association file for Apple Pay, and strict webhook signature validation for all asynchronous payment confirmation events.
- Open Banking Pipelines: Secure OAuth token storage infrastructure, PKCE enforcement for authorization code flows, and explicit SCA compliance.