Consent & Disclosure

When an agent buys on behalf of a user, the user has surrendered part of the purchase journey. Two questions follow immediately:

1. Did the user actually authorize this specific purchase?
2. Does the user understand what they’re getting, from whom, and at what price?

This page is the answer the destination engineer needs to read before going live. The substance is product-and-UX work, not legal language — it tells you what to build into your destination so the user is informed before the order is placed.

​​ How Firmly divides responsibility

The short version: Firmly is the commerce backend. The destination owns the consent layer. Firmly will not block an order placement because the user wasn’t shown a confirmation — that is the destination’s job.

​​ What Firmly does NOT mandate

Firmly’s checkout APIs and embedded checkout UI do not enforce:

• A “review and confirm” step before order placement
• Disclosure of merchant name, item, total, or return policy to the user
• Consent capture or audit logging on the user side
• A cooling-off period
• Identity verification of the user

This is intentional. Agentic surfaces vary too widely — voice, chat, ambient, autonomous — for one consent model to fit all. Firmly leaves the surface-appropriate consent UX to the destination.

​​ What the destination should do (recommended model)

These are recommendations, not enforced rules. They reflect what we’ve seen work across early agentic deployments.

​​ Before placing the order

Surface at least these four facts to the user, in whatever form the destination’s surface allows:

1. What they’re buying (product name, variant, quantity)
2. From whom (the merchant brand — not “Firmly”)
3. Total cost including tax and shipping
4. Where it’s going (shipping address)

For text and conversational AI surfaces, this is a structured message before a “yes / confirm” reply. For voice surfaces, a clear spoken summary before “Should I place the order?” For ambient or autonomous flows, this still applies but the confirmation may be implicit (a pre-authorized spending limit, a recurring purchase rule the user previously set).

​​ Capture the confirmation

Record:

• A timestamp
• The exact text shown to the user (or audio for voice)
• The user’s response
• The session ID and any merchant references

Keep this for at least as long as the merchant’s return window — typically 30 to 90 days. This is the destination’s evidence in any chargeback or dispute.

​​ After placing the order

Surface to the user:

• The order reference — Firmly’s cart_id plus the merchant’s native order number, returned as the first-class platform_order_number field on the complete-order response (some merchants also echo platform-specific identifiers in custom_properties)
• The merchant’s thank_you_page URL from the complete-order response — that’s where the user’s relationship with the merchant continues

Do not impersonate the merchant in conversations about the placed order. Anything the user wants to do beyond placement lives on the merchant’s side.

​​ Spending controls

If the destination’s agent operates without explicit per-purchase confirmation (autonomous flows, recurring purchases, parental-allowance flows), implement spending controls on the destination side:

• A per-transaction cap
• A per-period cap
• An allowlist of merchants
• A category blocklist (alcohol, age-restricted goods, etc.)
• A revocation path the user can trigger in conversation

These are the destination’s responsibility. Firmly enforces no caps by default.

​​ Identity and “on whose behalf”

A user who is signed into the destination’s surface (the destination’s account, the destination’s auth) is the buyer of record from Firmly’s perspective. If the surface supports household accounts, child accounts, or shared sessions, the destination — not Firmly — is responsible for routing the purchase to the right person.

For SSO between the destination’s surface and the merchant — so the order appears under the user’s existing merchant account rather than as a guest order — see Firmly Connect.

​​ A checklist for the launch reviewer

When the destination’s legal, compliance, or trust team reviews the integration, they’ll typically ask:

• What does the user see before the order is placed?
• How is consent recorded and for how long?
• What spending controls are in place?
• If the merchant disputes a charge, what’s the evidence?

This page answers Firmly’s side of consent and disclosure. The destination’s application policy fills in the rest.

​​ Related

• Agentic Commerce overview — the broader solution
• Firmly Connect SSO — signing the user into the merchant at order time
• Place Order — where custom_properties and thank_you_page are returned