In August 2025, Valve started requiring UK Steam users to register a credit card on their account to unlock “mature content.” In February 2026, Discord delayed its global age-verification rollout and said it was adding credit-card verification as a new option alongside facial age estimation and government ID. Two of the largest platforms on the consumer internet, arriving independently at the same answer: when you need to prove someone is an adult, ask for a card.
It looks pragmatic. The card is already on file for half your users, the UX is familiar, and a UK regulator has explicitly blessed it. But the credit-card age gate smuggles in an assumption that is true in exactly one country and quietly false in most of the others. A platform that treats “card on file” as “adult on file” is shipping a check that passes audit in London and fails it in Texas — with no way to tell the difference at runtime. This post is about why that happens, why the card conflates two legally distinct jobs, and what an age check has to do that a card simply cannot.
The Card on File Is Doing Two Jobs, and It’s Bad at One of Them
A credit card is a payment instrument. Its entire design purpose is to authorize the movement of money and to bind that authorization to an account that someone — not necessarily the person holding the plastic — is liable for. It carries a PAN, an expiry, a network, an issuer. What it does not carry, anywhere in the rails, is the cardholder’s date of birth. There is no age field in a card authorization. When a platform uses a card as an age check, it isn’t reading age off the card; it’s inferring age from a second-order fact: this card exists, therefore the issuing bank must have decided this person was old enough to get one.
That inference is only as strong as the issuance rule behind it. And issuance rules are not a law of physics — they are jurisdiction-specific banking policy that varies by country, by card type, and by issuer. The moment you build a global product on top of that inference, you’ve made the strength of your age gate a function of where the user’s bank happens to be incorporated. That’s a strange property for a compliance control, and it’s the root of nearly every failure mode below.
Why the UK Gives the Credit Card a Pass
Start with the case where the card check genuinely works, because being precise about why it works is what exposes where it breaks.
In its January 2025 final guidance on “highly effective age assurance,” Ofcom listed the methods it considers capable of meeting the Online Safety Act bar: open banking, photo-ID matching, facial age estimation, mobile-network-operator checks, credit card checks, digital identity services, and email-based age estimation. Credit card checks made the list for one specific, stated reason: in the UK, credit cards are issued only to people aged 18 and over. The card is a usable adult signal there because UK consumer-credit regulation puts a hard age floor under issuance. Ofcom was equally explicit about the other side of the line — self-declaration and “online payments which don’t require a person to be 18” are not highly effective. The distinction isn’t “cards good, checkboxes bad.” It’s “a card is only an age signal where the law guarantees the card itself was age-gated.”
That is exactly the logic Valve relied on. A UK Steam account counts as age-verified for as long as a valid credit card sits on it — the card stands in for an 18+ check because, in that jurisdiction, holding one implies you cleared 18. Inside the four walls of the UK, this is defensible. The problem is that almost nobody operates inside the four walls of one country.
Cross the Border and the Assumption Collapses
Take the identical control — “a valid credit card on the account means the holder is an adult” — and move it to the United States, and the floor disappears.
In the US, a minor can legitimately have a credit card number in their hands as an authorized user. The minimum age to be added as an authorized user ranges from 13 to 18 across issuers — and several of the largest banks, including Bank of America, Capital One, Chase, and Wells Fargo, set no minimum age at all. A parent adds a 14-year-old to their account, the bank runs no credit check on the child because the primary holder carries the liability, and the kid now holds a real, chargeable card bearing their own name. Layer on debit cards and reloadable prepaid cards — teen-branded debit products are a deliberate, marketed category — and you have a population of minors holding payment instruments that will sail through any “is there a valid card on file?” check.
So the same line of code is a defensible adult signal in the UK and a broken one in the US, and the platform has no clean runtime signal to distinguish the two. Issuer-and-product-level age rules are not exposed in the authorization response; you cannot reliably tell “UK credit card, issued to an 18+ holder” from “US card on which a 14-year-old is an authorized user” from the card alone. The control’s correctness depends on a fact the control can’t see. For anyone who has shipped a feature flag that was right in one region and silently wrong in another, this is a familiar and uncomfortable shape: a global rule resting on a local assumption, with the failure invisible until an auditor or a regulator surfaces it.
Proving Age Is Not the Same Job as Proving Parental Consent
There’s a second, subtler trap, and US builders fall into it constantly because the FTC’s own rules invite the confusion.
Under COPPA, a recognized way to obtain verifiable parental consent is to have a parent use a credit or debit card “in connection with a transaction” that notifies the account holder — and the FTC’s January 2025 final rule removed the old requirement that you actually charge a fee to do it. So a card is a sanctioned COPPA tool. But read what job it’s doing: it’s evidence that the person granting consent is a parent — an adult standing in for a child’s account — not evidence about the cardholder’s own age relative to a threshold. Those are different questions. “Is this person 18/21?” and “Is this person a consenting parent of this child?” require different proofs, and a card payment answers only the second.
The FTC was also clear that the collection of a card number alone — without a transaction, without supplemental verification — is insufficient even for parental consent. So the card, in COPPA’s own framing, is a component of a consent flow, supplemented with knowledge questions or a secondary contact channel. Treating “we captured a card number” as a standalone proof of either age or consent misreads the rule it’s borrowing credibility from. We’ve walked through the actual VPC mechanics in our verifiable parental consent implementation guide; the short version is that the card is never the whole answer, and it is never an answer to “how old is this user.”
What the Card Can’t Do Even When It “Works”
Set aside jurisdiction for a moment and grant the best case — a UK adult, a genuine 18+ credit card, no authorized-user weirdness. The card check still can’t do most of what a modern age-assurance program needs.
It has no granularity. A card is a binary 18+ token at best. It cannot tell you a user is over 13, over 16, over 21, or over 25 — and the regulatory map now demands exactly those gradations. Age-appropriate design codes, US state social-media laws, alcohol and gambling thresholds, and platform safety tiers all turn on bands the card simply doesn’t encode. The moment your compliance surface includes anything other than a single 18+ wall, the card stops being a complete answer.
It doesn’t bind to the person present. A card on file proves a card was entered, not that the human in this session is the person the card belongs to. Cards are shared within households, borrowed, and bought; a 15-year-old using a parent’s stored card defeats the check entirely, and nothing about “valid card present” notices. Binding the proof to the live human is the property that actually resists circumvention — the same gap we’ve written about in the context of shared devices and proxy verification, where a “passing” check quietly becomes no check at all.
It builds a honeypot you didn’t need. Storing card numbers to use them as an age flag means warehousing payment data — PCI scope, breach exposure, and a high-value target — for a purpose the card was never designed to serve. You inherit the full cost of holding financial instruments to answer a question they don’t answer well. Minimizing what you retain is the entire direction of travel in this space; collecting more sensitive data to do age assurance worse is the wrong trade, and it’s the kind of decision that ages badly the first time you have to write a breach notification.
It pushes users away. Handing a credit card to a chat app or a game launcher to read a forum or unlock a setting is a hard ask, and people decline it. The backlash to Discord’s rollout and to Steam’s UK card requirement wasn’t only about privacy — it was friction at a step users didn’t expect to pay for with their card details. Every unnecessary high-friction gate is abandonment you chose, a dynamic we’ve quantified in our work on verification drop-off.
None of this means the other methods are magic. Facial age estimation has its own failure surface — Discord’s face check was reportedly fooled by a 3D avatar a user puppeteered with a game controller, which is a reminder that any single method run without liveness and a fallback is a single point of failure. The point is not “swap the card for one other trick.” It’s that a serious program is layered, bound to the person, and chosen to match the actual threshold and jurisdiction — none of which a card on file delivers.
What “Highly Effective” Actually Asks For
Strip the methods away and look at the criteria underneath them. Ofcom’s bar is that a method be technically accurate, robust, reliable, and fair — and crucially that it be applied to establish the age of the person using the service, not a proxy for them. Those four words are doing real work, and they map cleanly onto why card-on-file underperforms: it’s not accurate across jurisdictions, it’s not robust against sharing, its reliability is hostage to issuer policy you can’t read, and it’s unfair to the large populations who don’t hold cards or hold them for reasons unrelated to their age.
The methods that clear the bar are the ones that attach the proof to the human in front of you. Document capture paired with liveness establishes that a real, present person matches a real credential. Facial age estimation, run on-device with a buffer-zone escalation to stronger evidence near the threshold, gives you a privacy-preserving estimate without warehousing anything sensitive. Open banking returns an over-18 confirmation from the bank without handing you the account or the date of birth. And reusable credentials let a user verify once and present a bound, privacy-preserving proof everywhere after, instead of re-entering a card at every wall. Each of these answers the question the card dodges: is the specific human here old enough, and can I prove that decision later?
The Honest Place for the Card
Intellectual honesty cuts both ways, so here is the case for the card, narrowly drawn. In a single jurisdiction where credit issuance is hard-gated at the age you care about — the UK being the cleanest example — a credit card is a legitimate, regulator-recognized adult signal, and using it as one option in a method menu is reasonable. As a secondary or step-up factor layered on top of a primary check, it adds friction-tolerant signal for users who’d rather not scan a face or a document. The failure isn’t using a card at all. The failure is making a payment instrument your primary, global age gate and assuming an issuance rule from one country travels to all of them. The card is a fine supporting actor and a poor lead.
The platforms reaching for it in 2026 are doing so under real enforcement pressure — Ofcom’s fines run to £18M or 10% of global revenue, and regulators have already shown they’ll act on self-declaration and inadequate assurance. That pressure is exactly why the method you pick has to be defensible everywhere you operate, not just where the card math happens to work. A control that’s correct in your home market and wrong abroad isn’t a shortcut; it’s deferred liability.
How Xident Fits
Xident was built to answer the question the card can’t: is the specific person in this session old enough, provably, anywhere you operate? We do threshold classification across bands (+12, +15, +18, +21, +25) rather than a single binary wall, so the same integration serves a 13+ social rule and a 21+ alcohol gate without bolting on a separate mechanism. Verification runs through layered methods — document capture with liveness, facial age estimation with on-device processing and a buffer-zone fallback to stronger evidence near the boundary — so no single check is a single point of failure, and the proof binds to the live human rather than to a piece of plastic that can be shared or borrowed.
We retain the decision, not the documents: an exportable, auditable record of what was verified, when, and how, without warehousing identity files, biometrics, or card numbers on your infrastructure. And because the result is a durable, bound, privacy-preserving age assertion, a user can verify once and present it again rather than re-entering credentials at every gate. If you’re weighing how to choose between methods under real regulatory load, our vendor security checklist walks through the questions that actually separate a defensible program from a convenient one.
A credit card tells you a bank, somewhere, once decided someone was old enough for credit. It does not tell you who is holding it now, how old they are, or whether your regulator agrees. Build the age check that does — and reach for the card only where it earns its place.
If you’re replacing a card-on-file age gate with something that holds up across jurisdictions, start here.
