This document is the orientation page for payment-related declarations in SADAR manifests. It covers the supported payment method types, the settlement flows through which money actually moves between counterparties, how merchants are identified across SADAR and external payment systems, the X402 micropayment protocol's role in agent-to-agent commercial flows, and the inheritance resolution rules that govern how payment declarations compose across entity-level and entry-level manifest scopes.
Payment Details is the operational refinement of the Financial NFR category covered in Non-Functional Requirements. Where Financial NFRs declare the headline cost structure(per-invocation cost, currency, billing cadence), Payment Details declare the operational mechanics that make those costs settle in practice. Both work together: Financial NFRs participate in bilateral matching at discovery; Payment Details govern the actual money movement once an engagement begins.
Audience: implementers building monetized SADAR-conformant services; integration teams wiring payment infrastructure into agentic flows; financial-operations teams reasoning about reconciliation and audit across SADAR-mediated commerce.
Payment Details are the structured declarations in a manifest that govern the commercial mechanics of engagement. They sit alongside Financial NFRs in the manifest's commercial-content area: the Financial NFRs declare what the cost structure is; Payment Details declare how payment actually happens — which methods are accepted, how settlement flows, how the merchant is identified to external payment systems, and how the rules compose when payment declarations exist at multiple scope levels in the manifest hierarchy.
Payment Details have a discovery-time role and a runtime role. At discovery, they participate in matching: a requester whose payment infrastructure cannot satisfy a server's accepted payment methods is not a viable counterparty even if all other NFRs match. At runtime, they govern the actual settlement flow that follows successful invocation: which payment instrument is presented, which settlement path is followed, which merchant identifiers are recorded for reconciliation and audit.
Like all manifest content, Payment Details are signed and verifiable. A server's declaration that it accepts Method X with merchant identifier Y is cryptographically signed; recipients verify the signature before trusting any payment-relevant content. This protects against payment-fraud injection through manifest tampering and ensures that payment paths in production align with what was declared at registration.
SADAR's Payment Details support a range of payment methods to accommodate the operational diversity of agentic deployments. Each method has its own structural fields, settlement implications, and integration patterns. A manifest may declare multiple accepted methods, with the requester selecting at engagement time among methods both sides support.
The diversity reflects the reality of cross-organizational agent commerce. A traditional B2B service relationship operates well on direct invoice; a high-frequency micropayment scenario fits X402; a developer-platform integration suits API key / token. By making the method explicit in the manifest, SADAR avoids the common failure mode of payment-method assumptions being mismatched between counterparties.
Settlement is how money actually moves from the requester's payment source to the server's collection point. The same payment method can settle through multiple flows; the choice of flow has consequences for latency, dispute handling, regulatory treatment, and the parties involved.
Settlement flow is declared by the server (the recipient of payment); the requester selects from declared flows that its own payment infrastructure can support. A server declaring direct settlement and on-chain settlement, paired with a requester whose infrastructure supports both, leaves the choice to the requester or the operational policy in effect at engagement time. A server declaring only marketplace-intermediated settlement constrains the requester to engage through the relevant marketplace.
A merchant in payment terms is the recipient of payment. In SADAR, the server is typically the merchant for invocation-level payments. The merchant must be identifiable to the payment infrastructure executing the settlement — which often means external identifiers beyond the SADAR-side entity_urn. The Payment Details section declares which external identifiers apply and how they map to the SADAR identity.
Cross-referencing these identifiers within the manifest gives reconciliation tooling a deterministic mapping: an audit log entry referencing a card merchant ID can be tied back to the SADAR entity_urn through the manifest's declared mapping; an on-chain settlement to a wallet address can be similarly correlated. Without this declared mapping, post-hoc reconciliation across SADAR audit and external payment records would require fragile manual joins.
Multiple identifiers of the same type may be declared when an entity operates across jurisdictions or processor relationships — for instance, separate VAT numbers per country of operation, or distinct wallet addresses per supported chain. The Payment Details declaration is structured to accommodate this multiplicity rather than forcing a single canonical identifier per type.
X402 is the HTTP 402 Payment Required protocol designed for agent-to-agent autonomous micropayments. A server returning HTTP 402 includes structured payment requirements (network, asset, amount, recipient address); the requester's wallet (typically associated with an agent or service account) settles on-chain and retries the request with a payment proof. SADAR adopts X402 as one of the supported payment methods for scenarios where conventional billing infrastructure is impractical — most notably cross-organizational agent commerce at scale.
Why X402 specifically? Conventional billing assumes counterparties have established relationships with payment instruments configured in advance. Agent-to-agent commerce often does not have this structure: an autonomous agent invoking a previously-unknown service has no pre-existing billing relationship and cannot reasonably establish one in the moment. X402's on-chain model decouples settlement from relationship establishment — the requester needs only a funded wallet, and the server needs only to declare its accepting wallet address. Settlement happens in the same flow as the invocation, with cryptographic finality.
A SADAR manifest declaring X402support typically includes:
• Network. The blockchain network on which the server accepts settlement (Base, Ethereum mainnet, Solana, Polygon, etc.). Multiple networks may be declared; requesters choose among supported networks based on their own wallet configuration.
• Accepted assets. The token or coin denominations accepted on each declared network (typically USDC; sometimes other stablecoins; rarely native tokens given their volatility).
• Recipient wallet addresses. Per-network addresses to which payment is sent. Verified through the same cryptographic signature that protects all manifest content; recipients verify the wallet declaration is authentic before settling against it.
• Pricing terms. Either fixed per-invocation pricing or dynamic pricing computed at challenge time. Fixed pricing is declared in the manifest; dynamic pricing returns the required amount in theX402 challenge response.
• Settlement timeout. How long the server waits for on-chain confirmation before treating the payment as failed. Network-specific; faster L2 networks support tighter timeouts.
After successful X402 settlement, the requester presents a payment proof (typically a transaction hash, sometimes with a signature attesting to the payment intent) on the retry request. The proof becomes part of the audit trail — recorded in the TelemetryRecord and, where applicable, attested in SCT chain link claims. This gives post-hoc auditors a verifiable link between the invocation and its on-chain settlement: an auditor can independently verify the transaction on the relevant network and confirm the declared payment occurred for the declared invocation.
Payment Details may be declared at two scope levels in the manifest hierarchy:
• Entity-level. Payment declarations at the entity scope apply as defaults to every entry under that entity. An organization declaring “we accept these payment methods globally” at the entity level establishes the baseline that individual entries inherit unless they override.
• Entry-level. Payment declarations at the entry scope (per-agent, per-tool, per-service) apply specifically to that entry. An entry-level declaration overrides any conflicting entity-level declaration for that specific entry.
The two-level structure reflects how payment policies typically work in practice: most of an organization's services accept the same set of payment methods (the entity-level default), but individual services may have specific requirements (a free reference implementation that overrides to “no payment required,” a premium tier that overrides to “Subscription only”). Declaring both levels together lets the manifest author state defaults concisely while preserving per-service flexibility.
When a requester (or matching algorithm) needs to determine the effective Payment Details for a specific entry, resolution proceeds:
1. Look up the entry-level declaration. If present and complete for the field in question, use it directly.
2. If the entry-level declaration is absent or partial, fall back to the entity-level declaration for the missing fields.
3. If neither level declares the field, apply the spec-defined default for that field (where defaults exist) or treat the field as undeclared.
4. If both levels declare the field with conflicting values, the entry-level value wins. The entity-level value is treated as the default, not a constraint.
Resolution operates at the field level rather than the section level: a partial entry-level declaration that overrides only some fields inherits the remaining fields from the entity level. This lets entry-level declarations be minimal — stating only what differs from the entity default — rather than forcing complete restatement of the entire Payment Details section per entry.
Some fields are non-inheritable by spec design: they must be explicit at the entry level if they apply at all. Non-inheritability typically applies to fields where inheritance would mask important per-entry policy: regulatory-jurisdiction-specific identifiers that vary by service, wallet addresses that should not be silently inherited across entries with different security profiles, dispute-handling endpoints that differ by service type. The spec enumerates non-inheritable fields with their rationale; the canonical list lives in 3. NFR Schema.
The two-level structure plus non-inheritable fields together give manifest authors a clear policy lever: state common defaults at the entity level for compactness; state per-entry overrides where they differ; explicitly declare fields that cannot be inherited. The resulting manifest expresses the intent precisely without forcing either over-declaration (everything explicit at entry level) or under-declaration(everything inherited with implicit risks).
This page covers Payment Details as an architectural surface at orientation depth. Several adjacent topics are intentionally out of scope here and live in dedicated documents:
• Non-Functional Requirements — the four NFR categories (Financial, Operational, Governance, Protocol) and the three-tier strictness model. Payment Details refines the Financial category.
• Core Functional Model — the architectural framing for manifests and bilateral matching that Payment Details participate in.
• Matching Algorithm — the bilateral two-direction algorithm that evaluates payment-method compatibility alongside other manifest content.
• Taxonomy — grounding standards for currency codes (ISO 4217), legal entity identifiers (LEI), and other commercial identifiers referenced by Payment Details.
• Registry Concepts — reference glossary including entity-level and entry-level scope concepts that inheritance resolution rules apply to.
• Core Security — manifest signing and JWKS that protect Payment Details declarations from tampering.
• Telemetry Record — the per-invocation audit artifact that records actual payment proof, settlement details, and merchant-identifier resolution at runtime.