UCP Checker
Industry

The UCP Payments Tech Council Is Seated — Here's Who's On It, and the Two Working Groups That Come Next

· 2 September 2026 · 7 min read

On 2 September the Universal Commerce Protocol closed the loop it opened in July. Nominations for the Payments Tech Council (Payments TC) were finalised, the council's structure and composition were fixed against the approved charter and the updated governance rules, and the members were written into the UCP maintainers file.

Eight organizations hold the inaugural seats: Adyen NV, Ant International, Coinbase, Global Payments, Google, PayPal, Shopify, and Stripe.

The same announcement did something the vertical councils didn't: it opened statements of interest for two Domain Working Groups — one for tokenization, one for buy-now-pay-later — with international market groups flagged to follow.

We covered the nominations when they opened and called this the council that mattered most, because payments is the only horizontal seam in the protocol. Here is what actually got seated.

Who's on it

The eight member organizations split into three recognisable groups.

The founders. Google and Shopify, who jointly proposed the charter.

The acquiring and processing layer. Adyen, Global Payments and Stripe — the companies that sit between a business and the money.

The wallets and alternative rails. PayPal, Coinbase and Ant International — a wallet with a two-decade head start, a crypto exchange, and the operator behind Alipay+.

Read as a set, that is a council built around how value actually moves in different markets rather than around the card as the default instrument — which is what the charter's "diverse international market needs" clause asks for, and what Ant International's seat puts a member behind.

The seat math is the story

Governance documents are dull right up until you compare them. UCP's councils each seat 16 members, but the allocation between founding organizations and the wider industry differs sharply by council:

Council Permanent founder seats Permanent industry seats Open elected seats
Shopping TC 8 (Google 4, Shopify 4) 0 8
Food TC 6 (Google 6) 4 6
Lodging TC 6 (Google 6) 6 4
Payments TC 6 (Google 3, Shopify 3) 6 4

Three things fall out of that table.

Google's permanent allocation on the Payments TC is three — its smallest on any council, and half what it holds on Food and Lodging. It is also, for the first time outside the Shopping TC, matched exactly by Shopify.

Six of the twelve permanent votes sit with organizations that are neither founder. On Food, the founding side holds a majority of the permanent votes outright.

And four seats are still open, elected by the Governing Council on the basis of technical contribution. The announcement makes that explicit: active contribution "will serve as one of the primary criteria to fill open seats in future elections." Organizations outside the eight have already said in the announcement thread that they want in.

None of this makes the payments council independent of its founders — Google and Shopify still hold half the permanent votes and both sit on the Governing Council above it. But on the numbers it is the most externally weighted technical council UCP has stood up, on the one seam that every vertical has to cross.

The two working groups

The second half of the announcement invites statements of interest for two DWGs:

  • Tokenization DWG — "appropriate tokenized representations of payment credentials for agentic flows." Proposed initial members: at least one Domain Tech Council member, plus American Express, Mastercard and Visa.
  • Buy Now Pay Later DWG — surfacing BNPL terms during product discovery and processing BNPL payment requests through payment handlers. Proposed initial members: at least one DTC member, plus Klarna and Affirm.

A working group is not a smaller council, and the distinction is worth getting right. Under UCP governance, a DWG is chartered by the Governing Council, has autonomy to define capabilities for its domain, and submits them for Domain Tech Council approval — every DWG artifact is reviewed and approved by the DTC that oversees it. It is the consensus venue where an industry's participants agree the shape of a capability, with the council retaining the sign-off.

Both groups map onto the charter. BNPL is a Phase 1 item — named alongside card tokens and e-wallets as the instruments of US-type markets. Tokenization reaches into Phase 2, which names "Agentic Tokens (Network Cloud Tokens)" as a deliverable: network tokens are the mechanism by which a card credential can be handed to an agent without handing over the card. In both cases the organizations that issue the instrument are the ones proposed to define how it is expressed, in a group whose output the council signs off. That is the venue the governance model provides, and it is now the venue in use.

The international market DWGs, still unannounced, are the ones to watch after that. The charter's Phase 2 names UPI and APAC e-wallets specifically, and neither behaves like a card — nor do the local rails that a Brazilian or Indian business would already be routing through an extension today.

The council inherits work that already shipped

Here is the part that gets lost in the governance news. The Payments TC is being seated after the release that did most of its Phase 1 structural work.

UCP v2026-08-25 moved payment out of the shopping namespace entirely. Payment constructs now live under dev.ucp.common.payment.*, token binding became vertical-agnostic, and four payment capabilities landed as named extensions:

  • dev.ucp.common.payment.authentication — device data collection and 3DS challenges
  • dev.ucp.common.payment.ap2_mandate — non-repudiable authorization for autonomous commerce
  • dev.ucp.common.payment.split_payments — multi-instrument allocation
  • dev.ucp.common.payment.payment_terms — deposits, installments and deferred schedules

We wrote about 3DS challenges and negotiated terms as they were merging. Read against the charter, that is a meaningful share of Phase 1 delivered before the body responsible for Phase 1 had members.

That is not a criticism; it is the normal order of events in a fast standard, and it was visible in July — the work was already sprinting, and what it lacked was somewhere to live. But it does change the council's opening job. It is not starting from a blank spec. It is inheriting merged capabilities, an installed base in the single digits, and the harder half of the roadmap.

Off zero — barely

We said in July that we would report the payment line when it moved, so here it is.

At the July census, declared payment capability across the verified fleet was zero. It is no longer zero. Across roughly 16,000 verified businesses among nearly 20,000 monitored domains, the payment layer as declared today looks like this:

Capability Businesses declaring it
Checkout ~16,250 (99.8%)
AP2 mandate 8
Identity linking 24
Payment authentication 1
Split payments 1
Payment terms 0

Checkout is effectively universal. The payment layer is countable on two hands. The gap between those two rows is the entire reason a payments council exists — and the number that will tell you whether it worked.

Live figures are on the capabilities page and the adoption stats; both move daily, and neither is a forecast.

One note on the calendar

When nominations opened, the published timetable put the membership announcement at 11 August. It landed on 2 September. The dates in the original discussion were revised along the way, and our July post reported the schedule as it stood then — worth flagging, because a three-week slip on a governance milestone is ordinary, and reading it as anything more would be a mistake.

What we'll be watching

We don't write the spec. We measure what happens after it ships, from the public record, the same way for every business — whoever holds a seat.

That chain is short enough to follow end to end. Council decisions become spec, and spec shows up on the protocol tracker. Spec becomes manifests in the wild, and those show up in the capability data and the monthly ecosystem reports.

Eight seats are filled, four are open, and two working groups are forming around the instruments that will decide whether an agent can pay for anything at all. The declared payment layer is still in single digits. Both of those numbers are now worth watching.


About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

Sources

What does a UCP agent find at your store?
Check it once and it gets its own status page.
Check a store

Keep reading

15 Oct 2026 UCP in the Agent Chain of Trust: What the GoDaddy, Infoblox, Google and Cloudflare Demo Checks Industry · 10 min 14 Oct 2026 UCP for B2B: A Procurement Council Charter, Quotes and Price on Request Industry · 11 min 13 Oct 2026 UCP Business Directory and Business Identity: Amazon's Three RFCs Explained Industry · 9 min