Docs
Firmly Agentic Commerce
Docs
Set theme to dark (⇧+D)
  1. Docs
  2. Solutions
  3. ...
  4. Use Cases
  5. Autonomous Agent Purchasing

Autonomous Agent Purchasing

The user is not present at the moment of purchase. They authorized the agent earlier — “buy a refill when I run out”, “book the flight if it drops below $400”, “restock my dog’s food” — and now the agent acts on that authorization without an interactive confirmation.

For card payments, this requires more than just a saved token. The card network needs proof that the cardholder authorized this specific transaction — bounded by an amount cap, an expiration, and a purchase scope. Without that proof, banks decline autonomous-agent transactions as if they were unauthorized.

Firmly’s Agentic Pay is the Network Token Router that makes this safe. The cardholder enrolls once via wallet-style biometric confirmation; each subsequent purchase then runs select-card → intent → complete against the user’s virtual_card_id. The mandate — amount cap, expiry, merchant scope — is carried in the intent and enforced by the network.

​​ The mandate model

Every autonomous payment carries a mandate the cardholder pre-authorized:

Mandate field What it bounds
amount Maximum the agent may charge this transaction. The capture amount at order completion must be ≤ this.
currency_code Mandate currency — protects against FX surprises
ttl_seconds The validity window, as seconds-to-live from issuance. After it elapses the intent is no longer usable — create a fresh one
merchant_name, merchant_category_code The scope — what the agent is authorized to buy and from whom
quantity, consumer_prompt What and how many; the prompt the cardholder approved

The destination doesn’t enforce the mandate — Firmly and the card network do. The amount ceiling is checked by Firmly at order placement: a cart total above mandate.amount (or a currency mismatch) is rejected with 400 BadRequest before the network is ever called. The remaining fields travel to the network with the intent. The destination’s job is to build the mandate honestly from the user’s standing authorization.

​​ What Firmly does (and doesn’t) for this scenario

Layer Owner
The user’s standing authorization (the “buy if X” or “restock when Y” rule) Destination stores and triggers it
The mandate construction (amount cap, expiry, merchant scope) Destination builds it; Firmly forwards it to the network
One-time card enrollment via biometric / OTP / FIDO Firmly runs the Network Token Router
Virtual card token storage Firmly holds the virtual_card_id
Network-level mandate enforcement Card network (Visa, Mastercard)
Each individual transaction (intent → complete) Firmly routes through the network
Choice Default Why
Payment Agentic Pay The only Firmly payment path designed for non-present cardholders
Integration pattern Deep Link / Headless for autonomous-only; Embedded if you also enroll cards interactively Autonomous runs server-side; enrollment usually needs a browser iframe
Auth Server-to-server for the autonomous side; Browser session for the enrollment step Two-phase: enroll in-browser once, transact from server forever after
Client library Headless SDK for the browser enrollment step Wraps the iframe handshake and verification methods so you don’t write that code yourself

​​ API sequence

​​ One-time enrollment (cardholder is present)

# Endpoint Purpose
1 Enroll Submit the card; Firmly routes to Visa, Mastercard, or Discover by BIN
2 Trigger Enrollment Start the verification challenge (OTP, FIDO, or iframe handshake depending on the network)
3 Verify Enrollment Complete the verification — biometric / passkey / OTP code
4 (destination stores) Persist the returned virtual_card_id for this user

The Headless SDK’s enrollCard() wraps steps 1–3 behind a single browser call.

​​ Per autonomous transaction (cardholder is NOT present)

# Endpoint Purpose
1 Select Card Resolve the user’s stored virtual_card_id — no PAN re-entry
2 Create Intent Build the mandate (amount, currency, expiry, scope) and submit
3 Wallet Complete Order Capture the payment against the merchant — capture amount ≤ mandate amount

The destination’s scheduler / trigger fires step 1.

​​ Agent considerations

  • Build mandates honestly. The mandate is the cardholder’s authority over the agent. Setting the amount higher “just in case” defeats the protection. Match the mandate to the actual intent — the user agreed to “up to $80 for groceries this week”, not “$80 anywhere”.

  • Re-authorize on scope changes. A standing rule for “groceries from Merchant X” can’t extend to Merchant Y. If the trigger pivots to a different merchant or product category, generate a fresh mandate (which the cardholder must approve interactively if you don’t have an outstanding multi-merchant authorization).

  • Handle the decline path. Mandate violations are explicit and user-visible — a 400 BadRequest from Firmly for an over-ceiling amount, or a decline from the network. Don’t retry blindly — surface the decline to the user (in the destination’s own conversation surface) and ask whether they want to update the rule or re-authorize.

  • Mandate expiration. Mandates are time-bounded. Track expiry on the destination side and prompt the user to re-authorize before they lapse — don’t wait for the agent to try a payment and discover it failed.

  • Audit per transaction. Each autonomous purchase should write to the destination’s audit log: which rule fired, what mandate was sent, what the network returned. This is the user’s evidence in any dispute.

​​ When this fits

  • Wallets with replenishment / auto-buy features
  • Banks with delegated-purchase rules in their app
  • Brand-loyalty apps with subscription-like behavior
  • Connected devices (smart fridges, in-car AI) that buy on the user’s behalf without prompting
  • AI chat products with persistent standing rules (“buy this when…”)

​​ When this doesn’t fit

  • The user is at a screen confirming each transaction → use Smart Payment Selection Path A–D instead
  • The destination doesn’t have an existing scheduler / trigger mechanism → Scheduled/Triggered Buying describes what the destination must build (the scheduler and trigger) before autonomous purchasing works — it’s a prerequisite to build, not an alternative that runs without one
  • The card network doesn’t support the user’s card for Agentic Pay → fall back to interactive Smart Payment paths