Bitcoin Cards With Google Pay

<p>Google Pay - now mostly living under the Google Wallet name on Android phones - is the same tokenization game as Apple Pay with one extra twist: Google enforces device attestation. This list counts only cards whose operator documents Google Pay or Google Wallet support on a page we fetched and dated. The iOS mirror is the Apple Pay list.</p>

What counts as documented

We searched each operator's help center, fee pages, product pages and app-store listings for a statement that the card can be added to Google Pay or Google Wallet. Silence counts as no - the same rule the Apple Pay page uses. 100% of the tracked bitcoin cards pass that bar, against 95% documenting Apple Pay and 16 documenting ATM withdrawals at all.

The strongest evidence is a setup article. ether.fi walks Android users through card-number entry into Google Wallet and ends with OTP verification [1]. Product-page claims count too: Nexo's card page documents both wallets for its virtual card [4], Coinbase's help center documents adding the Coinbase Card to Apple Pay or Google Pay [5], and Revolut's cards page says "Just link them to Apple Pay or Google Pay" [6].

The strongest documented picks

ether.fi Cash leads the register and documents Google Pay in the same article as Apple Pay [1], with the same honest failure-mode notes: Google runs risk checks the operator cannot override. Fold pairs both wallets with BTC cashback on every purchase [3]. Krak Card documents both wallets and keeps the sale timing in your hands via its Spend Order [2].

What Android adds and takes away

The tokenization privacy story is identical to Apple's: merchants see a device token, never your card number [8]. What differs is the device gate. Google Wallet requires Play Integrity attestation - rooted phones and most custom ROMs fail it, which means a de-Googled Android device cannot use any of these integrations at all. For that audience the honest paths are a physical card or the programs that document contactless ATM withdrawals without needing your wallet at the terminal.

The gate is worth understanding rather than just accepting. Play Integrity checks that the Android build is certified, unmodified and (for the strictest level) historically compliant with security updates. Bitcoin-card users skew privacy-conscious, and a meaningful share of them run de-Googled phones - for exactly those users, Google Wallet is a closed door regardless of what the card program documents. Apple's Secure Element model has no equivalent software-attestation gate: the same card that refuses to provision on GrapheneOS works on a ten-year-old iPhone. This asymmetry is not an operator choice - no bitcoin card program can switch it off - so it belongs in the purchase decision, not the support ticket.

Wear OS inherits the same check: a Pixel Watch can carry the token, a rooted phone cannot provision one. And the gate is enforced per device, not per card - one user can hold the same card on an attested phone and a non-attested tablet, with the wallet working on exactly one of them.

Programs with a one-sided wallet story

Wallet support is a project timeline, not a permanent property of the card. Ethena Pay's homepage documents "Add to Apple Pay in seconds. Google Pay available soon" - it stays off this list until Google Pay is live. SolCard excludes its base Virtual card from both wallets and documents them only for Platinum. Where an operator documents both wallets, the card appears on both lists; where it documents one, it appears on exactly one.

The one-sided story cuts both ways: some programs document Google Wallet first in markets where Android dominates. Either way, a card that documents both wallets today can lose one if the BIN sponsor changes or the token service flags the program - and because the gate sits with Apple and Google, the operator may learn about a blockage from its users before its dashboard shows it.

How to read the table

The Pay column shows the documented wallets (Apple, Google or both); the ATM method column separates card-plus-PIN from contactless phone-wallet access; the ATM column carries the card-side fee where one is documented. The BTC sold column is the one the other wallet lists do not have: it shows when the card converts your bitcoin - at load, at each transaction, or only when you decide - because that timing, not the wallet, is what actually moves your bitcoin exposure. KYC is the level required to obtain the card, and regions the documented availability.

Live values from our database - details and caveats in each review. "-" = not published by the operator.

Fees do not change through the wallet. If the true-cost calculator prices a card at 2.3% on your spending profile, tapping through Google Wallet does not move that number - the load, FX and monthly fees all stay exactly where they were. What the wallet changes is terminal-level privacy and one-tap convenience. The fee guide keeps those layers separate, and how bitcoin cards work explains the rails underneath.

What the wallet does to your bitcoin exposure

The same logic that applies on the Apple side applies here, with one Android-specific wrinkle. Wallet taps are frictionless, and friction decides how much spending runs through a card. On a program whose documented sale timing is "per transaction", every frictionless tap sells bitcoin at that moment - the spread applies, the disposal is realized. On a program whose sale timing is "at load" or "manual", the tap just spends dollars. The Android wrinkle: because Google Wallet refuses non-attested devices, the tap-to-pay convenience gradient is steeper on Android - either the wallet works everywhere on that phone or nowhere, with no middle ground. That makes the sale-timing question even more decisive for Android users: if your phone will carry the token, pick a card whose conversion behavior you would be happy to run at volume.

The interaction with bitcoin cashback is the mirror image. On programs that pay BTC rewards per purchase, the wallet does not change the earn side at all - the reward posts per transaction regardless of interface. So the wallet decision on those cards is pure convenience: same rewards, faster payment, fewer card-number exposures. On convert-per-transaction cards it is a spending-behavior decision first. The register's reward column and the sale-timing column together answer "does the wallet help or hurt my stack" better than any wallet feature list.

The practical habits that keep a wallet working

Treat the wallet token as a perishable integration, not a permanent feature. Add the card and make one small payment at home before you depend on it abroad - the first tap is the test, and it surfaces device-attestation failures while you can still fall back on the plastic. When the card is reissued or you change phones, expect to re-provision from scratch; the old token does not migrate, and the verification step needs a reachable phone number or inbox. And when a tap fails at a terminal above the contactless floor, the fallback is the plastic or chip - not a retry loop, which just burns attempts on programs that count them.

One last boundary worth stating: nothing here is an endorsement of storing value on a wallet-tokenized card rather than spending it quickly. The token protects the number, not the balance. Whether you pay by chip or by phone, the operator holds the funds and the self-custody page documents the minority of programs where the balance stays under your keys - for everyone else, the standard advice holds: load what you plan to spend, and treat the wallet as a nicer door into the same house.

If you carry both ecosystems, the choice between this list and the Apple Pay list is mostly about the phone you already carry - the cards, fees and rewards are identical on both, and every program documented on one page documents the same payment rails. Where the two lists genuinely diverge is in which programs have completed which integration, and that difference is recorded per card rather than per wallet.

Sources

1. ether.fi help center - add card to Apple Wallet or Google Pay - accessed 2026-11-07
2. Krak Card FAQs - wallets and ATM - accessed 2026-11-07
3. Fold credit card page - instant provisioning to Apple Pay and Google Pay - accessed 2026-11-07
4. Nexo card page - Apple Pay and Google Pay supported - accessed 2026-11-07
5. Coinbase help - add Coinbase Card to Apple Pay or Google Pay - accessed 2026-11-07
6. Revolut cards page - link to Apple Pay or Google Pay - accessed 2026-11-07
7. Bleap card page - Apple Pay or Google Pay - accessed 2026-11-07
8. Google Wallet help - set up and supported payment methods - accessed 2026-11-07
9. Shakepay help - how the card works (wallets and ATMs) - accessed 2026-11-07
10. Uphold card page - Apple Pay and Google Pay when available - accessed 2026-11-07