Four days after the Actions primitive merged, it found its first real-world user — and it wasn't a loyalty program or a gift-wrap flow. It was Mercado Pago, Latin America's largest payment processor, filing two proposals that use Actions to bring Pix, boleto, and the world's cash-voucher rails into UCP. The payment-extension layer just went global, and it's worth understanding exactly what shipped.

#What UCP payment extensions are (and aren't)

Two different things carry payments in a UCP manifest, and the distinction matters more every week. Payment handlers declare how a buyer can pay — the method or wallet surface a store presents: Google Pay, Shop Pay, a tokenized card handler. A handler is not the payment processor: a store can offer Google Pay at checkout and settle through Stripe or Adyen behind it, and the processor of record never appears in the manifest at all — it's only observable at the transaction layer. Payment extensions declare added flows — vendor-namespaced capabilities that compose onto checkout to express payment behavior the core spec doesn't model: buy-now-pay-later terms, installment display, and now out-of-band settlement. Handlers are the buyer-facing doorway; extensions are the vocabulary for everything payment does beyond a synchronous card charge.

The extension side is where the innovation is landing. Affirm shipped the first vendor payment extensions — three BNPL protocol extensions, deliberately provider-agnostic. This week, Mercado Pago became the second major payments company to build there.

#What Mercado Pago proposed

#635 — com.mercadopago.payment.display handles the in-session case: a buyer picks Pix, the business surfaces a QR code and copy-paste code as a pure-render Action on the checkout (the #582 primitive, used exactly as designed), the buyer pays in their banking app, and checkout resolves by polling — no redirect, no continue_url.

#641 — out-of-session payment settlement is the deeper one. UCP's checkout currently assumes payment authorizes synchronously at complete — the card model. A boleto is valid for days. An OXXO voucher gets paid in cash at a convenience store. A Pix charge with a due date settles whenever the buyer gets around to it. The proposal's answer: adopt the actions primitive on the order entity (so the payment artifact outlives the checkout session), and add an order.payment_status lifecycle (awaiting_payment → paid → expired → canceled) resolved asynchronously through the order webhook — cleanly decoupling "order placed" from "payment settled."

The scope is deliberately global, not regional: the proposal follows the industry's voucher category — the bucket where Stripe groups boleto (Brazil), OXXO (Mexico), Multibanco (Europe), and Konbini (Japan). Cash vouchers, instant bank transfers, and push-rail wallets dominate commerce across Latin America, and they're growing everywhere. Until this week, UCP's order entity simply couldn't express them.

#Why this matters beyond LatAm

Three reasons this is bigger than one vendor's integration.

Actions found product-market fit in four days. When we covered the Actions merge, the first watch item was "the first Action types in the wild." The answer arrived faster than any capability adoption we've measured — and it was payments infrastructure, not a peripheral flow. The primitive's first real job is making money move in places cards don't.

The card assumption is being dismantled by the extension layer, exactly as designed. The core spec didn't need to grow boleto support; a vendor composed it from existing primitives — Actions, webhooks, extensions — and proposed one additive surface (payment_status). This is the extension-layer thesis working in production: the protocol absorbs an entire continent's payment reality without the core spec collapsing under it.

It lands squarely inside the Payments Tech Council's mandate. The Payments TC charter put "geographic and instrument expansion — local payment methods" in its Phase 2 roadmap, and nominations closed on July 28. Mercado Pago's proposals are the first concrete work items of exactly that shape, arriving before the council is even seated. Whether Mercado Pago itself sought a seat is not public — but the founding membership announcement expected around August 11 just got more interesting.

#What the fleet's payment layer looks like today

Some measured context for where extensions fit. The payment-handler layer across the observed fleet is heavily concentrated: Google Pay (~9,000 stores), Shopify's card handler (~9,000), and Shop Pay (~7,700) — a platform-template oligopoly — followed by a long tail of handlers deployed on single-digit store counts. Declared payment capability, as regular readers know, still sits at zero.

That concentration is exactly why the extension layer matters: handlers arrive by platform template, but extensions are where payment vendors differentiate — and where provenance becomes critical. Every vendor extension resolves (or fails to resolve) on our authority-bound vendor map: com.mercadopago.* capabilities, when they ship, will be verified against Mercado Pago-controlled hosts under the freshly refined binding rule, the same as everyone. Trust in a payment artifact your agent renders at checkout starts with proving who published it.

Also this week in the same layer: a returns-policy extension (dev.ucp.shopping.policy.return) from the Technical Council lead, riding the newly merged policies[] surface — post-purchase flows following payments into the extension layer.

#What to watch

• #641's review. Order-level Actions plus payment_status is an additive change with large surface area — if it lands in something like its current shape, UCP orders become settlement-aware, and the order webhook becomes the async payments backbone.
• The Payments TC founding membership (~August 11). These proposals preview the council's actual workload — and its composition will signal how much weight the instrument-expansion agenda carries.
• Authority binding on com.mercadopago.*. The first LatAm vendor namespace on the map, verified like every other. Provenance is the price of admission to the payment flow — as it should be.

#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 payment-handler index and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured the same way for everyone, without picking winners.

#Sources

• #635 — feat: add com.mercadopago.payment.display extension
• #641 — Proposal: out-of-session payment settlement
• #634 — feat: add return policy extension
• #627 — authority binding refinement (merged 2026-07-24)
• Affirm's BNPL extensions to UCP
• Related coverage: the Actions primitive · Payments Tech Council nominations · State of Agentic Commerce — July 2026