Web Payments and Digital Identity are Having a Moment

For a long time, logging into a website was (perhaps still is) a bit of a mess. There’s definitely been many efforts to fix it, and though OAuth buttons and SSO integrations tried to clean things up, under the hood, “Sign in with…” is mostly a best-effort dance. You can authenticate a user, maybe even grab some claims about them, and with luck, stitch together a tolerable user experience.

How depressing that our best efforts result in “tolerable.”

Now contrast that with what happens when you click “Buy now.” That’s not best-effort. That’s a minefield of regulatory compliance, industry standards, liability frameworks, and expectations that money, actual money, will safely and instantly change hands. There’s PCI-DSS. There are 3-D Secure requirements. There’s the awkward but necessary dance of tokenization, fraud detection, and chargeback management.

When it comes to payments, the web grew up and started paying a mortgage a long time ago. When it comes to identity, we’re still pondering what it means to adult.

Times, however, they are a-changin’. The walls between the identity folks and the payments folks are getting thinner. In some cases, those walls are coming down entirely. And it’s not just because of technological convergence, though that’s part of it. It’s because users are demanding better experiences, regulators are demanding more assurance, and vendors are realizing there’s more money to be made (and saved) when you stop pretending these are two separate problems.

The silos are collapsing

Historically, the digital identity people worked over here and the payments people worked over there, each with their own browser APIs, working groups, and acronyms. It was a live-and-let-live scenario, with the occasional “You should talk to Bob in the Payments WG about that…” tossed across the W3C aisle.

That’s changing. Why?

I’m going to blame digital wallets.

Today’s digital wallets don’t just store payment cards; they also store verifiable credentials. Credentials like your driver’s license, your airplane tickets, and whatever will serve as an “I swear I’m over 18” age claim. All of these are coming together in a single UX surface, often right in the browser.

That means the web needs a new kind of interface. One where your browser can show you the secure thing you’re allowed to use at the right time, whether that’s a credit card, a credential, or some clever combination of the two.

Where the work is happening

At the W3C, two groups are particularly active in this convergence: the Federated Identity Working Group (FedID WG) and the Web Payments Working Group (WPWG). They’ve mostly stayed in their own lanes, but I think that’s going to change. Lines of communication are definitely about to get stronger.

Interested in learning more about how standards development works and how your organization might take advantage of early knowledge? I have a service for that: Inform the Standards in Digital Identity.

Federated Identity Working Group

On the FedID side, two APIs are reshaping browser-based identity:

• FedCM (Federated Credential Management): Designed to reimagine the “Sign in with…” experience for a world without third-party cookies. It gives users a native browser dialog for account selection, keeping identity flows first-party and privacy-friendly. It’s going to (hopefully) make life a lot better for anyone who uses the web for social connection or as a consumer.
• Digital Credentials API (DC API): This is the plumbing that lets browsers relay secure information between a site, the OS, and whatever wallet is installed. Think of it as the missing piece that both enables and protects the exchange of your personal information with whatever site is asking for it.

Web Payments Working Group

Over in WPWG territory, you’ll find APIs like:

• Secure Payment Confirmation: A way to prompt users for strong authentication using platform authenticators (read: WebAuthn) as part of a payment flow.
• Secure Remote Commerce (SRC): The “Click to Pay” system championed by major card networks. It’s not quite a wallet, but it is a federation-like model: the user chooses a card stored elsewhere and completes the transaction with fewer redirects and less friction.

Now here’s the fun bit, at least from my perspective: these lines between all these APIs are starting to blur. Could FedCM be used to show a list of saved payment cards, each tied to a user identity, during checkout? Could DC API help determine whether a credentialed identity has an associated payment method?

Some of the payment players were skeptical at first (standardization! browsers in the mix! scary!). But they’re warming up, especially as they realize a smoother, privacy-preserving, first-party login experience could give them something they’ve been missing: recognition of returning users without third-party cookies.

Shared problems, shared future

What’s driving this convergence? Three shared goals:

1. Returning user recognition: If you’ve ever run a checkout funnel, you know: drop-off is death. Being able to recognize a returning user, without tracking cookies or forcing a login, is gold.
2. Fraud mitigation: Whether you’re managing identity theft or card-not-present attacks, you need risk signals, device binding, and good authentication. That’s why FIDO device-bound credentials and biometric authenticators are popping up on both sides of the aisle.
3. Strong authentication: Regulators (looking at you, PSD2) and developers alike are embracing strong, phishing-resistant authentication. FIDO2 and WebAuthn aren’t just for logins anymore; they’re showing up in payment confirmations and credential exchanges.

But payments are also dragging identity into some new territory. Think of age-gated purchases or proof-of-residency for tax calculations. These aren’t traditional payment concerns, but they’re becoming essential parts of modern transactions. And that means they’re becoming browser problems.

So who’s in charge?

Well, no one. Or maybe it’s lots of someones. It’s hard to tell, and that’s both good news and bad news.

The newly launched FIDO Alliance Payments Working Group isn’t trying to create a new standard. Instead, it’s focused on identifying what’s missing, what payments need from the rest of the stack, and finding the right home for those requirements. That could mean new work in the W3C’s Web Payments WG, or tighter coordination with the FedID WG. Or maybe something new entirely.

It’s definitely the definition of “interesting times.” It’s a time when the people who design your login experience and the people who design your checkout flow have to start talking. Not just because it’s polite, but because they’re building for the same end user, solving the same problems, and being constrained by the same browser platforms.

What to watch

If you’re building anything that touches identity or payments on the web, now’s a good time to pay attention to:

• The FedCM API, which is rolling out in Chrome and being discussed across browser vendors.
• The DC API, which is gaining traction in wallet-based workflows.
• The future of Secure Payment Confirmation, which might just become the go-to method for confirming both logins and purchases.
• And the user experience expectations that come with digital wallets. Because the bar is no longer “functional.” It’s “frictionless.”

Final thought

We’re moving from a world where identity and payments were treated as separate UX problems to one where they’re deeply entwined. That’s going to be messy, yes, but also incredibly powerful.

Because when your browser can recognize you, verify you, and let you pay, all without handing your life story to a dozen trackers or to the browser maintainer, that’s not just good UX. That’s what the web experience should have been all along.

I’m so glad to be a part of getting that much closer to something better than just tolerable.