What Net Payments is (and is not)#

An agent that invokes a capability needs to answer commercial questions the transport layer cannot: what does this cost? did the payment reach the required verification tier? am I allowed to spend this? what usage fact do I bill? Net Payments answers those by signing the commercial facts around an invocation. It does not move money.

The boundary#

Net standardizes the commercial facts around capability invocation; it does not intermediate the money.

x402 (the payment wire) moves the funds on-chain. Net signs the facts around them: who the provider is, what a capability costs, whether a payment verified and to what depth, what spend policy allowed, and what was billed.

Responsibilities outside Net#

Net Payments does not:

• custody funds — no wallet, no balance, no escrow;
• process or clear payments — x402 + the chain do that;
• issue invoices, determine taxes, or run KYB / sanctions / identity checks — providers own those in their own systems;
• carry customer PII — see the data boundary below.

Wallet balances, compliance records, tax handling, and customer identity remain in provider, customer, chain, or payment-rail systems.

Design rules#

1. x402 is the wire. Net envelopes wrap x402 structures — they never replace, translate, or re-encode them.
2. Preserve x402 bytes. x402 documents ride as base64 of their original bytes; Net never re-serializes a received x402 doc. See x402 and Net.
3. Non-custodial by construction. Identity keys are not settlement keys, and there is no raw-bytes signing path. See Non-custodial signing.
4. Verification is a tier, not a boolean. A facilitator receipt is observed; depth and finality come from an independent on-chain check. See Verification tiers.
5. Spend policy decides before payment in the integrated caller path. The engine applies spend policy before signing or submitting payment. See Spend policy & approvals.
6. Network support stays outside Net core. Asset configuration, facilitator setup, scheme modules, and conformance determine which networks are enabled. See Networks.

The data boundary#

Net payment, billing, lifecycle, and failure objects carry references, commitments, signatures, quote IDs, verification outcomes, and policy decisions — not customer tax IDs, billing addresses, shipping addresses, or KYB records. This holds by construction: identities on the wire are public keys (entity IDs), the invocation input is carried as a hash, amounts are opaque atomic-unit integers, and there is no PII field on any envelope. Provider and customer records live in provider or partner systems.

You can read the boundary straight off the type. Here is every field on a net.payment.quote@1:

pub struct PaymentQuote {
    pub object: String,             // the version tag
    pub quote_id: String,           // content-derived, hex
    pub provider: EntityId,         // a public key
    pub caller: EntityId,           // a public key
    pub capability: String,         // "provider/capability"
    pub input_hash: Option<String>, // a blake3 hash — never the arguments
    pub requirements: X402Carry<PaymentRequirements>, // opaque x402 bytes
    pub asset_registry: RegistryRef,// the revision, never "latest"
    pub issued_at_ns: u64,
    pub expires_at_ns: u64,
    // … binding hash + signature
}

There is no name, no address, no account, and no argument payload — the price binds to an invocation through input_hash without the quote ever carrying what was invoked. That's what "by construction" means here: the field simply doesn't exist to be populated.

Terms acceptance, where used, means a signed acceptance commitment plus a terms hash/ID — Net does not host terms text, validate legal authority, store customer identity, or adjudicate enforceability.

What's reserved (not shipped)#

Named here so you don't build on them: disputes / refunds (net.payment.dispute@1 is a reserved tag with no semantics), RFQ / dynamic pricing, accounts / postpaid (Mode E), and inbound HTTP-402 serving (only the outbound client ships). These are roadmap, not behavior.