Paid services

When an agent pays, keep the action and the payment connected.

A payment tells you money moved. It may not tell you which service call, authorization or result the payment belonged to. PEAC records can keep those parts linked for later review.

payment-eventverified offline
Issuer
https://api.vendor.example
Event
authorized
Action
POST /v1/market-data/search
Signature
Ed25519 30cf81d6...
observation record - not a payment instruction
Payment contextObserved settlementCounterparty acknowledgmentVerifies offline
Two different questions

Payment evidence and service evidence answer different questions.

The payment system may report
  • authorization status;
  • amount and currency;
  • payment reference;
  • capture, settlement, refund, or dispute state;
  • provider timestamp.
The service evidence may report
  • requested endpoint or tool;
  • applicable terms or mandate reference;
  • input and output commitments;
  • service result;
  • gateway decision;
  • available delivery observation.

Neither source automatically proves the other source's claims. The payment provider reports the payment state; the service issuer reports the service context; the evidence case preserves and verifies the supplied artifacts.

The real questions

When an agent pays, "did money move?" is the easy part.

  • What was requested, and which policy or mandate applied?
  • Who or what authorized the action?
  • What result did the vendor return?
  • Was the action allowed, denied, captured, refunded, or disputed?
  • Can a customer, auditor, or partner verify the record later, without your systems?
Worked example

A research agent calls a paid market-data API.

The payment rail shows a charge was authorized. The signed record shows the endpoint, the terms that applied, the payment reference, the result digest, the issuer, the time, and the signature a counterparty can check.

The record preserves the payment artifact as evidence: a signed settlement receipt travels in the record's proofs, and settlement metadata is carried as a digest by default so raw payment headers never enter the signed payload.

x402 owns the payment flow and its payment-native signed artifacts. Originary preserves those artifacts inside portable records and evidence bundles that verify offline.

Verify it
npx -y @peac/cli@0.16.4 verify ./payment-event.jws --public-key ./jwks.json
Expected
Signature valid (offline).
payment-eventverified offline
Issuer
https://api.vendor.example
Event
authorized
Action
POST /v1/market-data/search
Agent
research-agent-v3
Policy
terms:v3 sha256:81af2c...
Ref
rail reference - x402-style
Result
200 sha256:9a3c1d...
Time
2026-06-12T14:08:12Z
Signature
Ed25519 30cf81d6...
observation record - not a payment instruction

The payment provider reports the payment state. The service issuer reports the service context.

Where it fits

Records can sit around commerce workflows you already run.

Payment flows
x402 paid API callsUsage-billed API eventsAP2 or MPP payment flowsRefunds, disputes, and settlement observations
Gateway and agent traffic
Gateway allow, deny, route, or throttle decisionsAgent-to-agent commerce handoffsAgent spend attribution for finance and audit review
Review and evidence
Mandate and terms-version bindingProcurement and audit-review bundlesCounterparty acknowledgment records

Examples are interoperability surfaces, not partnership claims. Originary composes with payment rails, identity systems, and agent protocols.

Boundaries

What Originary does not do.

  • It does not custody funds.
  • It does not process payments.
  • It does not replace your ledger or accounting system.
  • It does not decide tax treatment.
  • It does not require a chain, or another company to use Originary.

It issues, inspects, and verifies signed records from commerce workflows you already run.

Beyond single records

Broader evidence coverage, same wire format.

PEAC v0.16.4

Portable evidence beyond single signed records: the wire format stays stable while evidence coverage broadens.

Paid resource recordsPaid MCP tool recordsLinked counterparty acknowledgmentsMerkle commitment helpersExternal evidence anchoringAgent spend attributionAgent run lineage recordsConsented action recordsRuntime lineage exports

Broader evidence coverage, not a new payment rail, gateway, or policy engine.

Start with one paid workflow where another party asks what happened.

A paid API call, an MCP tool that triggers a charge, a gateway decision, a payment authorization, or a dispute review.

Logs stay local. Signed records travel.