Crypto Card Sharing 2026: Lend It, Own Every Charge

Everybody who has handed a card across a kitchen table wants to know the same thing, and on crypto card sharing the web answers with advice written about credit cards. What is at stake is the refund you would otherwise be owed: the moment you permit someone else to spend, most of these agreements stop treating the transaction as fraud and start treating it as yours. So on 4 November 2026 we read nine cardholder documents from seven companies, clause by clause. Six forbid it outright, three convert it into consent, one bills you regardless, and one says nothing in 241 words. Every clause number below came off the document rather than a help-centre summary.

Three kinds of rule turn up. A conduct rule says you shall not let another person use the card. A liability rule says that if you do, the spending counts as authorised and you pay for it — forbidding nothing, pricing everything. An account rule governs who may log in. Only the second reaches your money directly.

The six documents that ban it outright

Every document we could read in full, with the entity that would enforce it. The last two columns matter most: together they say whether sharing is forbidden, priced, or both.

Two things there do more work than the prohibition. Sharing is not its own offence but an example of unauthorised use — the category the document hangs its liability on. And clause 3.3 has you acknowledge that each physical card “is and remains at all times the property of the Issuer”. You are not lending your card. You are lending the issuer's.

Baanx reaches the same place with a checklist. Section 8 of both its documents, headed Keeping Your Card Safe, asks you to “keep your Card, Card number, CCV, login codes, PIN, and other security features used to access the E-wallet strictly to yourself”, then says the rest twice in one bullet: “do not share your security credentials to access the Card with any other person or otherwise allow another person to use the Card or the Services; not permit any other person to use your Card or the Services”. The wording is identical in both files — a shared template, not two decisions.

The clause that turns sharing into consent

The forbidding is not the interesting part. Three documents contain a sentence that changes what kind of event a shared transaction is, and it is the most expensive clause we read.

Read it against the definition of an unauthorised transaction the same documents supply a few paragraphs earlier: a transaction is unauthorised “if it is not initiated by you, you did not give permission to make the transaction and you do not benefit from the transaction in any way”. Three conditions, joined by and. All three have to hold.

Permission alone destroys the second. So the moment you hand over the card, every later transaction is authorised by definition, and the protections you counted on do not apply — not because anyone withdrew them, but because they were only ever about unauthorised use.

That is why “I shared it but I did not agree to that purchase” is weaker than it feels: you remain liable for “all transactions arising from use of the Card” by that person, not only the ones you had in mind. If your card stops working for an unrelated reason, our guide to a declined crypto card covers the ordinary causes.

One programme bills you without consent or benefit

BitPay takes the same US template and sharpens it. Section 4 carries a rider no other document in the set contains, and we checked all of them for it.

Set that beside the three-part test. The test makes a transaction unauthorised when you did not permit it and did not benefit from it. BitPay's rider says that even when both are true of a purchase, the single earlier act of granting access makes it yours. One decision converts every later transaction into your bill.

Crypto.com's US agreement, apparently from the same ancestor, stops a sentence earlier: you are liable for “all transactions made with the Card, Card Number or Account Number, and all related fees incurred, by those persons”, with no “even if”. Both also open section 4 by refusing the legitimate route: neither will issue an additional card for somebody else, and BitPay puts the maximum at zero. The ordinary bank answer is a named authorised user, and these programmes do not offer one.

Card details are a separate rule from card use

Reading these documents for one rule hides that there are two. Letting someone use the card is governed above. Letting someone see the number is governed elsewhere, and more strictly.

Clause 3.6 requires you to keep the card data — “the card number, expiration date, and security code” — “strictly confidential and not share the Card Data with any persons other than as necessary to conduct a transaction”. That carve-out is what makes the clause workable, since reading the number to a merchant is sharing it. It then names a method it will not treat as secure: card data “in clear text over fax, email or other unencrypted or otherwise unprotected media”.

Then it closes the door: “Neither we nor our respective affiliates shall under any circumstances be liable to you for unauthorised transactions caused by your failure to keep the Card Data secure.” Unlike the conduct clause, this one does not need you to have permitted anything — if the number leaks through carelessness, the exclusion bites even though the spending was genuinely unauthorised. Clause 3.7 obliges you to notify the issuer “without undue delay” on discovering any inappropriate disclosure of your PIN or card data, the one step that still helps you, and the subject of our guide to a lost or stolen crypto card.

What sharing actually costs you

Four consequences turn up across these documents, and most comparison pages mention none. Each cell is what that programme's own text provides — blank where the document is silent, not where we assume leniency.

Read the right-hand columns together and the shape of the risk appears. The US-template cards cap what the issuer can owe you at the transaction's face amount — a limit on your recovery, not your exposure. The European cards recite no zero-liability policy at all and exclude the issuer outright where card data was involved. In both families, crypto card sharing moves you from a position where somebody might reimburse you to one where nobody has agreed to.

Plutus limits the login, not the card

Plutus answers a different question again, and it is the same mismatch we found when counting how many crypto cards you may hold: the clause attaches to the account rather than the plastic.

Clause 30.1 lists what Plutus treats as a serious breach, and limb (f) is “allowing a third party that is not you to access your account by sharing your login details”. Nothing there is about the card. Hand someone the plastic and the 13,597 words of Plutus's terms do not obviously reach you; hand them your password and you have committed a serious breach.

What that costs is at 30.2: if Plutus closes your account, it ends your right to use the platform and “all the PRS that are available on your account will be cancelled and revert back to us”. PRS is the Plutus Rewards System, its own points and tokens. So the price of a shared login is not a disputed transaction but your accumulated rewards — a consequence no comparison page we found mentions.

The European clause and Article 74

One clause goes further than the rest, and is worth setting beside the law of the region it was written for. Clause 3.5 of the Crypto.com European terms reads:

That is not a sharing clause. It is a blanket assumption of risk for everything that happens on the card, authorised or not. The EU's own payment services directive sets a different default: Article 74(1) of PSD2 says the payer “may be obliged to bear the losses relating to any unauthorised payment transactions, up to a maximum of EUR 50” where an instrument was lost, stolen or misappropriated, and bears everything only on fraud or a failure of their Article 69 obligations “with intent or gross negligence”.

The gap between “any negligence” and “gross negligence” is the whole protection. A derogation does let providers contract out of parts of Article 74, but Article 63 confines it to instruments concerning transactions “not exceeding EUR 30”, or with a spending limit or stored balance of EUR 150 — so a card topped up with more than that is not what the escape hatch describes.

We are not lawyers and this is not advice: whether a clause this broad survives a regulator or a court is for them. What we can say is what the two texts say, and they do not match. If a programme tells an EEA cardholder they accept the risk of unauthorised transactions full stop, that term claims more than the directive hands it. Which regulated entity you deal with matters too, the subject of our note on crypto card issuers.

Taking permission back is a written procedure

Suppose you shared the card and want to stop. Only one document says how, and it is more demanding than a tap in an app.

Section 4 of the Crypto.com US agreement sets out two steps and a deadline: telephone the number on the back of the card, and “you must follow-up not later than 10 business days with the written notification to revoke (cancel) permission for any person you previously authorized”. Until the issuer has received that revocation “and ha[s] had a reasonable time to act upon the written notification”, you remain “responsible for all transactions and fees incurred by you or any other person you have authorized”.

Three points follow. The phone call alone does not finish the job, and the clock on the written step runs in business days. “A reasonable time to act” is undefined, so the end of your liability is not a date you can calculate. And the issuer may respond by cancelling the card and issuing a new number, so revocation can cost you the card too. Freezing a card is a different mechanism, covered in crypto card frozen funds.

Two defects in the drafting

Two of these documents cannot count their own sub-clauses, and both defects sit in exactly the lists this article depends on.

The first is in the clause containing the sharing ban. Clause 3.3 of the Crypto.com European terms runs its limbs (a), (b), (c), (d), (e) and then (e) again — two obligations share a label, and there is no (f) in the clause. The Brazilian edition, same 30 April 2025 date, reproduces the duplicate. The Australian and Singaporean editions run (a) to (f) correctly, so the error sits in one template and its translation.

The second is in Plutus's serious-breach list. Clause 30.1 runs (a), then (c), (d), (e), (f), (g), (h), (i) — no limb (b) at all, and the sharing limb we quoted is (f). Neither defect changes what the clauses require. They matter because these documents decide who pays, and because citing “clause 3.3(e)” of the European terms is ambiguous in a way the drafter did not intend. If you rely on one of these clauses in a dispute, quote the words and not just the number.

What to check before you hand it over

Final take

The honest answer is that six of nine documents say no, and the three that do not are the ones to worry about. A conduct ban is a rule you can comply with. A clause reclassifying your friend's spending as your own authorised spending is not a rule at all — it is a bill, and it arrives whether or not anybody accuses you of a breach.

Which makes this another reading test, like the eligibility clause and the card count before it. These programmes do not disagree about whether sharing is acceptable; every one that addresses it is against. They disagree about what to do to you afterwards, and that choice sits in a sentence most readers never reach. The one worth finding is not the clause that forbids it. It is the clause that prices it.

Sources

All read in full on 4 November 2026. Crypto.com EU/EEA prepaid card terms (cl. 3.3(c) and its duplicated limb; cl. 3.5–3.7; Foris MT Limited; 30 April 2025), Australia (cl. 3.3(c), limbs (a)–(f) intact; 17 September 2025), Singapore (cl. 4.3(c); Foris Asia Pte. Ltd.; 7 January 2025), Brazil (cl. 3.3(c); same duplicated limb; 30 April 2025) and the US Prepaid Visa Cardholder Agreement (§ 4, the 10-business-day revocation step, the sharing and liability sentences and the three-part unauthorised test; Community Federal Savings Bank; effective 1 September 2026). Exodus Card EU+UK terms (§ 8; the liability sentences; “The Card is nontransferable”; Baanx Group LTD, issuer Monavate Ltd) and the Crypto Life “CL” Card terms (§ 8, identical bullet; 6,861 words; Baanx US Corporation with Cross River Bank; still headed “Draft of 6-26-25”). BitPay Card cardholder agreement (§ 4, the “even if you did not authorize” rider and zero secondary cards; Metropolitan Commercial Bank), Plutus EEA terms (cl. 30.1(f) and the missing limb (b); cl. 30.2 on PRS; last updated 8 April 2025) and XKard terms and conditions (241 words; XHYPE FZCO; no sharing clause). Statutory text from Directive (EU) 2015/2366 (PSD2), Articles 63, 69 and 74.

Read but not quotable, and therefore not counted: RedotPay's card terms returned only cookie-consent text through a reader proxy, so its position is unknown rather than absent, and Wirex was unreachable for a fourth consecutive run. Where a document is silent we say “silent” rather than infer permission.

Related Articles

• Multiple Crypto Cards 2026: What the Terms Allow
• Crypto Card Age Limits 2026
• Crypto Card Complaints 2026
• Crypto Card Chargebacks 2026
• Crypto Card KYC Rules 2026
• Business Crypto Cards 2026

Frequently Asked Questions

Can someone else use my crypto card?

Not under six of the nine documents we read. Crypto.com's European, Australian, Singaporean and Brazilian terms each list sharing the card's use as an unauthorised manner of use, and both Baanx agreements carry a section 8 bullet against letting another person use it. BitPay does not forbid it in those words but makes you liable for everything that follows. Plutus limits the account login instead, and XKard says nothing.

Is it illegal to let someone use your crypto card?

Nothing we read creates a criminal offence. These documents create a contractual breach and a transfer of financial risk. The consequence is liability, not prosecution: once you have permitted the use, the programme can treat the spending as yours.

Does sharing a crypto card void zero liability protection?

In effect, yes, because it changes what kind of transaction it is. The Crypto.com US, Exodus and CL Card agreements all define an unauthorised transaction as one you did not initiate, gave no permission for and do not benefit from. Permission alone fails that test, so the transaction is authorised and zero liability never engages.

What happens if I give someone my crypto card PIN?

Three agreements answer this in one sentence: if you share your card, access codes or PIN, that person's use of the card account “may be considered as authorized”, and you will be liable for all transactions arising from it. The European terms go further at clause 3.6, excluding the issuer altogether where you failed to keep the card data secure.

How do I withdraw permission once I have let someone use my card?

Two steps with a deadline, on the Crypto.com US agreement. Section 4 tells you to telephone the number on the back of the card, then follow up not later than 10 business days with written notification revoking permission for anyone you previously authorised. Until that notice lands and the issuer has had a reasonable time to act, you remain responsible for everything they spend.

Do no-KYC crypto cards have rules about sharing?

Not in any document we could read. XKard's published terms run to 241 words, state that it is not a card issuer, and contain no sharing clause, no liability allocation and no issuer name. That silence is not permission: the governing rule lives in the issuing provider's terms, which the reseller neither publishes nor names.