AGTP-Commerce: Open Commerce Specification for Agent-to-Agent Transactions

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses terminology from [AGTP], [AGTP-IDENTIFIERS], [AGTP-TRUST], [AGTP-CERT], and [AGTP-LOG]. Selected additional terms specific to this document:¶

Pricing Manifest:

A structured document advertising an agent's pricing, accepted settlement rails, refund policy, and related commerce metadata. Published by the agent and discoverable through DESCRIBE.¶

Settlement Endpoint:

An identifier indicating where transaction settlement is routed. Refers to a payment provider relationship the agent operator has established independently. Carries no banking information.¶

Transaction Record:

The dual-signed record of a commerce agreement between two agents. Created by the TRANSACT method, logged through AGTP-LOG.¶

Payment Provider:

An application-layer service that consumes AGTP-Commerce transaction information and executes financial settlement through existing financial infrastructure. Examples include traditional payment processors, banking services, cryptocurrency rails, and specialized agent-economy payment services.¶

Owner Authorization:

The cryptographic proof that an agent's owner (the principal recorded on the Agent Genesis) has authorized the spending envelope signaled in Budget-Limit headers. Carried as the Intent-Assertion header of [AGTP-MERCHANT-IDENTITY] (Section 4.2).¶

Dispute Window:

The period during which either party to a transaction may challenge the transaction's completion or terms, declared in the pricing manifest at transaction time.¶

2.1. What This Document Specifies

This document specifies seven things:¶

1. The Pricing Manifest format used by agents to advertise pricing (Section 3).¶

2. Extended Budget-Limit header semantics for signaling authorized spending envelopes (Section 4).¶

3. The TRANSACT method for committing to agent-to-agent transactions (Section 5).¶

4. The settlement endpoint declaration mechanism for indicating payment provider integration (Section 6).¶

5. The audit-trail-based receipt mechanism using AGTP-LOG transaction records (Section 7).¶

6. The dispute composition surface for application-layer dispute resolution (Section 8).¶

7. The negotiated tier mechanism for trusted-partnership pricing outside public manifests (Section 9).¶

2.2. What This Document Leaves to Others

This document leaves to other specifications and to the parties themselves:¶

• Payment processing. How a payment provider executes financial settlement through its infrastructure. This is the payment provider's internal operation.¶

• Settlement timing. When and how money actually moves between accounts. The pricing manifest declares expected timing; the payment provider enforces it.¶

• Dispute resolution mechanics. What evidence AGTP-Commerce carries is specified. How dispute resolution services consume that evidence and reach resolution is application-layer.¶

• Currency conversion. Multi-currency settlement happens at the payment provider layer.¶

• Tax reporting formats. Tax authorities have their own reporting formats. AGTP-LOG transaction records provide evidence that tax-reporting services can consume.¶

• KYC, AML, and financial compliance. These are the responsibilities of regulated payment infrastructure. AGTP-Commerce carries structural records that compliance services use.¶

• Cryptocurrency-specific mechanics. Wallet addresses, token specifications, blockchain network identifiers, and crypto settlement details are out of scope. The settlement endpoint mechanism accommodates cryptocurrency rails through opaque identifiers without specifying internal formats.¶

This narrow scope keeps AGTP-Commerce defensible as a protocol specification. The document specifies messaging structures; payment infrastructure operation is outside it.¶

3.1. Manifest Document

An agent advertising commerce capability publishes a Pricing Manifest as a structured document. The manifest is discoverable through the DESCRIBE method per [AGTP] or via dedicated discovery paths per [AGTP-DISCOVERY]. The manifest media type is application/agtp-pricing+json.¶

The manifest declares the agent's pricing tiers, accepted settlement rails, refund policy, dispute window, trust threshold requirements, and related commerce metadata. The manifest is a static document updated at the agent operator's discretion. It is fixed before any request arrives; negotiated tiers are addressed separately in Section 9.¶

3.2. Manifest Schema

A minimal Pricing Manifest contains:¶

{
  "spec_version": "1.0",
  "agent_id": "agtp://agents.acme.com/concierge",
  "owner_id": "lei:5493001KJTIIGC8Y1R12",
  "currency": "USD",
  "tiers": [
    {
      "tier_name": "free",
      "price": "0.00",
      "scope": "discovery:query inquiry:basic",
      "trust_threshold": null
    },
    {
      "tier_name": "standard",
      "price": "0.05",
      "unit": "per-call",
      "scope": "booking:read booking:write",
      "trust_threshold": 0.6
    },
    {
      "tier_name": "premium",
      "price": "0.25",
      "unit": "per-call",
      "scope": "booking:read booking:write booking:expedited",
      "trust_threshold": 0.85
    }
  ],
  "settlement_endpoints": [
    "settlement:stripe-merchant-2891",
    "settlement:ach-routing-acme"
  ],
  "settlement_timing": "net-7",
  "refund_policy": "audit-verified",
  "dispute_window": "P7D",
  "last_updated": "2026-06-27T00:00:00Z",
  "signature": "..."
}

3.3. Manifest Discovery

Agents publish their Pricing Manifest at substrate-native paths discoverable through standard AGTP mechanisms. Recommended paths:¶

The manifest MAY also be referenced from the agent's Identity Document ([AGTP-IDDOC], optional field pricing_manifest_uri), from its AGTP-CERT, or returned in DESCRIBE responses. The recommended discovery flow:¶

1. The requesting agent invokes DESCRIBE on the target agent.¶

2. The DESCRIBE response includes a pricing-manifest-uri field pointing to the manifest location.¶

3. The requesting agent fetches the manifest.¶

4. The requesting agent evaluates whether the manifest's tiers, trust thresholds, and settlement endpoints match its needs.¶

3.4. Manifest Updates

Pricing Manifests MAY be updated by the publishing agent. Each update MUST:¶

• Increment a version or timestamp field¶

• Be re-signed with the agent's current certificate¶

• Apply only to transactions initiated after the update timestamp¶

Transactions in progress at the time of a manifest update MUST complete under the manifest version in effect at transaction commitment.¶

4.1. The Budget-Limit Header

[AGTP] names Budget-Limit among its request headers and places its specification in this document. Budget-Limit is an OPTIONAL request header declaring the maximum resource consumption the principal authorizes for one method invocation, as a list of unit=value members whose units are drawn from the AGTP Budget Unit Registry of [AGTP]:¶

Budget-Limit = budget-member *( OWS "," OWS budget-member )
budget-member = unit "=" value
unit          = 1*( ALPHA / DIGIT / "-" )   ; registered unit name
value         = 1*DIGIT [ "." 1*DIGIT ]     ; per the unit's format

Budget-Limit: USD=10.00, ttl=3600
Budget-Limit: tokens=5000, compute-seconds=120, USD=10.00, ttl=3600

A financial member names a registered currency unit (ISO 4217 code per [ISO4217]; USD, EUR, and GBP are the initial registrations) and carries a decimal value at the unit's precision. The ttl member, in seconds from the request's Request-Signature timestamp, bounds the budget's lifetime and is RECOMMENDED on every commerce request; a request whose ttl has elapsed when the server evaluates it is refused with 462 and reason budget-expired. Version 00 of this document carried the commerce envelope as a JSON object in this header; that form is withdrawn so that one grammar serves base AGTP and this document.¶

Two status codes attach to the header and are distinct. 456 Budget Exceeded ([AGTP]) is returned when executing the method would exceed the declared limit, a fact the server learns during or before execution. 462 Insufficient Budget (this document) is returned when the envelope is insufficient for the receiving agent's price or settlement requirements before any execution, a fact the server learns by comparing the header with its pricing manifest.¶

4.2. Owner Authorization of the Envelope

The signed authorization of a spending envelope by the agent's owner or principal is carried in the Intent-Assertion header of [AGTP-MERCHANT-IDENTITY], a detached JWT whose amount_ceiling claim is the authorized maximum and whose agent_id names the spending agent. Version 00 of this document carried a separate owner_auth signature inside Budget-Limit; the Intent Assertion already serves that purpose, and one signed envelope is better than two. This document adds one optional claim to the Intent Assertion:¶

settlement_method:

The settlement endpoint identifier (Section 6) the principal authorizes for this envelope. When present, the request's settlement_method parameter MUST equal it.¶

The requesting agent carries the settlement method it is prepared to use as the settlement_method parameter of the method body (PURCHASE or the request that precedes TRANSACT). It MUST match one of the target agent's declared settlement endpoints for a transaction to proceed.¶

4.3. Budget Validation

When an agent receives a commerce request carrying Budget-Limit, it MUST validate:¶

1. The header parses per Section 4.1 and names a currency unit the receiving agent's manifest prices in, or one it can convert at a rate it states in the response.¶

2. The ttl has yet to elapse.¶

3. The financial member is sufficient for the price of the requested service at the requesting agent's eligible tier.¶

4. The settlement_method parameter matches at least one of the receiving agent's declared settlement endpoints.¶

5. When the receiving agent's policy requires owner authorization for the operation class or amount, an Intent-Assertion is present, verifies per [AGTP-MERCHANT-IDENTITY], names the requesting Agent-ID, and carries an amount_ceiling at or above the financial member.¶

If validation succeeds, the receiving agent MAY proceed with the transaction commitment per Section 5. If validation fails, the receiving agent MUST respond with 462 Insufficient Budget and a reason from budget-unparseable, budget-expired, price-exceeds-budget, settlement-unsupported, owner-authorization-required, or owner-authorization-invalid, optionally including the actual price and acceptable settlement methods in the response body.¶

5.1. The TRANSACT Method

TRANSACT is a new AGTP method that creates the structural commitment to an agent-to-agent transaction. The method is invoked by the receiving agent (the seller) after a budget-validated request from the calling agent (the buyer). TRANSACT produces a Transaction Record signed by both parties.¶

Category: TRANSACT. Idempotent: No (each invocation creates a new record). Required Authority-Scope: commerce:transact.¶

The TRANSACT method establishes:¶

• The agreed price and pricing tier¶

• The work to be performed (referenced via the original request)¶

• The agreed settlement endpoint and timing¶

• The dispute window¶

• Both parties' signatures¶

5.2. Transaction Record Structure

A Transaction Record contains:¶

{
  "transaction_id": "txn-2026-06-27-abc123",
  "buyer": {
    "agent_id": "agtp://agents.bigco.com/orchestrator",
    "owner_id": "lei:5299002IZHCT9HFFP822",
    "principal_id": "principal-cfo-bigco",
    "signature": "<buyer JWS signature>"
  },
  "seller": {
    "agent_id": "agtp://agents.acme.com/concierge",
    "owner_id": "lei:5493001KJTIIGC8Y1R12",
    "signature": "<seller JWS signature>"
  },
  "price": {
    "amount": "0.25",
    "currency": "USD",
    "tier": "premium"
  },
  "work_reference": {
    "method": "BOOK",
    "request_id": "req-2026-06-27-xyz789",
    "scope": "booking:expedited"
  },
  "settlement": {
    "endpoint": "settlement:stripe-merchant-2891",
    "timing": "audit-verified"
  },
  "dispute_window": {
    "expires_at": "2026-07-04T00:00:00Z"
  },
  "committed_at": "2026-06-27T14:30:00Z",
  "log_entry_ref": "agtp-log://logs.acme.com/2026/06/27/txn-abc123"
}

5.3. Commitment Workflow

The transaction commitment workflow proceeds as follows:¶

1. The buyer invokes a method (BOOK, EXECUTE, or similar) carrying a valid Budget-Limit header per Section 4.¶

2. The seller validates the budget signaling and confirms the request is eligible at a specific pricing tier per its manifest.¶

3. The seller invokes TRANSACT, generating a draft Transaction Record with the seller's signature.¶

4. The buyer receives the draft Transaction Record, validates it against the original request and pricing manifest, and adds the buyer signature.¶

5. The completed Transaction Record is logged through AGTP-LOG per Section 7.¶

6. The seller proceeds with the requested work.¶

7. Settlement occurs through the payment provider integration per the declared settlement field.¶

5.4. Cancellation Before Commitment

Between the seller's draft Transaction Record signature and the buyer's countersignature, either party MAY cancel by sending a TRANSACT cancellation. Cancellation MUST be logged through AGTP-LOG with the cancellation reason. No settlement occurs for canceled transactions.¶

6.1. Settlement Endpoint Identifiers

The settlement endpoint mechanism allows agents to declare which payment provider integrations they accept without disclosing banking information at the protocol layer. Settlement endpoints are opaque identifiers that refer to the agent operator's payment provider relationships, which are established independently of AGTP.¶

The recommended identifier format:¶

settlement:<provider-id>-<account-reference>

Examples:¶

• settlement:stripe-merchant-2891 (Stripe merchant account)¶

• settlement:paypal-merchant-acme (PayPal merchant account)¶

• settlement:ach-routing-021000021-account-acme (ACH routing)¶

• settlement:wire-swift-CHASUS33-acme (wire transfer)¶

• settlement:crypto-eth-0x742d... (Ethereum wallet)¶

• settlement:agent-economy-XYZ-account-acme (specialized provider)¶

The actual format of the account-reference portion is provider- specific. AGTP-Commerce leaves provider-specific formats unstandardized; it standardizes the use of opaque identifiers as the integration surface.¶

6.2. Payment Provider Integration

Payment providers integrate with AGTP-Commerce by:¶

1. Operating their existing payment infrastructure under their own regulatory framework.¶

2. Providing agent operators with a mechanism to register and obtain a settlement endpoint identifier.¶

3. Consuming Transaction Records from AGTP-LOG (or from the agent operator's local log access) to determine when settlement should occur.¶

4. Executing financial settlement through their existing infrastructure using the Transaction Record as the supporting documentation.¶

5. Reporting settlement completion back to the agent operator and optionally to AGTP-LOG for transaction lifecycle completion.¶

The payment provider's internal operations remain outside the scope of AGTP-Commerce. The integration surface is the Transaction Record format and the settlement endpoint identifier.¶

6.3. The Agent-Economy Payment Provider Opportunity

AGTP-Commerce creates an architectural slot for specialized agent-economy payment providers. While traditional payment processors (Stripe, PayPal, banking merchant services) can integrate with AGTP-Commerce immediately, the agent economy has characteristics that specialized providers are positioned to serve better:¶

• Aggregated micro-billing. Agents may transact in small amounts frequently. Aggregating thousands of $0.001 transactions into periodic settlements reduces per-transaction overhead.¶

• Multi-currency agent settlement. Agents may transact in various denominations including cryptocurrency. Specialized providers can handle conversion to operator-preferred currency.¶

• Agent-aware dispute resolution. Agent transactions have characteristics (machine-readable audit trails, deterministic verification of work completion, signed attestations) that traditional dispute processes were never built around.¶

• Agent-specific compliance. Tax reporting, AML compliance, and KYC for agent operators is domain-specific work.¶

This document explicitly invites both incumbent payment infrastructure and new entrants to operate as AGTP-Commerce payment providers. Vendor-neutrality is preserved throughout; the specification favors no provider category.¶

7.1. Transaction Records in AGTP-LOG

Every committed Transaction Record MUST be committed to AGTP-LOG as a commerce-transaction-committed statement (Section 7.2). The statement carries the record's digest and the parties and omits the record itself, since [AGTP-LOG] statements are public; the full record is held by both parties and disclosed to the payment provider or a dispute service against the committed digest. The log entry serves multiple purposes:¶

• Receipt for buyer. Proof the transaction was committed at the agreed price for the agreed work.¶

• Receipt for seller. Proof the buyer authorized the transaction and committed to settlement.¶

• Justification for settlement. Payment providers consume the log entry as supporting documentation for settlement execution.¶

• Evidence for disputes. If either party disputes the transaction, the AGTP-LOG entry is the authoritative record of what was agreed.¶

• Audit record for compliance. Tax authorities, regulators, and audit functions consume the log entry as transaction evidence.¶

7.2. Log Entry Format

This document registers the commerce-transaction-committed event type in the AGTP-LOG event-type registry of [AGTP-LOG]. The agtp-subject is the seller's Canonical Agent-ID (the agent that invoked TRANSACT); the payload is a CBOR map, deterministically encoded per [RFC8949]:¶

{
  "transaction-id": <text>,
  "record-hash": <bytes>,                ; SHA-256 of the canonical
                                         ; Transaction Record
  "buyer": <bytes>,                      ; buyer Canonical Agent-ID
  "seller": <bytes>,                     ; seller Canonical Agent-ID
  "committed-at": <text>,                ; RFC 3339
  "settlement-timing": <text>,           ; immediate, net-N, ...
  "log-position": <uint>,
  "previous-tree-size": <uint>
}

The amount, the tier, and the work reference stay in the Transaction Record and off the public log. The log operator signs the statement and the usual AGTP-LOG metadata applies:¶

• Entry timestamp¶

• Log operator signature¶

• Optional SCITT cross-witnessing per [AGTP-LOG]¶

The cryptographic guarantees of AGTP-LOG (append-only, signed by log operator, optionally cross-witnessed) apply to commerce transactions the same way they apply to other AGTP operations.¶

7.3. Work Completion Records

Transaction Records capture the commitment to perform work. Separate log entries MAY record the completion of work. The completion record references the original Transaction Record and includes:¶

• Completion timestamp¶

• Seller's attestation that work was performed¶

• Optional buyer's attestation that work was received satisfactorily¶

• References to any artifacts or deliverables produced¶

Settlement timing of audit-verified requires a work completion record before payment provider execution. Settlement timing of immediate or net-N requires no explicit completion attestation.¶

8.1. Evidence AGTP-Commerce Carries

When a transaction is disputed, AGTP-Commerce carries evidence that dispute resolution services consume:¶

• The signed Transaction Record from AGTP-LOG¶

• The original request and response messages¶

• Any work completion records and attestations¶

• Audit trail entries showing intermediate operations¶

• Trust score history of both parties per [AGTP-TRUST]¶

This evidence is cryptographically verifiable through standard AGTP mechanisms (signature verification, log integrity, certificate chain validation).¶

8.2. Application-Layer Dispute Resolution

Actual dispute resolution mechanics happen at the application layer. Dispute resolution services consume AGTP-Commerce evidence and apply their own resolution processes. Examples of dispute resolution service categories:¶

• Payment provider dispute services. Traditional payment processors have established dispute resolution processes that can be extended to agent transactions.¶

• Specialized agent-economy arbitrators. New entrants may emerge specializing in agent dispute resolution, leveraging AGTP-Commerce evidence formats.¶

• Industry-specific arbitration. Financial services arbitration, e-commerce dispute resolution, and similar industry-specific services compose with AGTP-Commerce for transactions in their domain.¶

• Court-system integration. For transactions warranting legal proceedings, AGTP-Commerce evidence is structured to support legal discovery and admission.¶

AGTP-Commerce specifies what evidence is available; dispute resolution services choose how to use it. The protocol favors no particular dispute resolution model.¶

9.1. Beyond Public Pricing

Static pricing manifests cover the public commerce case where any qualified agent can transact at advertised tiers. Some agent relationships involve pre-established partnerships with negotiated terms outside public pricing. AGTP-Commerce accommodates these through negotiated tiers.¶

A negotiated tier is a pricing arrangement established between two agents (or their operators) outside the public manifest. The arrangement MAY include:¶

• Volume commitments and corresponding discounts¶

• Dedicated capacity allocations¶

• Specialized service tiers¶

• Custom dispute resolution arrangements¶

• Different settlement timing or methods¶

9.2. Carrying Negotiated Tiers

Agents engaged in a negotiated tier relationship MAY signal this through:¶

• A partnership_tier field in the requesting agent's request, referencing a pre-established agreement¶

• A separately signed partnership credential carried alongside the request¶

• An AGTP-CERT extension referencing a partnership agreement¶

Receiving agents validating a negotiated tier request MUST verify the partnership credential against their records of agreed partnerships. The TRANSACT workflow proceeds the same way as for public pricing, with the partnership terms substituting for the public manifest terms.¶

9.3. Public vs. Negotiated Coexistence

An agent MAY simultaneously offer public pricing through its manifest and negotiated tiers to specific partners. The two mechanisms compose without conflict. Public pricing applies as the default; negotiated tiers apply when the calling agent presents a valid partnership credential.¶

10.1. AGTP Base

AGTP-Commerce specifies the Budget-Limit header that [AGTP] names and assigns here (Section 4.1), and adds the TRANSACT method. The base specification's wire format, authentication, and identity headers are used unchanged.¶

10.2. AGTP-IDENTIFIERS

Transaction Records carry Agent-IDs, the owners resolved from their Identity Documents, and per-request principal_id values as defined in [AGTP-IDENTIFIERS]. The principal_id is the per-request acting-principal identifier lifted from external IdP credentials when a Pattern 2 External Identity Provider composition is in effect per [AGTP-COMPOSITION]; it is distinct from the agent's permanent Owner-ID. No new identifier types are introduced.¶

10.3. AGTP-TRUST

Trust thresholds in pricing manifests reference the trust score format defined in [AGTP-TRUST]. Behavioral evidence from transaction outcomes (completion rate, dispute frequency, payment timeliness) provides input to trust scoring per the consumer behavior section of [AGTP-TRUST].¶

The credit-rating-analogous trust provider framing in [AGTP-TRUST] applies to commerce: credit bureaus and specialized agent trust providers may incorporate commerce behavior into trust scoring.¶

10.4. AGTP-CERT

Pricing manifests MAY be referenced from AGTP-CERT extensions, binding the pricing structure to the agent's cryptographic identity. Settlement endpoint declarations MAY be carried as certificate extensions for high-assurance applications.¶

10.5. AGTP-LOG

Transaction Records are logged through [AGTP-LOG]. Commerce operations inherit AGTP-LOG's cryptographic properties (append-only, signed, optionally cross-witnessed). Settlement justification and dispute evidence rely on AGTP-LOG integrity.¶

10.6. AGTP-MERCHANT-IDENTITY

[AGTP-MERCHANT-IDENTITY] and AGTP-Commerce cover related but distinct concerns and compose together; neither substitutes for the other. The relationship is intentional:¶

AGTP-MERCHANT-IDENTITY specifies the merchant-side identity model for agents transacting through payment networks. It defines Merchant-ID, Merchant Manifest Document, the Merchant-Manifest-Fingerprint request header, and the merchant- lifecycle states. It establishes the identity primitives that payment networks (Visa, Mastercard, AMEX, and similar) consume to recognize an agent as a known merchant. The PURCHASE method in AGTP-MERCHANT-IDENTITY is the payment-network-mediated transaction primitive backed by merchant identity verification (and is the method that returns 458 Counterparty Unverified when merchant identity fails).¶

AGTP-Commerce (this document) specifies the broader transaction structure: pricing manifests, budget signaling, the TRANSACT method for transaction commitment between any two AGTP agents, settlement endpoint identification, audit-trail-based receipts, and dispute composition surfaces. It requires no payment network mediation. Agents transacting agent-to-agent without a payment network intermediary use the TRANSACT method and the settlement endpoints that the receiving agent's operator has independently configured.¶

The documents compose: agents transacting through payment networks MAY use both AGTP-MERCHANT-IDENTITY (for the payment-network-side identity and PURCHASE flow) and AGTP-Commerce (for pricing manifests, budget signaling, and audit-trail receipts). The PURCHASE method defined in AGTP-MERCHANT-IDENTITY and the TRANSACT method defined in this document are distinct primitives with distinct verification chains; agents and payment infrastructure choose which is appropriate based on whether a payment network is mediating the transaction.¶

For agents in a payment-network-mediated transaction, the receiving agent's pricing manifest MAY declare settlement_endpoints that reference the payment network's settlement infrastructure (e.g., settlement:visa-acquirer-<id>); the merchant identity primitives in AGTP-MERCHANT-IDENTITY then provide the payment-network-side identification for that settlement.¶

10.7. AGTP-LEI

For agents deployed by LEI-holding legal entities, institutional identity per [AGTP-LEI] provides verifiable institutional identification for regulated settlement. Transaction Records carrying LEI-anchored Owner-IDs enable settlement through infrastructure that requires institutional verification.¶

10.8. AGTP-PRESENCE

Pricing-aware discovery composes with the Presence layer in [AGTP-PRESENCE]. Agents can be discovered with capability matching plus pricing constraints in a single query. The capability partition dimension in Presence overlays composes with the scope-based pricing tiers in commerce manifests.¶

10.9. AGTP-DISCOVERY

The DISCOVER method per [AGTP-DISCOVERY] accepts max_cost and cost_unit and returns candidates whose indexed price fits, per Section 3.3.1; the manifest URI rides with each result's Identity Document, and the manifest itself is fetched and verified before any price is relied upon. Anticipatory Discovery Services (ADS) introduced in [AGTP-DISCOVERY] MAY preload pricing-aware predictions, expanding agent awareness with commerce-eligible candidates.¶

11.1. Manipulation Resistance

Pricing manifests MUST be signed by the publishing agent's certificate. Verifiers MUST check the signature before accepting manifest contents. Manifest tampering during transit is prevented by signature verification.¶

Transaction Records require signatures from both buyer and seller. Neither party can unilaterally modify a committed Transaction Record.¶

Where the receiving agent's policy requires it, a spending envelope carries the owner's or principal's Intent Assertion. An agent cannot forge an authorized envelope; the assertion is signed by the principal and verifies per [AGTP-MERCHANT-IDENTITY].¶

11.2. Settlement Risk Acknowledgment

AGTP-Commerce leaves settlement risk in place. Payment providers may fail to execute settlement for reasons including counterparty insolvency, regulatory action, technical failure, or fraud. The protocol carries the structural transaction record; settlement execution depends on the payment provider relationship.¶

Agents and their operators SHOULD evaluate payment provider counterparty risk independently of AGTP-Commerce protocol guarantees. The protocol provides evidence that settlement was agreed and guarantees nothing about whether settlement will occur.¶

11.3. Dispute Evidence Integrity

The integrity of dispute evidence depends on AGTP-LOG integrity. If log operators are compromised or collude with one party, dispute evidence may be falsified. SCITT cross-witnessing per AGTP-LOG SHOULD be used for high-value transactions to provide independent verification of log entries.¶

11.4. Owner Authorization Verification

The Intent Assertion (Section 4.2) is the load-bearing mechanism for ensuring agents transact within authorized envelopes where policy requires one. Receiving agents MUST verify it before accepting such a transaction. Compromised owner keys can authorize unauthorized transactions; owner key security is the responsibility of the owner's identity infrastructure.¶

11.5. Settlement Endpoint Verification

Settlement endpoint identifiers are opaque to AGTP-Commerce. An agent cannot verify through the protocol that a settlement endpoint identifier corresponds to a legitimate payment provider relationship. Verification of settlement endpoint legitimacy is the responsibility of the calling agent's risk evaluation, typically through out-of-band relationships with the payment provider or through trust provider services that maintain settlement endpoint reputation information.¶

11.6. Refund and Dispute Window Abuse

Pricing manifests declaring overly long dispute windows or aggressive refund policies may attract abusive callers. Agents SHOULD monitor dispute and refund rates and adjust manifest terms as needed. Trust scoring per [AGTP-TRUST] SHOULD incorporate dispute and refund behavior as input.¶

13.1. TRANSACT Method Registration

The AGTP Method Registry of [AGTP] holds the method floor; methods beyond it are registered through the AGTP-METHODS catalog. This document requests registration of TRANSACT in that catalog, in the transaction category, with this document as reference:¶

13.2. Budget-Limit Header

This document is the reference for the Budget-Limit request header in the AGTP Header Field registry of [AGTP] (Section 4.1), and registers the reason tokens budget-unparseable, budget-expired, price-exceeds-budget, settlement-unsupported, owner-authorization-required, and owner-authorization-invalid for status 462.¶

13.3. AGTP-LOG Event Type

This document registers commerce-transaction-committed in the AGTP-LOG event-type registry of [AGTP-LOG] (Section 7.2).¶

13.4. Media Type Registration

This document requests registration of the following media type:¶

• Name: agtp-pricing+json¶

• Type name: application¶

• Subtype name: agtp-pricing+json¶

• Required parameters: none¶

• Optional parameters: none¶

• Encoding considerations: 8bit; JSON content is UTF-8 encoded¶

• Security considerations: See Security Considerations of this document¶

• Published specification: This document¶

• Person and email address to contact: Chris Hood chris@nomotic.ai¶

• Intended usage: COMMON¶

• Author: Chris Hood¶

• Change controller: IETF¶

13.5. Authority-Scope Values

Registration of new Authority-Scope values:¶

13.6. Status Code

Registration of a new status code in the AGTP status code registry:¶

Earlier drafts of this document used 458 for this condition; 458 is Counterparty Unverified in [AGTP] and [AGTP-MERCHANT-IDENTITY], and 462 is the value [AGTP] assigns here.¶

14.1. Path to Payment Provider Integration

A payment provider considering AGTP-Commerce integration follows roughly this path:¶

1. Define a settlement endpoint identifier scheme for accounts on the provider's platform.¶

2. Implement consumption of AGTP-LOG Transaction Records as settlement-triggering input.¶

3. Map Transaction Records to the provider's internal settlement workflows.¶

4. Provide agent operators with an onboarding flow that registers accounts and issues settlement endpoint identifiers.¶

5. Define dispute integration with AGTP-LOG evidence consumption.¶

6. Operate within existing regulatory framework.¶

The integration is simple because AGTP-Commerce requires no change to the payment provider's underlying operations. Only the integration surface (Transaction Record consumption, settlement endpoint issuance) is new.¶

14.2. Path to Agent Operator Adoption

An agent operator considering AGTP-Commerce deployment follows roughly this path:¶

1. Establish a payment provider relationship and obtain a settlement endpoint identifier.¶

2. Define pricing tiers appropriate to the agent's capabilities.¶

3. Publish a Pricing Manifest at the agent's substrate-native path.¶

4. Configure the agent's TRANSACT handling for incoming commerce requests.¶

5. Configure trust threshold evaluation for callers.¶

6. Configure dispute response handling.¶

The operator's banking, tax, and compliance relationships remain with their payment provider. AGTP-Commerce provides the protocol-level integration with the agent ecosystem.¶

16.1. Normative References

[AGTP]

Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-10, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-independent-agtp-10>.

[AGTP-CERT]

Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-04, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-agent-cert-04>.

[AGTP-IDDOC]

Hood, C., "AGTP Agent Identity Document", Work in Progress, Internet-Draft, draft-hood-agtp-identity-document-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identity-document-00>.

[AGTP-IDENTIFIERS]

Hood, C., "AGTP Identifier Stack and Attribution-Record", Work in Progress, Internet-Draft, draft-hood-agtp-identifiers-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identifiers-03>.

[AGTP-LOG]

Hood, C., "AGTP Transparency Log Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-log-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-log-03>.

[AGTP-TRUST]

Hood, C., "AGTP Trust and Verification Specification", Work in Progress, Internet-Draft, draft-hood-agtp-trust-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-trust-03>.

[ISO4217]

"Currency codes -- ISO 4217", n.d., <https://www.iso.org/iso-4217-currency-codes.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

16.2. Informative References

[AGTP-COMPOSITION]

Hood, C., "AGTP Composition Profiles", Work in Progress, Internet-Draft, draft-hood-agtp-composition-02, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-composition-02>.

[AGTP-DISCOVERY]

Hood, C., "AGTP Discovery and Naming", Work in Progress, Internet-Draft, draft-hood-agtp-discovery-02, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-discovery-02>.

[AGTP-LEI]

Hood, C., "AGTP Binding to the Legal Entity Identifier (LEI and vLEI)", Work in Progress, Internet-Draft, draft-hood-agtp-lei-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-lei-01>.

[AGTP-MERCHANT-IDENTITY]

Hood, C., "AGTP Merchant Identity", Work in Progress, Internet-Draft, draft-hood-agtp-merchant-identity-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-merchant-identity-03>.

[AGTP-PRESENCE]

Hood, C., "AGTP Presence: Ambient Discovery and Visibility for Agents", Work in Progress, Internet-Draft, draft-hood-agtp-presence-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-presence-01>.

[ISO20022]

"Financial services -- Universal financial industry message scheme", n.d., <https://www.iso20022.org>.