Part V: Alternative Payment Methods (APMs)
Chapter 22 — Wallets, Super Apps & Closed-Loop Payments
It's Monday morning. Mei, FreshCart's finance lead, opens her laptop and pulls up three dashboards — one for each payment provider the company ran over the weekend.
Dashboard one: Stripe. She sees 847 Apple Pay transactions from their Singapore pop-up stores. They ran as card payments; settlement is queued, and the money lands in the bank account midweek. Clean, predictable, done.
Dashboard two: WeChat Pay's merchant portal. 312 transactions from the Hong Kong Mini Program. Callbacks verified, settlement pending T+1. But one transaction has a red flag — a failed signature verification that needs investigating.
Dashboard three: PayPal Business. 94 cross-border transactions, mostly from expats ordering meal kits online. Two open disputes stare back at her. One "Item Not Received," one "Significantly Not as Described." Evidence deadline: Thursday.
Same company. Same weekend. Three parallel payment universes.
Why does accepting "wallets" feel like running three separate businesses? Because these aren't three flavors of the same thing. They're three fundamentally different architectures wearing the same label. The settlement timelines are different. The dispute rules are different. The fee structures are different. Even the definition of what happened is different — one was a card payment in disguise, one was a closed-loop ledger entry, and one was an account-based transfer mediated by a platform.
In this chapter, you'll learn to see through the label. By the end, you'll be able to pick up any wallet — Apple Pay, Google Pay, WeChat Pay, Alipay, PayPal, GrabPay, whatever comes next — and immediately ask the three questions that actually matter: Who controls authentication? Who owns the settlement rail? And who arbitrates disputes? Those three answers determine your real cost, your conversion rate, and your operational burden as a merchant.
Let's start by taking apart the word "wallet" itself.

What Is a Wallet, Really?
Ask ten people in payments what a "digital wallet" is and you'll get twelve answers. That's because "wallet" has become a catch-all term for anything that lets you pay without typing in a card number. But if you want to understand what's actually happening to your money — and your liability — you need a sharper lens.
Every digital wallet, no matter how different it looks on the surface, does three jobs.
The Three Jobs
Job one: credential storage. A wallet holds something valuable on your behalf. It might be a tokenized version of your credit card (called a DPAN — a Device Primary Account Number, essentially a stand-in for your real card number that only works on your specific device). It might be a balance you've loaded with real money. It might be a vaulted bank account or a saved PayPal login. The point is, the wallet is a container — and what's inside that container varies wildly from one wallet to the next.
Job two: authentication. When you're ready to pay, the wallet needs to prove you're you. Apple Pay does this with your face or fingerprint via the device's biometric sensors. WeChat Pay does it through your app login and a payment PIN. PayPal redirects you to a login screen. Each approach has different security properties, different friction levels, and different implications for who bears liability if something goes wrong.
Job three: presentation. The wallet packages the credential and the authentication proof into something the merchant (or the merchant's payment processor) can actually use. Apple Pay transmits a one-time cryptogram alongside the DPAN over NFC or through a web API. WeChat Pay signs an API callback. PayPal returns an order approval token. This is the handoff — the moment the wallet's job ends and the payment rail's job begins.
Here's what those three jobs look like across FreshCart's three wallets:
| Apple Pay | WeChat Pay | PayPal | |
|---|---|---|---|
| Credential Storage | Tokenized card (DPAN) in device Secure Element | Platform balance or linked bank card, held on WeChat's servers | Vaulted bank account, card, or PayPal balance tied to user account |
| Authentication | Device biometric (Face ID / Touch ID) — no password, no redirect | App login + payment PIN or fingerprint within the WeChat app | Email/password login via redirect or popup, optional 2FA |
| Presentation | DPAN + per-transaction cryptogram via NFC or web token | Signed API callback with encrypted payment confirmation | Order approval token via JS SDK, captured by merchant backend |
Same three jobs. Completely different implementations.
The Fourth Question
But here's the thing those three jobs don't tell you: what rail does the money actually move on?
When FreshCart's customer taps Apple Pay at the Singapore pop-up, the DPAN gets detokenized back into a real card number by the card network. From that point on, it's a standard Visa or Mastercard authorization. The money moves on card rails — interchange fees, scheme fees, acquirer markup, T+1 or T+2 settlement, card-network dispute rules. Apple Pay is a beautiful front door, but behind it, the plumbing is the same card infrastructure you already know from earlier chapters.
When a customer pays through WeChat Pay's Mini Program in Hong Kong, something very different happens. There's no card network involved. WeChat Pay's backend processes the transaction on its own ledger, verifies it cryptographically, and sends a callback to FreshCart's server. The money settles through WeChat's own banking relationships. Disputes don't follow Visa's chargeback rules — they follow whatever contract FreshCart signed with its WeChat Pay acquiring partner.
And when a PayPal customer checks out online, the money moves through PayPal's account-based system. The underlying funding might come from a card, a bank account, or a PayPal balance — but the merchant's relationship is with PayPal. PayPal runs its own dispute resolution process, with its own evidence requirements and its own deadlines. That's why Mei has disputes in her PayPal dashboard that look nothing like the chargebacks she handles through Stripe.
This is why "wallet" is a misleading singular noun. The container looks similar from the outside, but the rail underneath determines everything that matters to your business: what you pay, when you get paid, and who you call when something goes wrong.
Think of it this way: a wallet is like a car's ignition system. Turning the key (or pressing the button) is the authentication. The key itself is the credential. But whether you're starting a gasoline engine, an electric motor, or a hydrogen fuel cell — that's the rail. Same interface, completely different machinery.
So as you evaluate any wallet for your business, don't stop at the three jobs. Ask: What credential is stored? How is the payer authenticated? How is the credential presented? And then the one that really matters: What rail does the money actually move on?
Let's trace a single payment through each of FreshCart's three wallets so you can see the machinery for yourself. First up: Apple Pay, and the split second between tap and beep.
Apple Pay: The Device-Native Card Overlay
It's a Saturday afternoon at FreshCart's pop-up store in Tanjong Pagar. A customer picks up a cold-pressed juice and a bag of granola, walks to the counter, and holds her iPhone near the payment terminal. Face ID scans. A quiet beep. The screen reads "Done." Total elapsed time from tap to approval: about two seconds.
Two seconds. And in those two seconds, here's what actually happened.
Her iPhone's Secure Element — a tamper-resistant chip physically embedded in the device — selected the DPAN (Device Primary Account Number) associated with her default card. This DPAN isn't her real card number. It's a token that only works on this specific device, issued by the card network when she first added her card to Apple Pay. Alongside the DPAN, the Secure Element generated a one-time cryptogram — a unique, mathematically derived code that proves this transaction is fresh and hasn't been replayed from a previous capture.
The Secure Element transmitted the DPAN and cryptogram to the NFC terminal via a short-range radio signal. The terminal passed this data to FreshCart's payment service provider (in this case, Stripe acting as PSP and acquirer). Stripe formatted the authorization request and sent it to the card network — Visa, Mastercard, whichever network the card runs on.
Here's the critical step: the card network detokenized the DPAN. It looked up the mapping between the device-specific token and the customer's real PAN (Primary Account Number) and forwarded the authorization request, now carrying the real card number, to the issuing bank — the bank that gave the customer her card.
The issuing bank ran its fraud checks, confirmed the customer had sufficient credit, and sent back an approval. That approval traveled back through the network, through Stripe, through the terminal, and onto the customer's screen. Done.
Why the DPAN Matters
Notice what didn't happen: the customer's real card number was never stored on her phone. It was never transmitted over NFC. There's no static CVV to steal. If someone managed to intercept the NFC signal, they'd capture a DPAN that only works on that specific iPhone and a cryptogram that's already been used. Replaying it would fail instantly.
This is why Apple Pay is fundamentally more secure than tapping a physical card. A contactless plastic card transmits the real PAN over NFC every single time. Apple Pay never does. The tokenization layer neutralizes entire categories of fraud — skimming, replay attacks, and breached card-on-file databases all become irrelevant for the Apple Pay credential.
The Business Model You Don't See
Here's something that surprises most merchants: Apple doesn't charge you a cent. There's no Apple Pay fee on your processing statement. Instead, Apple earns a small basis-point fee from the issuing bank on each transaction — a revenue share negotiated as part of the deal for banks to participate in Apple Pay. The exact amount varies by market and is rarely disclosed publicly, but it's widely reported to be around 15 basis points in the US (roughly $0.15 on a $100 transaction).
As a merchant, you pay the same card-processing costs you'd pay for any card transaction: interchange, scheme fees, and your acquirer's markup. Apple Pay transactions show up in your Stripe dashboard (or whoever your processor is) looking exactly like card payments — because that's what they are, once the DPAN is detokenized.
Settlement and Disputes
Settlement follows the standard card lifecycle. For FreshCart in Singapore, that's typically T+1 or T+2 depending on the acquirer arrangement. Chargebacks follow card-network rules — Visa's or Mastercard's dispute resolution process, not Apple's. If a customer disputes an Apple Pay transaction, Mei handles it the same way she'd handle any card chargeback. Apple is not involved in the dispute.
This is both a strength and a limitation. The strength: if you already know how to handle card payments, Apple Pay adds zero operational complexity. The limitation: you get none of the potential benefits of a closed-loop system (like faster settlement or simpler dispute resolution).
The Online Variant
Apple Pay isn't just for tapping at terminals. When FreshCart's Singapore customers order meal kits on Safari, the Apple Pay button appears on the checkout page. The flow is different in form but identical in substance: the Apple Pay JS API triggers a payment sheet, the customer authenticates with Face ID, and the browser generates an encrypted payment token containing the DPAN and cryptogram. FreshCart's backend sends this token to Stripe, which decrypts it and processes the authorization through the same card-network pipeline. Same rails, different doorway.
An Operational Detail Worth Knowing
One thing FreshCart's engineering team learned the hard way: Apple Pay payment processing certificates expire every 25 months. If you miss the renewal, Apple Pay stops working — silently, without a dramatic error message. It just fails. If you accept Apple Pay, put the certificate expiry date on your team calendar and treat it like renewing your SSL certificates.
The Conversion Argument
So why bother? Because friction kills conversion. Stripe reports approximately a 2x increase in checkout conversion when Apple Pay is surfaced as an "express checkout" option early in the flow — above the fold, before the customer reaches the card-entry form — compared to burying it at the bottom. When you eliminate seventeen form fields and replace them with a glance at your phone, more people finish buying.
What Apple Pay Is Not
Let's be precise about what Apple Pay is and isn't. Apple Pay is not a payment network. It's not an acquirer. It's not a closed-loop system. It doesn't hold your money, doesn't settle transactions, and doesn't resolve disputes.
Apple Pay is a superior authentication and credential-delivery layer built on top of existing card rails. It makes the front door better — faster, more secure, higher-converting — but behind that door, the plumbing is the same card infrastructure that has been clearing and settling transactions for decades.
That's why Mei's Stripe dashboard treats Apple Pay transactions identically to card-present and card-not-present transactions. Because architecturally, that's exactly what they are.
Now let's look at something fundamentally different. When FreshCart's Hong Kong customer opens WeChat and taps "Pay," no card network is involved at all.
WeChat Pay: Payments Inside a Super App
A FreshCart customer in Hong Kong opens WeChat — the same app she uses to message friends, read news, and hail taxis. She taps into FreshCart's Mini Program (a lightweight app-within-an-app that lives inside WeChat), browses the weekly meal kit selection, adds a salmon poke box to her cart, and taps "Pay." A payment sheet slides up showing the total. She confirms with her fingerprint. Done. She never left WeChat.
What just happened is architecturally unlike anything in the Apple Pay flow.

The Machinery Behind the Tap
When the customer tapped "Pay," FreshCart's backend server called WeChat Pay's Unified Order API, passing the order amount, a description, and a callback URL — the address where WeChat Pay should send the payment confirmation later. WeChat Pay's server validated the request, created a payment record, and returned a prepay_id — a temporary identifier representing this pending transaction.
FreshCart's backend took that prepay_id, signed it with a set of parameters (a timestamp, a random nonce, and the app ID), and sent these signed payment parameters back to the Mini Program running on the customer's phone. The Mini Program invoked the JSAPI — WeChat's JavaScript payment interface — which triggered the payment sheet the customer saw.
After the customer confirmed with her fingerprint, the Mini Program sent the signed parameters to WeChat Pay's processing engine. WeChat Pay debited the customer's linked funding source (a balance, a bank card, whatever she had configured), and then came the step that defines this architecture: WeChat Pay sent an encrypted callback notification to FreshCart's server at the callback URL registered earlier.
This callback is encrypted using AEAD_AES_256_GCM — a modern authenticated encryption standard that ensures the notification hasn't been tampered with and came from WeChat Pay, not an impersonator. FreshCart's callback server verified the digital signature in the HTTP headers (checking the Wechatpay-Serial and Wechatpay-Signature fields against the timestamp and nonce), decrypted the payload, confirmed the amount matched the original order, and updated the order status to "paid." Only then did FreshCart trigger fulfillment — boxing the salmon poke and queuing it for delivery.
Why This Works Differently
Notice what's missing from this flow: there's no card network. No acquirer in the traditional sense. No detokenization step. WeChat Pay processes the transaction on its own infrastructure and settles through its own banking relationships. The merchant's primary technical relationship is with WeChat Pay's API — not with Visa, not with Mastercard, not with a traditional payment gateway.
The Super-App Context
To understand why WeChat Pay is so dominant, you need to understand what WeChat is. Weixin (its Chinese name) and WeChat together exceed 1.3 billion monthly active users. It's not just a messaging app — it's the operating system of daily life for much of China and a growing share of the Chinese diaspora in Hong Kong and Southeast Asia.
People wake up, check WeChat messages, read articles on WeChat's newsfeed, hail rides through Mini Programs, order food through Mini Programs, split dinner bills in group chats, and pay at street vendors by scanning QR codes — all without leaving the app. Payment isn't a separate activity you think about. It's a feature inside a daily habit. That's the source of WeChat Pay's stickiness, and it's something no standalone payment app can easily replicate.
Combined with Alipay, WeChat Pay accounts for roughly 90% of China's mobile payment market, according to the Bank for International Settlements. That's not a market share — it's a duopoly.
Merchant Fees
WeChat Pay's domestic merchant fee is commonly around 0.6% for most categories in mainland China — significantly lower than card-network interchange in most Western markets. Cross-border arrangements, including Hong Kong's, vary depending on the acquiring partner and the specific contract. FreshCart's HK arrangement runs through a local acquirer, and the fee structure looks different from the flat domestic rate.
The Security Model: Not Optional
If you're integrating WeChat Pay, you need to understand that the cryptographic security model is not optional. It's not a nice-to-have that you can skip for an MVP. WeChat Pay's API v3 requires:
- Request signing — every API call from your server must be signed with your merchant private key
- Signature verification — every response and callback from WeChat Pay must be verified against WeChat Pay's platform certificate
- Callback encryption — payment notifications are encrypted with AEAD_AES_256_GCM, and your server must decrypt them before processing
The HTTP headers on each callback include a Wechatpay-Serial (identifying which platform certificate to use for verification), a Wechatpay-Signature, a timestamp, and a nonce. Get any of these wrong, and your integration silently fails — which is exactly what happened to FreshCart's flagged transaction that Mei saw in her dashboard on Monday morning.

Certificate Lifecycle: A Ticking Clock
WeChat Pay platform certificates have a five-year validity period. That sounds like a long time, until you realize that five years is exactly long enough for the engineer who set up the integration to have changed jobs twice. WeChat Pay's partner documentation explicitly warns about outage risk from delayed certificate rotation.
FreshCart's SRE team learned to treat WeChat Pay certificate lifecycle as a first-class operational concern — right alongside SSL certificate renewals and API key rotations. If the platform certificate expires and you haven't rotated to the new one, your callback verification fails, and every transaction looks like potential fraud.
Disputes: Don't Assume "No Chargebacks"
A common misconception about WeChat Pay is that there are no chargebacks. This is dangerously wrong.
Dispute and chargeback rules are contract- and jurisdiction-dependent. The Bank of China (Hong Kong) merchant acquiring schedule for WeChat Pay explicitly defines chargeback procedures, investigation letter timelines, and merchant obligations. The rules may look different from Visa's — different evidence requirements, different deadlines, different escalation paths — but the exposure is real. If you're accepting WeChat Pay through a cross-border or Hong Kong acquiring arrangement, read your merchant agreement carefully. The chargeback section is not theoretical.
What WeChat Pay Is
WeChat Pay is a closed-loop payment ecosystem embedded in a super app. Identity, commerce, and payment are fused into one surface. Even when the underlying funding source is a bank card or a bank account, the merchant experience is dominated by WeChat's API, WeChat's callbacks, and WeChat's rules. You're not plugging into the card-network infrastructure — you're plugging into WeChat's commercial operating system.
That's two down. Now let's look at the third universe in Mei's Monday-morning dashboard: the PayPal disputes waiting for evidence by Thursday.
PayPal: The Account-Based Checkout Network
A British expat living in Singapore wants to order FreshCart's weekend meal kit. He doesn't have a local Singapore bank card — his finances are still anchored in the UK. He browses FreshCart's website, fills his cart with a Thai green curry kit and a bag of organic chia seeds, and reaches the checkout page. There, between the credit card form and the "pay with bank transfer" option, he sees the familiar blue PayPal button. He clicks it.
A PayPal window pops up. He logs in with his email and password, confirms the shipping address, and clicks "Pay Now." The window closes, and FreshCart's checkout page shows "Order Confirmed." He never typed a card number. He never created a Singapore-specific account for anything. PayPal bridged the gap.
What Actually Happened
FreshCart's checkout page loaded the PayPal JS SDK — a JavaScript library that renders the PayPal button and handles the client-side interaction. When the customer clicked the button, the SDK opened a PayPal approval window in a new browser context. The customer logged into PayPal, reviewed the order details, and approved the payment.
At this point, PayPal returned an order approval — essentially a confirmation that the buyer has authorized this specific amount — back to the JS SDK, which passed it to FreshCart's frontend via an onApprove callback. FreshCart's frontend then called its own backend server, which made a server-to-server API call to PayPal's Orders v2 API to capture the payment. This capture step is when the money actually moves — the approval alone doesn't transfer funds.
PayPal confirmed the capture, and separately sent a webhook event (a server-to-server notification, much like WeChat Pay's callback) to FreshCart's webhook endpoint. This webhook serves as a safety net: even if the frontend-to-backend communication glitches, the webhook ensures FreshCart's system eventually learns that the payment was captured. FreshCart's backend verified the webhook signature, updated the order state, and triggered fulfillment.
The Scale of PayPal's Network
PayPal processed $1.79 trillion in total payment volume in FY2025, with 439 million active accounts globally. About 37% of that volume comes from outside the US. For FreshCart's British expat, PayPal works precisely because it's an account he already has — no local card needed, no new onboarding. That's the power of a global account-based network.
A Fundamentally Different Business Model
Here's the structural difference that matters most to merchants: PayPal charges you directly. Unlike Apple Pay, where Apple earns from issuers and the merchant pays standard card-rail costs, PayPal's revenue comes primarily from merchant transaction fees. The fee varies by country, product tier (standard checkout, advanced processing, marketplace), and whether the transaction is domestic or international.
This means PayPal is directly incentivized to monetize checkout. Every time a buyer clicks that blue button, PayPal earns. This incentive explains both PayPal's aggressive pursuit of checkout placement and the occasional tension between PayPal's interests and the merchant's interest in steering customers toward lower-cost payment methods.
Don't treat PayPal's fees as a single number. Published fee schedules vary significantly by market and product. Always validate against your actual merchant contract.
Tokenization: Account-Based, Not Network-Based
PayPal offers vaulting — the ability to save a customer's payment method for future purchases, with the customer's consent. But this isn't the same kind of tokenization as Apple Pay's DPAN. PayPal's model is account-based vaulting: the saved credential is tied to the customer's PayPal account and the merchant's integration, not to a specific device or a card-network-issued token. If a FreshCart customer opts in, PayPal remembers their payment method so the next order is even faster — but the token is a PayPal construct, not a Visa or Mastercard construct.
The Dual-Track Dispute Problem
This is where things get operationally complex. PayPal runs its own dispute resolution system — completely separate from the card networks. If a buyer opens a dispute through PayPal ("Item Not Received" or "Significantly Not as Described"), PayPal adjudicates it. The merchant needs to provide evidence — proof of shipment, tracking numbers, delivery confirmation — within PayPal's deadlines.
But here's the wrinkle: if the buyer's funding source was a credit card, the buyer can also file a chargeback with their card issuer, bypassing PayPal's resolution entirely. This creates a dual-track liability. Mei might resolve a dispute successfully in PayPal's system, only to get hit with a card-network chargeback for the same transaction weeks later.
PayPal offers Seller Protection to shield merchants from certain dispute types, but eligibility has specific requirements. The transaction must ship to the PayPal-confirmed address. Proof of shipment (and for certain claims, proof of delivery) must be provided. Evidence deadlines must be met. FreshCart had to operationalize evidence collection — systematic capture of tracking numbers, delivery photos, and customer communications — because winning PayPal disputes requires documentation, not just good intentions.
What PayPal Is
PayPal is an account-based payment platform that owns the buyer relationship. When a customer logs into PayPal, PayPal controls the authentication, holds (or can hold) a balance, manages the payment method selection, and runs the dispute process. The merchant's relationship is with PayPal as an intermediary, not directly with the buyer's bank or card network.
PayPal monetizes both sides of this relationship: transaction fees from merchants, and trust and convenience for buyers. This two-sided model — plus 439 million accounts — is what makes PayPal's blue button valuable even when cheaper payment methods exist. For FreshCart's expat customer, PayPal wasn't the cheapest option. It was the only option that worked without a local bank account.
Three wallets. Three architectures. Same checkout page. Now that you've seen the machinery inside each one, let's step back and ask a bigger question: what's the real difference between a closed-loop system and an open-loop one — and why should you care?
Closed-Loop vs Open-Loop: Why It Matters
Payment systems exist on a spectrum, not in neat binary categories. At one extreme, you have fully closed-loop systems — a single operator controls the payer, the payee, the ledger, and the dispute process. Think of a Starbucks gift card: Starbucks issues the credit, stores the balance, processes the payment, and handles refunds. No intermediaries, no interoperability, total control.
At the other extreme, you have fully open-loop systems — interoperable networks with clear separation between issuers and acquirers. The card networks (Visa, Mastercard) are the textbook example: any issuing bank can issue a card, any acquiring bank can accept it, and the network handles the switching in between.
Most wallets live somewhere in the middle, and where they sit on this spectrum determines almost everything about your experience as a merchant.
| Fully Closed (Starbucks card) | Super-App Closed (WeChat Pay) | Account-Based (PayPal) | Card Overlay (Apple Pay) | Fully Open (Card networks) | |
|---|---|---|---|---|---|
| Who controls auth | Platform (balance check) | Platform (app login + PIN) | Platform (email + password) | Device (biometric) | Issuer (PIN, 3DS, etc.) |
| Settlement rail | Internal ledger | Platform banking relationships | PayPal ledger + underlying card/bank | Card network rails | Card network rails |
| Dispute resolution | Platform policy | Contract-dependent | PayPal + potential card chargeback | Card network rules | Card network rules |
| Merchant data access | Full (platform owns all data) | Limited by API scope | Limited by PayPal policies | Same as card (via PSP) | Standard card data |
| Consumer switching cost | Lose stored balance | Lose ecosystem (social, commerce, identity) | Lose saved methods + buyer protection history | Low (card still works without Apple Pay) | Low (any card works) |
| Merchant switching cost | N/A (proprietary) | High (API + Mini Program rebuild) | Medium (API integration swap) | Low (PSP manages) | Low (acquirer swap) |
The Economics of the Spectrum
Closed-loop operators capture more data and can monetize it — they see every transaction, every user behavior, every merchant interaction. WeChat Pay knows what its users buy, when, where, and from whom. That data fuels advertising, credit scoring, and merchant analytics. The trade-off: merchants are locked into the platform's terms, and consumers are locked into the platform's ecosystem.
There's a second, quieter revenue stream in closed loops: float. When customers load money into a stored-value wallet, that balance sits with the operator until it's spent — and idle money earns interest. PayPal discloses in its annual filings that it earns interest on customer balances; every gift card sold and not yet redeemed is an interest-free loan from the customer to the operator. But float income is fragile, because regulators can take it away with one rule. China did exactly that: since 2019, the People's Bank of China has required Alipay and WeChat Pay to park 100% of customer reserve funds at the central bank, earning nothing. Most e-money regimes (the EU's E-Money Directive, Singapore's Payment Services Act) similarly require customer funds to be safeguarded in segregated accounts. The lesson: never build a wallet business plan on float alone — treat it as a bonus that regulation can delete.
Open-loop systems trade data richness for interoperability and acceptance breadth. Visa doesn't know what you bought (the issuer does), but Visa is accepted at more than 150 million merchant locations worldwide, by its own count. Apple Pay inherits this breadth by riding on card rails — it works wherever contactless cards are accepted.
For FreshCart, the implications are concrete. Apple Pay delivers open-loop economics with friction reduction — you pay standard card costs but get higher conversion. WeChat Pay delivers closed-loop economics with ecosystem lock-in — potentially lower fees in China but a completely separate integration, reconciliation, and dispute stack. PayPal sits in the hybrid middle — an account-based closed loop running on open-loop card and bank funding.
The Walled Gardens Are Softening
Even the strongest closed loops are opening up. In 2024, Reuters reported that Alibaba began adding WeChat Pay to its marketplaces — a move that would have been unthinkable a few years earlier. When conversion becomes the bottleneck, even fierce competitors cooperate on payment acceptance.
On the regulatory side, the European Commission made Apple's NFC access commitments legally binding in 2024, requiring Apple to allow third-party payment apps to use the iPhone's NFC chip for contactless payments. The message to platform operators is clear: controlling access to the checkout is increasingly a regulated privilege, not an unchallenged right.
The Merchant Decision Matrix
FreshCart's product team gathers for a quarterly planning session. The question on the whiteboard: Which wallets should we support, in which markets, through which channels?
The answer isn't "all of them everywhere." Each wallet carries different integration costs, different economics, different conversion impacts, and different operational burdens. Here's how the three compare across the dimensions that actually matter to a merchant building a payments strategy:
| Apple Pay | WeChat Pay | PayPal | |
|---|---|---|---|
| What it is | Device-native card overlay | Super-app closed-loop ecosystem | Account-based checkout network |
| Typical cost | Standard card-rail fees (interchange + scheme + acquirer) | ~0.6% domestic China; cross-border varies by acquirer | Direct merchant fees (varies by country, tier, and product) |
| Integration complexity | Low — most PSPs handle it; certificate renewal every 25 months | High — API signing, callback encryption, cert lifecycle, Mini Program build | Medium — JS SDK + Orders API + webhook verification |
| Conversion impact | ~2x with express checkout placement (per Stripe) | Essential in China/HK markets; high in-app conversion | Strong for cross-border; trust layer for new merchants |
| Fraud and disputes | Card-network rules; enhanced security via DPAN + cryptogram | Contract-dependent; do not assume "no chargebacks" | Dual-track: PayPal disputes + potential card chargebacks |
| Best-fit reach | iOS users globally; strongest in US, UK, Australia, Singapore | China mainland, HK, expanding in SEA; Chinese diaspora | Global; 37% non-US volume; expats and cross-border |
| Regulatory risk | EU NFC access mandates; potential unbundling of defaults | China data/capital regulations; cross-border compliance | Licensing requirements vary by market |
| Reconciliation | Standard card reconciliation via PSP | Separate reconciliation against WeChat Pay portal/API | Separate reconciliation against PayPal dashboard/API |
| Best use case | Express checkout for iOS-heavy, card-paying markets | Market-entry requirement for China-facing commerce | Trust layer for cross-border and new-customer acquisition |
Where the Flows Diverge
Here's what happens after a customer chooses a payment method at checkout. Notice where the wallet path and the super-app path diverge from traditional card entry — and where the wallet path reconverges with card rails:
The card-entry and wallet paths converge at the card network — because a wallet like Apple Pay is just a better front door to the same rails. But the super-app path never touches the card network at all. That's the fundamental architectural fork that determines everything downstream: fees, settlement, disputes, and reconciliation.
The Practical Recommendation
Wallet choice is a portfolio decision, not an exclusive one. FreshCart's product team landed on this framework:
- iOS-heavy premium segment (Singapore pop-ups): Apple Pay as express checkout, surfaced early in the flow. Run A/B tests on button placement — the conversion lift justifies the effort.
- China-facing acquisition (Hong Kong Mini Program, Shenzhen expansion): WeChat Pay isn't a nice-to-have. It's a market-entry requirement. Budget for the integration and operational complexity upfront.
- Global e-commerce with diverse customers (website): PayPal as the trust and completion layer. It won't be the cheapest option, but for customers without local payment methods — like FreshCart's British expat — it's the difference between a sale and an abandoned cart.
All three coexist on the same checkout page. The customer picks the path that works for them. FreshCart's ops team manages three reconciliation streams. That's the cost of selling across payment universes.
Now that you have the frameworks to evaluate any wallet, let's look ahead. The checkout battle isn't over — it's accelerating.
What's Next: The Checkout Battle Ahead
The wallet landscape isn't settling into a stable equilibrium. The battle lines are shifting.
Super Apps and Embedded Finance
In markets where super apps dominate, payment is becoming a feature of a commercial operating system, not a standalone function. WeChat doesn't think of itself as a "wallet" — it's a platform where commerce, social interaction, and financial services are inseparable. This model is spreading. GrabPay in Southeast Asia, Paytm in India, and Mercado Pago in Latin America are all building toward the same fusion of identity, commerce, and payment. For merchants entering these markets, accepting the super-app payment method isn't a line item on a feature roadmap — it's the cost of doing business in that ecosystem.

BNPL Inside the Wallet Button
Buy Now, Pay Later is migrating inside wallet interfaces. PayPal surfaces Pay Later directly in its JS SDK — merchants who integrate PayPal checkout get BNPL as a funding option without additional work. Apple explored and then abandoned proprietary BNPL (Apple Pay Later was shut down in 2024), a signal that even platform giants prefer partnerships over balance-sheet credit risk. The trajectory is clear: BNPL is becoming "just another funding option" inside the wallet button, not a separate checkout flow. The Worldpay Global Payments Report 2025 tracks BNPL growing from $2.2 billion to $342 billion in global transaction volume between 2014 and 2024.
Cross-Border "Tourist Rails"
Both Alipay and WeChat Pay have enabled foreign card linking for visitors to China, allowing tourists to pay at domestic merchants without a Chinese bank account. This is the reverse of what FreshCart's British expat did with PayPal — instead of using a global platform to pay in a local market, Chinese super apps are opening their closed loops to pull in foreign spending. Meanwhile, PayPal's 37% non-US total payment volume share demonstrates that account-based networks have a natural cross-border advantage.
CBDCs as Competitive Pressure
China's e-CNY (digital yuan) is live and available in major cities, but adoption has lagged the private super-app payments that already serve the market. Network effects are hard to unseat — even for a central bank. The e-CNY represents competitive pressure on private wallets rather than an imminent replacement. It's a reminder that the state hasn't ceded control of the payment infrastructure, even if private platforms dominate the user experience today.
The Regulatory Trajectory
Regulators worldwide are signaling that "owning the checkout" may become a regulated privilege. The European Commission's 2024 decision making Apple's NFC access commitments legally binding was the most concrete example: third-party payment apps must be allowed to use the iPhone's NFC chip for contactless transactions. Potential unbundling of wallet defaults and interoperability requirements are on the regulatory agenda in multiple jurisdictions. For merchants, this means the competitive landscape could shift faster than integration cycles — a wallet that's dominant today might face mandatory interoperability requirements tomorrow.
The Meta-Trend: Authentication Is the Battleground
Zoom out far enough, and the pattern becomes clear. The checkout battle isn't really about who has the best app icon or the most users. It's about who can vouch for the payer with the least friction and the most security. Face ID is faster than a password. A biometric on a device is more secure than a PIN typed into a terminal. Whoever controls the most trusted, most frictionless authentication mechanism controls the default button position on the checkout page. And the default button position is where the money flows.
Wallets compete on how money moves. But the most disruptive "alternative" payment method of the past decade isn't a new rail at all — it's credit, repackaged as a checkout button. In the next chapter, we pull apart buy now, pay later — and explain why BNPL looks like a payment method but functions as a lending business.
Sources
Wallet Market Share and Adoption
- Worldpay Global Payments Report 2025 — digital wallet share: 53% of global e-commerce, 32% of global POS (2024)
Apple Pay
- Apple Merchant Integration Guide — DPAN flow, payment processing certificate 25-month expiry
- Apple Platform Security Overview — Device Account Number, Secure Element architecture
- EMVCo Payment Tokenization Specification — domain-restricted tokens, cryptogram pairing
- PCI Security Standards Council — tokenization as PAN substitution, PCI scope reduction
- Stripe Apple Pay Documentation — approximately 2x checkout conversion with express placement
WeChat Pay
- Tencent Holdings Annual Report — Weixin/WeChat exceeding 1.3 billion monthly active users (March 2024)
- Bank for International Settlements (BIS) — Alipay and WeChat Pay accounting for approximately 90% of China's mobile payments
- WeChat Pay API v3 Documentation — request signing, AEAD_AES_256_GCM callback encryption, header specifications
- WeChat Pay Partner Documentation — platform certificate 5-year validity, rotation guidance
- Tencent Cloud Mini Program Payment Documentation — JSAPI invocation, callback handling
- Bank of China (Hong Kong) WeChat Pay Merchant Acquiring Schedule — chargeback definitions and timelines
- Sixth Tone — WeChat Pay 0.6% domestic merchant commission
PayPal
- PayPal Holdings FY2025 Form 10-K — $1.79 trillion TPV, 439 million active accounts, 37% non-US volume
- PayPal Developer Documentation — JS SDK, Orders v2 API, webhook integration
- PayPal Seller Protection Policy — eligibility requirements, evidence standards
Competitive and Regulatory Developments
- Reuters — Alibaba adding WeChat Pay to its marketplaces
- Reuters — Apple Pay Later discontinuation (2024)
- European Commission (2024) — Apple NFC access commitments made legally binding
- ECB SPACE 2024 Study — euro area online payment growth trends
- Worldpay Global Payments Report 2025 — BNPL growth from $2.2 billion to $342 billion (2014–2024)