Standing Intents

Overview

A standing intent is a recurring purchase authorization that a shopper's shopping agent or app holds against your store. The shopper authorizes it once, with a signed payment mandate. After that, the agent can place repeat orders ("draws") against the grant without a fresh approval each time — but only inside hard limits that your store enforces on every single draw.

You see every grant in the dashboard under Orders → Standing intents, and you can kill any of them instantly.

This is different from Subscriptions. A subscription bills a fixed product on a fixed schedule that you configure. A standing intent is held by the buyer's side: their agent decides what to reorder and when, and your store's job is to enforce the caps the shopper agreed to.

The limits on every grant

Each standing intent carries limits that are checked server-side on every draw. None of them can be bypassed by the agent:

Limit	What it does
Per-draw cap	The most a single draw may total. Always at or below the period budget.
Period budget	A rolling spend ceiling over the grant's period (1 to 365 days, 30 by default). Spend is summed from real orders, so a cancelled or refunded draw frees its budget.
Draw count (optional)	A cap on how many draws may run per period, on top of the spend ceiling.
Expiry	Every grant expires. A grant never lives longer than one year, even if the mandate asks for more.
Currency	The grant is pinned to the currency it was authorized in. If you later change your store's base currency, existing grants stop drawing and the shopper has to authorize a new one.
Shipping address	A grant can bind a delivery address at creation. If it does, every draw ships there — a draw cannot redirect delivery.

What a draw actually is

A draw is a normal order. It goes through the same pipeline as any other agent order on your store: prices are recomputed from your live catalog (the agent's claimed prices are ignored), tax is calculated, the fraud screen runs, and stock is reserved atomically. The order lands in Orders like any other sale and is linked back to its standing intent, which is how the period spend is counted.

The one thing a draw skips is the per-order payment mandate — the grant itself is the authorization.

How the shopper pays

There are two modes, and the default is the cautious one:

On-session — each draw produces a payment to confirm. The shopper (or their app, with the shopper present) completes it. This is how every grant starts.
Auto-charge — the shopper saves a card through a Stripe SetupIntent on your connected Stripe account. Once confirmed, draws charge that card off-session with no further interaction.

A card can never be attached when the grant is created. Vaulting a card is a separate, token-authorized step that the shopper confirms, so an agent cannot arm a card it does not control. In the dashboard, the Billing column shows which mode each grant is in.

Your controls

Open Orders → Standing intents to see every grant against your store: buyer, status, per-draw and period caps, billing mode, whether the authorizing mandate was cryptographically signed, draws and spend to date, and expiry.

Revoke stops all future draws immediately. Revocation is serialized against in-flight draws, so a draw cannot slip through while you revoke. It cannot be undone; the shopper authorizes a new grant if they want to resume.
Viewing and revoking requires the orders permission, and every revocation is written to the audit log.
The shopper's side can also read state and revoke at any time, using the secret token issued when the grant was created.

Revoking reduces risk, so it works even when other account actions are restricted.

Security model, briefly

The grant is authorized by a signed payment mandate whose maximum covers the full period budget. A signed mandate is single-use: it can authorize one order or one standing intent, never several.
Draws are authorized by a secret token minted at creation and shown exactly once. Your store keeps only a hash, so the token cannot be recovered from the database. A wrong token and a nonexistent grant return the same error, which keeps grant ids unguessable in practice.
The platform can enforce cryptographically verified mandates, in which case unsigned grants are refused outright. Whether a signature is required is advertised in the store's agent manifest, so agents know before they try.

For developers and agent builders

A store's agent manifest at https://<storefront-domain>/.well-known/ucp advertises the standing_intents capability and the endpoint URLs. The endpoints live on the merchant's storefront domain and are rate-limited:

Action	Endpoint
Create a grant	`POST /api/agent/standing-intents`
Read state (status, remaining budget)	`GET /api/agent/standing-intents/{id}`
Place a draw	`POST /api/agent/standing-intents/{id}/draw`
Vault a card for auto-charge	`POST /api/agent/standing-intents/{id}/payment-method`
Revoke	`POST /api/agent/standing-intents/{id}/revoke`

Creation returns the grant plus a one-time drawToken. Store it — it is never shown again, and every later call must send it in the x-standing-intent-token header. Draws take items (product ids and quantities) and return the order id and payment details; totals are always the server's own repricing.

Questions? Contact [email protected] or visit the FAQ at bestwebby.com/faq.

Documentation