Agent checkout just grew credit terms. Who authorised them?

A new UCP extension lets a business offer net-30 or deposit-plus-balance and lets the buyer's side pick one. The spec is careful about rendering and explicitly silent on whether the agent may commit.

By XAgent Team · 2026-08-15

On August 14 the Universal Commerce Protocol merged an extension that changes what an agent is choosing at checkout. Until now every agentic commerce standard has modelled the agent as a buyer picking items. Payment Terms lets it pick an obligation: "The Payment Terms extension lets a Business offer the Buyer a choice of when payment for a checkout is due." Net-30 sits next to pay-now, and deposit-plus-balance sits next to paying the full stay at booking. The spec is unusually careful about how those options are displayed. It says nothing at all about whether the party selecting one was authorised to.

What actually merged

PR #602, "feat: Add Payment Terms with Well-Defined Schedules", merged to main at 17:04:32Z on August 14 — 843 added lines across six files, comprising the normative spec and its JSON schemas.

The spec document is small. A business publishes terms[]; the buyer's side writes selected_term_id; the business returns a repriced checkout. Each term is "an addressable, renderable choice composed of one or more payment schedules. Each schedule is one payment: an amount, and a complete buyer-facing statement of when it is due."

What makes it consequential is how much the selection moves. Per the spec, the recomputed response is "authoritative for all derived state — including totals, line item prices, discount eligibility, policies[], messages[], and the payment handlers offered." Choosing when you pay changes what you pay, what you are told, and what instruments you may pay with.

The spec is blunt about the implication for clients: "A Platform MUST NOT assume that the amounts shown in terms[] survive selection unchanged, and MUST re-render from the response."

The restraint is the interesting part

Two design decisions say something about what the authors think agent-side software should be trusted with.

First, the merchant does the maths. due_at "is an absolute RFC 3339 date-time", provided when the business can determine it and omitted when the date depends on a future event. In the installments example the spec states the division of labour outright: "The Business does the calendar arithmetic; the Platform reads dates." There is no recurrence rule, no anchor-plus-offset, nothing for a client to compute and get wrong.

Second, rendering has a floor that assumes minimal cooperation. A platform that reads nothing but title, description, schedules[].description and schedules[].amount "MUST be able to present what is owed and when, for every term." A business is required to author terms so that holds.

And the spec is careful not to overclaim what that floor achieves: "It does not by itself discharge a jurisdictional disclosure duty — a finance charge that must be given a prescribed prominence, for instance."

Obligations also survive the checkout. Where a disclosure governed the accepted term, the business "MUST return that disclosure on the Order with its path set to $.payment.accepted_term" — because, as the spec puts it, "An obligation disclosed at checkout does not end at checkout: it records money still owed, not context."

What the spec says it does not cover

This is the paragraph merchants should read twice. Under Out of scope:

"Payment execution. This extension discloses when money is due. It does not define credential storage, future-charge authorization, how a Business executes capture, or mandate requirements".

So the standard now has a well-specified way for a buyer's side to commit to paying later, and explicitly no position on the mandate under which that commitment was made. Recurring commerce is out too: "Schedules settle the current checkout. They do not create future purchases, renewals, or fulfillment obligations."

That is a defensible scope decision — a checkout protocol is not an authorization framework, and we have argued before that protocols move the bottleneck rather than removing it. But it leaves a specific question unanswered at a specific moment, and the moment is now a wire format.

Why "which obligation" is harder than "which item"

A mandate that says up to $200 on office supplies from approved vendors answers a question about price and category. It does not obviously answer whether the agent may accept net-30.

Consider what an ordinary optimiser does with terms[]. If the objective is to minimise cost now — and for anything that routes tasks by price, it usually is — a deposit-plus-balance term beats paying in full, and net-30 beats both. Nothing in the selection looks unusual. The checkout completes, the total may even be identical, and the principal has acquired a future liability they were not present for.

Three things follow for anyone building on this.

Deferred is a different authorisation than spend. A ceiling expressed as an amount does not constrain a commitment expressed as a date. If your mandate model has only a budget, it does not cover this.

The cheapest path defers. Any agent choosing on price will select the term that moves money furthest into the future unless something tells it not to. That is not misbehaviour; it is the objective working.

The record has to name the term. The spec gives you the hook — $.payment.accepted_term on the Order — and it is the field that makes "what did we actually agree to" answerable months later. That is the provable pillar doing real work, and it is worth writing into your order schema now rather than after the first dispute.

What's next

Watch whether a mandate format grows a term dimension. The card networks' credential work and the comment letters to the FSB both describe scope-constrained agent authority in terms of amounts, categories and merchants — none of them in terms of when payment falls due. Payment Terms has just made that a live gap rather than a theoretical one.

Meanwhile the practical merchant position is unchanged and slightly more urgent. If you are going to offer agents a choice of obligation, you need to know which agent chose, what its principal permitted, whether a deferred term was inside that, and be able to reconstruct all four. If you would rather not build that yourself, list your store on XAgent and let the open execution market hold the quote, the authorization check and the record.