Booking a haircut, a spin class or a plumber has never had a home in the Universal Commerce Protocol. That may be about to change. On 9 October, Prasad Wangikar of Stripe filed a charter for a Local Services Domain Tech Council, backed by Meta, Wix, Squarespace, Housecall Pro, Jobber, HoneyBook and Stripe.

It's a proposal, not a decision. The issue is labelled for Governing Council review. But it's the first formal attempt to give services a council of their own, and it sets out in detail what booking needs that shopping checkout doesn't. This post covers what the charter proposes, how it would fit into UCP, and what it means for booking platforms and the businesses that use them.

#What is UCP Local Services?

UCP Local Services is a proposed domain of the protocol for booking time-based services: appointments (one-to-one sessions), group sessions (capacity-limited classes and events), reservations (shared resources such as courts, lanes and tables) and rentals (exclusive use of equipment for a set time). The charter proposes a Domain Tech Council to own it, the same kind of body that already runs lodging, food and payments.

The charter sums up the domain in one line: "real-time slot computation over staff and resource calendars, with holds". That is the one thing no existing UCP council needs.

#Why booking doesn't fit shopping checkout

The charter's problem statement explains why a haircut "looks trivial to a consumer, but the machinery underneath is not":

• Slots are computed, not stocked. Availability depends on staff, rooms and equipment at once.
• Two agents can race for the same slot. Bookings need short, time-limited holds ("TTL-based holds") so one agent's buyer doesn't lose the 3pm to another's mid-checkout.
• The booking keeps living after checkout. Reschedule, cancellation, no-show and waitlist have no equivalent in shopping.
• Payment has to follow the booking. "The buyer is not charged for a slot they do not receive."

It also explains why existing standards don't cover the whole path. iCalendar and CalDAV share calendars inside one organisation, not bookings across organisations. schema.org describes services for search, not for transactions. OpenActive's Open Booking API "covers physical-activity bookings well" but not appointments, reservations and rentals, or agentic payments. Each big scheduling platform has its own API, "which is precisely the fragmentation problem".

#How it would fit into UCP

The charter's main argument is that local services need almost everything UCP already has, plus one new layer. Discovery through /.well-known/ucp, capability negotiation, identity linking, consent, payment handlers, idempotency, webhooks and errors all stay UCP's. The council would own three things:

• a service catalog schema (duration, pricing, policy links, resource requirements),
• an availability query with slot holds,
• the booking lifecycle: create, confirm, reschedule, cancel, no-show.

Paid bookings would not get a separate payment flow. The charter proposes extending dev.ucp.shopping.checkout with a single booking object carrying the service, slot, hold, resources and policy, so create_checkout and complete_checkout confirm the payment and the booking together. Because that touches shopping checkout and payment handlers, the charter commits to landing it only with Shopping and Payments council review.

It draws clear lines with the other councils:

#Payments are where it gets new

Most service payments already work in UCP. Paying in full at booking is plain checkout. Known deposits, and known charges due at the appointment, are covered by dev.ucp.common.payment.terms, which shipped in v2026-08-25. The charter calls those "adoption, not new protocol work".

Three cases aren't covered today:

• A card held as a guarantee: authorised, and possibly released without ever being charged.
• Conditional capture: authorise at booking, then capture all, part or none depending on a cancellation or no-show.
• Pay at the counter: finish the checkout with no protocol payment at all, because the customer pays in cash or on a terminal. As the charter puts it, "a checkout that will never charge anything has no specified completion path in UCP today."

The charter proposes those for a second phase, with the Payments council owning the payment mechanics (authorisation, capture, partial capture, release) and the services council owning the booking events that trigger them. It notes they aren't scheduling-specific: pay on delivery and pay at pickup have the same shape as pay at the counter.

#The roadmap

Phase 1 is deliberately narrow: appointments and group sessions only, paid in full at booking. It covers a service catalog, availability with holds (and a no-holds path for quiet providers), bookings with signed webhook events, and the booking object on checkout. "Atomically" is defined as an observable contract rather than a promise: re-check before charging, never leave a charge without a booking, keep unknown outcomes safely retryable. The acceptance criteria include test vectors for a hold expiring during checkout, double-booking under concurrency, and a payment failure that must leave no confirmed booking.

Phase 2 widens it: free bookings with no checkout, reservations and rentals, reschedule and no-show handling, waitlists, iCalendar export, mixed carts with a product and a service in one checkout, and the new payment models. Cancellation policies would reuse the deterministic cancellation schedule work under the Lodging council "rather than defining a second, incompatible shape".

Phase 3 covers depth: vendor extensions, embedded booking UI for things like waivers and intake forms, rebooking "the usual", and memberships and class packs.

#Where the Universal Scheduling Protocol fits

This isn't starting from nothing. The Universal Scheduling Protocol (USP), developed in Wix's GitHub organisation, already registers booking capabilities in a store's UCP profile under its own dev.usp-protocol.* namespace. Our UCP for Services page tracks it; one verified UCP profile in our census declares USP bookings today.

The charter names USP as "a strong initial starting point" and recommends that, once the council exists, it discusses "naming USP as an extension of UCP for local time-based services". It also commits to folding in three open UCP proposals that have had no home council: #317 (search availability, hold a slot, book), #303 (the original services vertical request) and #479 (an availability query), "rather than shipping a fourth competing shape".

#Council or working group?

The charter asks for a full Domain Tech Council, not a working group under an existing council. Its reasons: services have "no natural parent" (a working group would put "a haircut booking under a council chartered for hotel stays or restaurant menus"), the domain needs a standing owner for a live capability family, and there's already a backlog of proposals with nobody to decide between them. It also says the submitters "will accept a DWG if the Governing Council disagrees".

The issue currently carries the gov:needs-gc-review label. Lodging followed the same path: a charter, then a seated council, then a merged booking spec.

#What it means for booking platforms and businesses

For scheduling platforms (salons, studios, clinics, trades software): the charter's offer is "one open integration instead of one per platform", while keeping pricing, staff assignment, policy and the customer relationship. Wix, Squarespace, Housecall Pro, Jobber and HoneyBook are already named in the charter. If you run a booking platform and aren't on the list, the charter is the place to engage.

For AI agent builders: one way to find availability, hold a slot and book across providers, using the same checkout, errors and negotiation as shopping. Phase 1's test vectors target the failures agents are most likely to hit: expired holds and two agents booking the same slot.

For businesses using those platforms: nothing to do yet. Today, paying in full or paying a known deposit already works through ordinary UCP checkout and payment terms. Holds, no-show fees and pay-at-the-counter wait for the council's later phases.

#What we'll watch

• The Governing Council's decision on the charter, and whether it becomes a council or a working group.
• Whether USP is adopted as the starting point, and how its namespace maps into UCP.
• The Phase 1 booking object on checkout, and the Shopping and Payments councils' review of it.
• The first live UCP profile declaring a services capability under a UCP namespace.

We'll update our UCP for Services page as it moves.

#FAQ

Does UCP support service bookings? Not yet, as a standard. A charter for a Local Services Domain Tech Council was filed on 9 October 2026 and is awaiting Governing Council review. Paying in full or paying a known deposit for a service can already go through ordinary UCP checkout and payment terms.

Who proposed the UCP Local Services council? Prasad Wangikar of Stripe filed the charter. It names Meta as a platform, and Wix, Housecall Pro, Squarespace, Jobber, HoneyBook and Stripe as businesses committing to the work.

What would UCP Local Services cover? Appointments, group sessions, reservations of shared resources such as courts and tables, and equipment rentals. Overnight stays stay with lodging, and food ordering stays with the food council.

What is a slot hold? A short, time-limited reservation of a slot while the buyer completes checkout, so two agents can't book the same time. It's one of the main things the charter says shopping checkout can't express.

How does it relate to the Universal Scheduling Protocol? The charter recommends USP as the starting point and proposes discussing it as an extension of UCP once the council exists.

Can UCP handle no-show fees or pay-at-the-counter? Not today. The charter proposes card guarantees, conditional capture after a cancellation or no-show, and pay-at-the-counter for its second phase, with the Payments council owning the payment side.

#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

• Issue #922: [DTC Charter]: Local Services, UCP GitHub, filed 9 October 2026, open (awaiting Governing Council review)
• Issue #317: Universal Appointment Scheduling, open
• Issue #303: Services Vertical — Extending UCP Beyond Physical Goods, open
• Issue #479: Booking Availability, open
• Universal Scheduling Protocol: UCP-native deployment, usp-protocol.dev
• UCP release v2026-08-25 (payment terms)
• UCP for Services, UCP Checker, USP count as of 11 October 2026

Related coverage: UCP for Services · Lodging gets its council · UCP Lodging Is Merged · UCP's Ask Is Merged