Where Regent sits
On every rail the shape is the same: the decision happens before money moves, the amount and the counterparty are read from the rail rather than from the agent wherever the rail can name them, and the rail’s own outcome closes the decision in the receipt. What differs is the exact point where the decision is taken and who reports the outcome.
| Rail | The decision is taken… | Amount and payee come from | What closes the decision | Status |
|---|---|---|---|---|
| Stripe through the Cloud Gateway | before the request reaches Stripe; the gateway holds the Stripe key, the agent never does | the request itself, per Stripe path: amount on payment intents and charges, the line items of a checkout session, destination on transfers, the owner’s bank on payouts; refunds count as money leaving (the operations map) | Stripe’s answer to that call; receipt settlement_source: provider | Live |
| Agentcard (the owner’s own card at US merchants) | between the cart and the confirm: Agentcard reports the cart, Regent decides on its total, the confirm carries the decided amount as a ceiling Agentcard enforces | Agentcard: the cart total and the store id, never the agent | Agentcard’s order events (placed, confirmed, failed, cancelled); receipt settlement_source: provider | Live; sandbox cards in sandbox organizations |
| Any HTTP API through the gateway or the sidecar | before the call; the credential is injected after an allow | the tool’s declared sources (payee_from, the amount field); a tool that cannot name them fails closed | the provider’s response, or the agent’s /complete recorded as the agent’s report | Live |
| Your own servers (sidecar) | in the data path, as a proxy the agent talks to; the agent reaches nothing else | same as above | same as above | Live |
| Custody co-sign (a custodian signs a transfer only after Regent’s decision) | before the custodian signs: the custodian asks Regent about the transfer, signs on allow, refuses otherwise | the transfer request at the custodian: amount, asset, destination address | the on-chain transaction the custodian reports, verified on the chain; receipt settlement_source: custodian, settlement_ref the transaction hash, settlement_network the chain | Pilot with a custody provider |
| Budget envelope (AAuth Budgets) | before the first call: a slice of the mandate is issued as a budget token the resource meters itself | the token’s budget claim; the resource’s own metering | the resource’s usage reading | Live at get4agent.com (Budget envelopes) |
| Card issuer or processor pre-authorization | at authorization time, before the issuer approves | the authorization message | the issuer’s signed settlement confirmation | Published contract, no issuer wired yet: below |
Two rules hold on every row. The agent never names its own counterparty when the rail can
(payee_source: rail in the receipt says which happened), and an outcome the rail did not
report is a decision left open, never a success assumed
(Latency and failure).
What an issuer or processor would wire
The contract below is what we ask of an issuer or processor, published so that the first integration is a configuration exercise rather than a design meeting. It is the same contract the custody pilot runs on, with card vocabulary.
The hook. A synchronous call from the authorization path, before the issuer’s approval, carrying:
| Field | Required | Notes |
|---|---|---|
amount, currency | yes | minor units follow the currency’s decimals |
merchant.name, merchant.mcc | yes | the payee; the MCC lets a mandate cap by category |
auth_reference | yes | the issuer’s id for this authorization; it becomes the idempotency key |
card_reference | yes | a token or last four plus a stable id; never the PAN |
agent_id or a card-to-agent binding | yes | which agent this card is bound to |
merchant.country, channel | optional | facts a policy may key on |
The answer, within the network’s own window (Regent answers in well under a second; set your
timeout and decide in advance what a timeout means — we recommend a decline): allow, deny
or escalate with a decision_id, the refusal code when there is one, and on an allow a signed
token the issuer may keep with the authorization.
Settlement. When the transaction clears, the issuer signs a
settlement confirmation over decision_id, status,
amount and currency (a JWS, Ed25519, ES256 or RS256, with a JWKS the issuer publishes) and
posts it to Regent. Regent embeds it in the receipt. From then on the receipt says what the
issuer says, under the issuer’s key, and a chargeback is argued from one document both sides
can verify.
What the issuer never sends. The PAN, the CVV, the cardholder’s name or address. The receipt carries the rail’s references; it has no field for any of these (what is never in a receipt).