By Mihail B., founder and editor of Sweepbase
Bleap’s card page tells a prospective customer to “activate your virtual Bleap card and start paying immediately with Apple Pay or Google Pay”. Its Google Play listing, updated on 4 August 2026, is blunter: “Use Apple Pay and Google Pay for contactless payments, just tap and go.” I have no reason to doubt the feature works.
I went looking for where that promise is written down. It took two documents, and the one carrying it is published by a different company and never says Bleap.
(Disclosure: Sweepbase carries referral links on some cards it lists, including Bleap. Nobody named here paid for this article or saw it before publication. I put questions to both Bleap and Unlimit on 11 August with a reply deadline of the 13th. Bleap’s support address returned an autoresponder pointing to in-app help; the follow-up it promises for non-user enquiries never came. Unlimit did not reply.)
Apple Pay Support Across 139 Crypto Cards
I maintain Sweepbase, a free dataset of consumer crypto cards under CC BY 4.0. On 10 August 2026 it listed 139 cards a consumer could still apply for, and I read the mobile wallet field on every one.[i]
Twelve name no wallet at all, so the field reads not disclosed, not specified, or expected later. Seven say “Yes” and stop. The remaining 120 name a brand.
Then a bucket I had not expected to need. Eight of the 120 name a wallet in order to withhold it. Tap Card’s field reads “Not enabled (Apple Pay unavailable; Google Pay not specified)”. ZAR Card’s reads “Tap to Pay enabled (Apple/Google Pay not explicitly named)”, the opposite of what a keyword match scores it as. Bing is rolling out, Blackcatcard is conflicting, PokePay is undisclosed.
That leaves 112 affirming some wallet and 104 affirming Apple Pay itself without a qualifier; the eight in between confirm Google Pay while hedging Apple. Make it 106 if you allow the two that reach Apple Pay through a workaround. The buckets are mine, and that wobble is what this counting is like.
The 104 look reassuring until you ask what a named wallet is worth. A brand page is a marketing sentence, and the company issuing the card is usually not the one that wrote it.
What the Cardholder Agreement Actually Says
Bleap is a euro card sold in the EEA and Switzerland. Open its EEA Cardholder Terms, read on 10 August 2026 and again on the 11th, and the words Apple and Google appear zero times each in the visible text. Clause 5.2, headed Authorising transactions and Tokenisation, covers the subject in one sentence: “When you add the Card to a wallet or tokenised service, its provider’s terms apply in addition to these Card Terms.”
The same document names the issuer. It is not Bleap: “The Card is issued by Unlimit EU Ltd, an Electronic Money Institution authorised by the Central Bank of Cyprus; issuer activities are governed by Unlimit’s General and Card Terms.”
Clause 5.2 is ordinary drafting, so I read four more agreements from four other programmes. Holyheld, which runs on the same issuer as Bleap, advertises Apple Pay on its homepage and mentions it zero times in its terms, which never name the issuer at all, only “the licensed payment-instrument issuer partnered with us”. Gnosis Pay mentions it zero times and repeats the structure exactly: “Cards are issued by Monavate. Card-related activities… and use of the Card are therefore governed by your Cardholder terms.” Wirex is the hard case. Neither its payment card terms nor the Mastercard issuer terms it publishes alongside them mention Apple Pay anywhere in the visible text. Five agreements, four programmes, and the wallet appears in none of the paper carrying a brand name.
That second Bleap quotation is a signpost, and following it is where this stops being a story about a missing paragraph. Clause 1.3 requires the customer to confirm they accept “these Terms, Unlimit Issuer Terms, Risk Disclosure, Price Disclosure and the Privacy Policy”, and a later clause gives the address: the issuer’s terms “are available here”, at accounts.unlimit.com/legal-documents.
There the wallet promise finally appears in a contract. The issuer publishes an Apple Pay Terms and Conditions, a Google Pay equivalent, and a Digital Wallets document for Mastercard cards. The Apple Pay file runs five pages, and acceptance needs no signature, only use: “By registering your Eligible Card for Apple Pay… you fully and unconditionally accept these Terms and Conditions”.
So a wallet contract exists and the cardholder is bound by it on first use. What it never contains is the word Bleap. It is the issuer’s template, carrying a batch approval date of 9 May 2024 shared with the Google Pay and Digital Wallets files. The same library holds fee schedules for eight other programmes, Holyheld among them, all pointed at those wallet documents.
Why Automated Checks Get Wallet Support Wrong
Verifying this at scale hits a mechanical problem. Search the raw HTML of Bleap’s cardholder terms for “Apple Pay” and you get 20 hits on a page whose visible text has none; its card page gives 21 raw against 1 on screen. The app ships its whole translation bundle on every route, legal pages included, so a fetch reading bytes without rendering finds strings no reader sees. Bleap also runs two card pages that render different sentences about Apple Pay while both carry both in the bundle.
I know the failure mode because I shipped it. My row for that card read “Yes (Mastercard integration)” from the day I created it until 7 August 2026. Our comparison table matches on the literal words Apple or Google, so it printed a flat No in the wallet row beside a card that supports both. Five months.
It caught the fact-checker on this piece too. I was told my opening quotation existed only in the bundle, and the sentence from Bleap’s other card page was the real one. I rewrote the article around that before checking it myself. In the same pass I lifted two programme names off PDF filenames instead of the page, and had to take them back out.
The Issuer Controls Tokenisation, Not the Brand
For a payments audience the documentation gap matters for a duller reason than accuracy. Provisioning runs through the issuer, its processor and the network token service. The brand on the app icon may be none of the three.
On 28 July 2026, without warning, the Solflare card stopped working for everyone holding one. Solflare said so on its own blog that day and blamed its card issuing partner, Kulipa, which had “struggled to keep its operations going”; Condia reported that Kulipa had suspended operations the following day. No cardholder could have seen it coming from Solflare’s own paper.
Some of it was findable. A separate programme, nsave, named its card issuers in terms dated 5 January 2026: Kulipa, with a company number, and Monavate entities alongside. A reader would have learned there were two, which beats silence and was not enough. nsave closed its own card programme to new customers on 11 May 2026 and has never said which partner left.
Three Due Diligence Questions for Card Programmes
If you are commissioning one of these programmes, three questions do most of the work.
Which Document Names the Wallet?
Four candidates: the marketing page, the help centre, the cardholder agreement, and the issuer terms it incorporates by reference. Only the last two bind. On the one programme where I found the wallet named at all, it was the fourth.
Does the Virtual Card Provision, or Only the Plastic?
If it is the plastic, a new customer waits for delivery before the feature they signed up for exists. Across 139 cards I found that distinction stated on two.
Who Is the Token Requestor?
If the agreement is silent and nobody has said which card provisions, the brand probably cannot answer this either. That answer decides who fixes an outage.
What This Means for Card Programme Operators
None of this needs a product change. It needs a sentence in a document that already exists, naming which wallets are supported, which card provisions, and which entity holds the token. Failing that, a pointer from your own agreement to the issuer file that answers the first question.
I have an interest in programmes doing that, since it would make the dataset I publish cheaper to maintain. The next person asking a support desk why their phone stopped working would at least be told which company to ask.
[i] Counts come from the Sweepbase crypto card dataset as it stood on 10 August 2026, CC BY 4.0. A card is obtainable when its Discontinued field is unset and Experience Type is not pre-launch. The live download has gained one card since that date, so the same read today returns 140.
About Author:
Mihail B. is founder and editor of Sweepbase, a comparison catalogue of consumer crypto cards. It carries referral links, disclosed and excluded from its ratings.
