Watch a client fund an account on a phone. Card checkout means sixteen digits, an expiry, a CVV, a billing address, then a redirect to a bank app, then back. Wallet checkout means a double click and a fingerprint. The difference in completed deposits is not subtle, and it is the single strongest argument for putting the button on the page.
The weaker arguments are the ones firms usually repeat, so it is worth separating what these wallets genuinely change from what they only appear to change.
What is actually being sent
Apple Pay and Google Pay are not payment methods in the sense that a bank transfer is a payment method. They are a wrapper around a card that already exists. When a card is added to a phone, the card network issues a substitute number, a device account number in Apple's language, a network token more generally. The real card number never sits on the device and never reaches the merchant.
At payment time the wallet produces that token plus a one-time cryptogram, a short value that proves this specific device authorised this specific transaction. The merchant's payment provider forwards both. The issuer decrypts the cryptogram, maps the token back to the real account, and approves or declines as normal. Everything downstream, the interchange, the settlement, the dispute rights, still runs on card rails, which is why the wallets show up in reporting under the same interchange categories as any other card payment.
One consequence worth remembering: if the client's card is closed or reissued, the token usually updates automatically. That matters more for recurring billing than for one-off deposits, but it is a real operational benefit.
Why approval rates tend to improve
Card deposits for trading firms fail at rates that would horrify a normal e-commerce merchant. Some of that is the merchant category. A lot of it is data quality: a mistyped expiry, a billing address that no longer matches, a card the customer stopped using.
Wallet payments arrive with none of those problems. The card data came from the issuer's own provisioning process, the address comes from the wallet, and the cryptogram tells the issuer the cardholder was physically present with an authenticated device. Issuers generally treat that risk signal favourably. Firms that already track approval rates by method usually find the wallet line sits above the plain card line, and that the gap is widest on mobile.
Higher approval on the same acquirer is a genuine gain. It is not a route around a declining acquirer. If a payment provider is throttling a trading merchant because of dispute ratios or category risk, adding a wallet button changes the front end and nothing else.
The authentication question
In Europe, PSD2 requires strong customer authentication on most electronic payments: two factors from possession, knowledge and inherence. A wallet transaction carries possession, the provisioned device, and inherence, the biometric that unlocked it. That combination is normally treated as satisfying SCA, which is why a wallet payment usually skips the separate 3D Secure screen that a manual card entry triggers.
For the client, that is one less redirect and one less abandoned deposit. For the firm, it also affects liability on fraud disputes. An authenticated wallet transaction is a poor candidate for a chargeback claiming the cardholder never authorised it. What it does nothing about is the other kind of dispute, the one where the client admits paying and argues about the service they received. In trading that is the more common complaint, and the way those disputes are decided is unchanged by the wallet.
Where trading firms hit the wall
Here is the part nobody mentions in the integration guide. Neither wallet decides whether a business may accept payments. The acquirer does. A broker, a prop firm or an education business sits under a merchant category code that a large share of acquirers will not board at all, and the ones that will apply reserves, volume caps and pricing that reflect the category. That decision happens before wallets enter the conversation, and it is the same decision covered in high-risk merchant accounts.
Two more practical constraints. Apple Pay on the web requires the merchant domain to be verified, which means hosting a verification file on the exact domain that renders the checkout, so a firm serving a payment page from a third domain has to repeat that work per domain. And both wallets are deposit paths only. A refund reverses to the card account behind the token, but once the refund window closes, payouts leave through a card credit or a bank transfer, which is a separate payout rail with its own timing and its own limits.
Is it worth adding
For a firm whose clients deposit from phones, yes, and the integration is usually days rather than weeks because the payment provider already supports both. The gain is at the top of the funnel, in deposits that would otherwise be abandoned halfway through a card form.
For a firm still fighting to keep a card account open, the wallet button is the wrong project. Fix the dispute ratio, fix the descriptor, fix the refund policy, then add convenience on top of something stable. And whichever way the deposit arrives, the record has to land in the client file with the method attached, because when an acquirer asks why disputes cluster in one segment, the answer lives in that data. Keeping deposits, methods and client history in one back office is what makes that question answerable.
"Everyone asks us to add the wallet buttons first. I ask what their card approval rate looks like today. If it is bad because the acquirer is nervous, a nicer button on a broken rail just gets you declined faster."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Apple Pay and Google Pay are network tokens over an existing card, so interchange, settlement and dispute rights all still run on card rails.
- Approval rates usually rise because the card data is issuer-provisioned and the device cryptogram gives the issuer a strong authentication signal.
- Wallet payments normally satisfy PSD2 strong customer authentication on their own, removing the separate 3D Secure step and weakening unauthorised-transaction disputes.
- Access is decided by the acquirer and the merchant category, not by the wallet, and payouts still need a separate rail because clients cannot withdraw to a wallet.
Frequently Asked Questions
Can a broker or prop firm accept Apple Pay and Google Pay?
Only if its acquirer already accepts the business. The wallets are a presentation layer over a card account, so they inherit whatever merchant category code and risk decision the acquirer applied. A firm that cannot get a card account for its category will not solve that by adding a wallet button, and a firm that already has a stable card account can usually switch the wallets on through its payment provider.
Do Apple Pay and Google Pay reduce chargebacks?
They reduce one type. Because the payment carries device authentication and a network token, disputes claiming the cardholder did not authorise the transaction are much harder to sustain. What the wallets do not touch is the dispute where the customer accepts they paid but argues about the service, which in trading is the more common complaint.
Can clients withdraw back to Apple Pay or Google Pay?
Not as a wallet. A refund reverses to the underlying card account behind the token, and beyond the refund window most firms pay out through a card credit to the original card or through a bank transfer. Wallets are a deposit path, so payout planning has to be done separately.