Checkout profile: purchasing goods

The Stipendex profile for "an agent buys goods for a human". The payment mechanics are a direct embodiment of the 4agents order-flow v2.1 model (hold on estimate+tolerance, "ACCEPT is the source of truth for the amount", capture ≤ hold) expressed in Stipendex objects.

Separation of concerns: Stipendex covers authority and money movement; commerce orchestration (cart, stock reservations, shipping, disputes, MoR, fiscal receipts) is run by an orchestrating platform — e.g. 4agents. The boundary is defined at the bottom.

Differences from the service profile

Flow

Agent/host         Wallet                Platform (4agents)          Rail (Connect)
  │ get_quote ─────────────────────────────▶│ (stock reserve, shipping
  │ ◀── Quote{estimate+tolerance, TTL 15m} ─│  estimate — its domain)
  │──Quote──▶│ mandate: allowlist+limits    │
  │          │ HITL: total+tolerance ──────▶ principal
  │          │ ◀─ Confirmation (approve) ───
  │          │ hold(estimate+tol) ─────────────────────────────────────▶│
  │          │◀──────── Proof{mode:hold} ────────────────────────────────│
  │ place_order + Proof ────────────────────▶│ Receipt{held}
  │                                          │ … seller ACCEPT:
  │                                          │ confirms price/stock/total
  │                                          │ capture(amount_final ≤ hold)──▶│ split
  │ ◀──────── Receipt{captured, amount_final, order_id} ────────────────────│
  │
  │  DECLINE / timeout / total out of tolerance:
  │ ◀──────── Receipt{voided} ── hold released, no money moved ─────────────│

Normative rules

• C1. A Confirmation is mandatory before hold; the confirmation shown to the principal includes the total, the tolerance, and the order contents. SHOULD: principal_assertion (passkey) — strong proof of acceptance (see mandate-wallet.md).
• C2. capture only after the seller's explicit ACCEPT and only of the confirmed amount; amount_final ≤ estimate + tolerance — otherwise MUST void + re-quote + a new confirmation. No incremental auth beyond the tolerance.
• C3. Timings: Quote TTL (and the soft stock reserve) ≈ 15 min; the ACCEPT window ≪ the hold lifetime (hours, hard-capped; then auto-void). The numbers are platform configuration; Stipendex only requires ACCEPT window < hold TTL with margin.
• C4. Multi-seller: a Quote and a sub-payment are per-receiver; a partial ACCEPT = capture of accepted sub-orders, void of the rest; re-confirmation by the principal when the total changes beyond the tolerance.
• C5. Cancellation by the principal before ACCEPT → void with no losses. After capture — a refund per platform policy, outside the Stipendex happy path.
• C6. Rail configuration MUST keep the seller as merchant of record (direct charges, or destination charges with on_behalf_of) and the platform out of possession/control of funds in every flow, including refunds and disputes (see rails.md).

The evidence chain for disputes

By the time of a dispute/chargeback the platform can present a complete machine-readable chain:

Mandate (principal's signature: limits, validity, purpose)
  → Confirmation (signature + passkey: "I accept the total $92.40 ± $8.40", timestamp, channel)
    → Quote (seller's signature: contents, estimate, tolerance)
      → Proof{hold} → Proof{capture(amount_final)}
        → Receipt{captured, order_id}

This closes the main legal risk of agentic purchases ("was there acceptance?" — H5 from the 4agents analysis): the human's consent to a specific amount is recorded cryptographically, not as "a chat reply".

The Stipendex ↔ orchestrating platform boundary

The platform sees from Stipendex only: Proof/Confirmation references and Receipts. The principal's limits and allowlist are never disclosed to it.