Regent ControlSettlement Confirmation

Settlement confirmation

A completion receipt records what settled for a decision: status, amount, currency, payee. Until October 2026 every one of those facts came from the caller of /complete, the agent or its gateway, so a receipt attested to what the agent said happened. A settlement confirmation lets the other side of the payment, the merchant, PSP, custodian or API provider, state the outcome under its own signature. When it verifies, the receipt carries the counterparty’s figures, names the signer and embeds the signed statement, so anyone holding the receipt and the two public key sets can check both signatures offline.

Sending one

The counterparty signs a compact JWS and the caller passes it to /complete:

POST https://control-api.regentprotocol.org/v1/control/decisions/{decision_id}/complete
Authorization: Bearer rgnt_ctrl_…
{
  "status": "success",
  "amount": 310.0, "currency": "KZT",
  "confirmation": "<compact JWS>"
}

The JWS must look like this:

PartFieldRule
headeralgES256, EdDSA, RS256 or PS256
headerkidrequired; must appear in the issuer’s JWKS
headertypsettlement-confirmation+jwt
payloadissthe issuer URL, trusted by the control plane (see below)
payloadiatissued-at; may not lie in the future
payloadexpoptional; enforced when present
payloaddecision_idthe decision being confirmed; must equal the one in the path
payloadstatussuccess or failed
payloadamount, currencyoptional; what actually settled (currency is required with amount)
payloadpayeeoptional; who was paid
payloadrefoptional; the counterparty’s own reference, such as an order id or a transaction hash
payloadkindoptional; merchant, psp, custodian or provider

What the receipt says

ClaimMeaning
settlement_sourcecounterparty when a confirmation verified, agent otherwise. Receipts minted before this claim existed carry none and are agent-reported.
confirmed_bythe confirmation’s iss
confirmation_kidthe key that signed it
confirmation_hashsha256 of the compact JWS, also cited by the audit trail
confirmationthe JWS itself, verbatim
confirmation_ref, confirmation_kindcopied from the confirmation when present
agent_report_mismatchtrue when the caller’s own status or amount differed from the counterparty’s

With a verified confirmation the receipt’s amount, currency, payee and status are the counterparty’s. The caller’s figures are kept beside them in the settlement audit event, so a divergence is visible rather than overwritten. A failed confirmation without an amount settles the decision at zero, which releases the mandate hold.

The /complete response reports what happened: confirmation_accepted is true, false (with the reason in confirmation_error) or null when none was sent.

Trust

The control plane verifies a confirmation against the issuer’s published JWKS, fetched over https and cached. Which issuers count is configured per deployment (COUNTERPARTY_ISSUERS) and may be extended per organization. An issuer that is not trusted, a key that is not in the JWKS, a confirmation for another decision, a future iat or an expired exp are all rejected.

A rejected confirmation never fails the completion. The mandate hold must reconcile whether or not evidence arrived, so the completion is recorded from the caller’s figures, the receipt says settlement_source: agent, and the response carries the rejection code. A confirmation can only add to a receipt what it proved.

On get4agent

For prepaid purchases get4agent is the merchant of record: the buyer’s balance is debited on the marketplace, so get4agent signs the confirmation itself, with its Ed25519 issuer key published at https://get4agent.com/.well-known/jwks.json, after the charge succeeds. The reference is the listing, the supplier’s order id for a delayed fulfilment, or the on-chain transaction for an x402 purchase. If the charge fails after the supplier delivered, get4agent confirms a failed settlement at zero, so the receipt never shows a purchase that was not paid for.