X Pay

The Payment Layer for the Autonomous Economy

Version 0.4 · 11 October 2026.

Abstract#

Software increasingly acts on behalf of people and businesses. AI agents buy data, call models and allocate compute. Robots and connected devices add physical services to that exchange: completing deliveries, charging batteries and accessing infrastructure. Each needs a way to pay within an operator's authority and budget.

X-Pay brings payment operations and programmable payments into one platform. Its public API catalogue documents pay-per-request utility and AI endpoints using USDC on Base. The merchant application provides the operational workspace for integrations. The X-Pay facilitator verifies payment authorizations and provides settlement services for supported USDC payments on Base and BNB Smart Chain. x402 connects a resource request to machine-readable payment requirements and an authorized payment.

This paper describes the protocol, payment architecture, spending controls and the path from software agents to autonomous machines. Verification, settlement and operator authority are distinct responsibilities throughout the design.

1. Introduction#

Two shifts are converging.

The first is economic. Software is moving from things people operate to things people delegate to. An agent that plans a trip, reconciles a ledger or researches a market does not make one large purchase. It makes thousands of small ones: a geocoding lookup, a currency conversion, a document parse, a model call. Each is worth a fraction of a cent. Aggregated across a fleet of agents running continuously, they are worth a great deal.

The second is technical. Stablecoins and programmable payment authorizations make small machine payments practical in more settings. Whether an individual request is economical depends on the network, facilitator, asset and payment size.

What has been missing is the connective tissue: a way for a machine to discover a price, agree to it and pay it without a human in the loop, using infrastructure the machine already speaks. That infrastructure is HTTP.

X-Pay connects this payment flow to the tools businesses need to integrate and operate it. Robotics is a near-term extension of the same infrastructure: a machine can pay for a digital resource before it can pay a physical charging station. The latter also requires the station operator to expose a compatible payment interface.

2. The problem#

2.1 The monetization stack is built for humans#

To sell an API today, a developer assembles a stack that has almost nothing to do with the API itself:

• user registration, email verification and account recovery
• card processing, with its PCI scope, chargebacks and fraud review
• subscription tiers that either under serve or over serve nearly every customer
• API key issuance, rotation and revocation
• usage metering, quota enforcement and invoice generation
• dunning, refunds and reconciliation

Each layer adds integration, maintenance and security work before a developer can operate a paid resource.

2.2 It excludes the fastest growing class of buyer#

Many conventional flows expect human interaction. An agent acts under an operator's authority, with credentials and purchase permissions that must be deliberately provisioned. Common approaches have tradeoffs:

• A human pre provisions an API key. This binds spend to a static secret with no per call ceiling. Without appropriate limits, a leaked or misused key can expose the account to uncontrolled spending.
• A human prepays a balance. This works, but only inside one vendor. It does not compose across the open web, and it cannot pay a service the agent discovers at runtime.
• The agent uses delegated card access. This can work with appropriate controls, but a general-purpose credential must not imply unrestricted spending authority.

2.3 Small payments need a different cost structure#

Per-transaction processing costs can exceed the value of a small API call. Metered billing and prepaid balances address that problem by aggregating usage, but they usually require a relationship with each provider before an agent can make a purchase.

x402 offers another model: a service publishes payment requirements with the request, and a compatible client can pay under a preconfigured policy. The economics still depend on the payment rail and facilitator. Network fees, platform fees, settlement failures and refund handling belong in the integration's cost model.

3. Background: HTTP 402 and the x402 standard#

RFC 9110 reserves 402 Payment Required for future use. x402 defines payment requirements and payment payloads that can be carried over HTTP.

The x402 standard fills that gap. In outline:

1. A client requests a protected resource with no payment attached.
2. The server responds 402 Payment Required together with a machine readable quote describing what payment would satisfy the request: scheme, amount, asset, network and recipient.
3. The client constructs a payment authorization, signs it, and retries the request with the authorization attached in a header.
4. The server follows the selected scheme to verify, execute and settle, then returns the resource and payment result. The ordering depends on the supported payment flow.

The design has three properties that matter:

• It is in band. No redirect, no hosted checkout page, no callback. The payment lives in the same request and response cycle as the resource.
• It is machine readable. The quote is structured data, not a pricing page. Software can parse it, compare it against a budget and act.
• It can remove separate payment onboarding. A compatible endpoint can accept a payment without a provider subscription. Authentication, terms and other access controls remain a service-specific decision.

x402 defines the handshake. It does not, on its own, give a merchant a gateway, a dashboard, a wallet with spending controls, payouts or a place to be discovered. That is the gap X Pay fills.

4. Design principles#

Connect payment to the resource request. The client should discover and satisfy payment requirements through a machine-readable exchange, without an interactive checkout for each purchase.

Make settlement policy explicit. Response latency, finality and credit exposure are different concerns. A deployment must state when it releases a resource and how it handles pending or failed settlement.

Bound the blast radius before signing. For an autonomous spender, controls that run after a signature exists are decoration. Every limit is enforced while refusal is still free.

Use a predictable unit of account. Stablecoin-denominated requirements simplify budgeting, while still carrying issuer and market risk. A proposed ecosystem token must not be a prerequisite for an API payment.

Be honest about what is not built. A payment system earns trust by being precise about its failure modes, not by omitting them.

5. The protocol#

5.1 Version 2 objects#

The official v2 specification defines three core objects. Use maintained libraries to encode and validate them; abbreviated addresses below explain their structure and are not executable integration values.

PaymentRequired. A resource server offers one or more acceptable payment methods. In HTTP transport, the JSON is base64-encoded in the PAYMENT-REQUIRED response header.

{
  "x402Version": 2,
  "resource": {
    "url": "https://api.example.com/resource",
    "mimeType": "application/json"
  },
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "2000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x...recipient",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

amount is an integer string in the asset's smallest unit. 2000 units of a six-decimal token is 0.002 tokens. eip155:8453 identifies Base mainnet. The token contract and signing domain must match the actual network and asset; do not derive them from a display symbol alone.

PaymentPayload. The client returns the selected requirement in accepted, plus scheme-specific payment data. For an EIP-3009 authorization, the nested structure is:

{
  "x402Version": 2,
  "accepted": {
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "2000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0x...recipient",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  },
  "payload": {
    "signature": "0x...signature",
    "authorization": {
      "from": "0x...payer",
      "to": "0x...recipient",
      "value": "2000",
      "validAfter": "0",
      "validBefore": "...expiry timestamp",
      "nonce": "0x...32-byte random value"
    }
  }
}

The base64-encoded payload travels in PAYMENT-SIGNATURE. A nonce belongs to the authorization; the v2 payment requirements do not mandate a server-issued quote nonce. The client must match the method offered by the server, including relevant extensions.

SettlementResponse. The payment result is returned in PAYMENT-RESPONSE. A successful settlement response includes success, transaction and network; it may also include the payer and other scheme-specific details.

{
  "success": true,
  "transaction": "0x...transaction hash",
  "network": "eip155:8453",
  "payer": "0x...payer"
}

A verified authorization is not a successful settlement response. Keep the network, transaction identifier, request identifier and application outcome together for reconciliation.

5.2 The HTTP exchange#

GET /resource HTTP/1.1
Host: api.example.com

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 PaymentRequired JSON>

GET /resource HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <base64 PaymentPayload JSON>

HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64 SettlementResponse JSON>
Content-Type: application/json

{"result": "..."}

The HTTP transport specification defines the wire contract. A client that already knows valid payment requirements may attach payment to its first request. An initial request followed by a paid retry is two requests, not one round trip.

5.3 EVM authorization#

EIP-3009 permits signed token transfer authorizations submitted by another party. For supported tokens, a facilitator can pay transaction gas while the payer authorizes the amount, recipient, validity window and nonce. Signing uses a network- and contract-specific domain.

EIP-3009 is one mechanism, not the definition of x402. Other networks and transfer methods have different payloads, verification rules and funding requirements. An EVM deployment must use the exact EVM scheme specification that matches its implementation.

For X-Pay, the current Base path uses USDC transfer authorizations, while the BNB Smart Chain path uses Permit2. These are different signing and allowance mechanisms. BNB USDC may require an initial token allowance transaction to Permit2, funded by the payer; a gas-sponsored settlement does not remove that setup requirement. Use a compatible client and the network-specific requirements rather than reusing a Base authorization on BNB.

5.4 Verification and replay control#

A resource server must compare the submitted payment against its own requirements, not trust a client-provided price. The following describes the design responsibilities, not a replacement for a scheme verifier:

1. Validate protocol version, schema, selected scheme, network and asset.
2. Match recipient and amount to the server's current requirements.
3. Validate the scheme's signature or payment proof, signing domain and validity period.
4. Apply replay and concurrent-request protection using the scheme's canonical payment identity.
5. Follow the required verification, resource execution and settlement ordering.
6. Persist the result so retries cannot purchase or deliver the same operation twice unintentionally.

For EIP-3009, replay tracking must scope an authorization to its network, token, payer and nonce. Atomic reservation is essential when multiple workers can accept the same payment. A local reservation does not lock funds onchain; settlement can still fail. Contract-wallet verification and chain state checks can require network calls, so there is no universal verification-latency guarantee.

5.5 Failure handling#

Exact status codes and error fields are part of the deployed endpoint's contract. Consult the endpoint documentation and protocol specification rather than assuming the proposed gateway exposes a particular error taxonomy.

6. Architecture#

6.1 Components#

The proposed architecture separates resource access, payment processing and merchant operations.

Gateway. Middleware, plus a hosted edge service, that sits in front of a merchant endpoint. It resolves the price for the route, issues the 402 quote, verifies inbound authorizations, enforces replay protection and releases the response.

Facilitator. The settlement service. It takes verified authorizations, submits them onchain, batches where batching is safe, tracks confirmation and produces receipts. Separating the facilitator from the gateway separates payment processing from resource logic. Response release must still follow the selected scheme and settlement policy.

Nonce and quote store. The strongly consistent component. It holds unexpired quotes and claimed nonces, and it is the only thing in the path that cannot be eventually consistent.

Wallet. The buyer side. It holds funds, evaluates quotes against policy, signs authorizations and records spend. The AI Wallet variant adds the constraints an autonomous spender needs.

Dashboard, Marketplace, SDK. Merchant control plane, discovery surface, and the client and server libraries that mean neither side implements the handshake by hand.

6.2 Payment lifecycle#

The diagram shows a proposed deferred-settlement variant. It carries credit exposure because value is delivered before settlement. It is not the default v2 HTTP success contract and must not emit a successful settlement receipt before payment succeeds. A standard deployment must implement the ordering required by its chosen scheme.

7. Verification and settlement#

7.1 Verification is not settlement#

Verification determines whether a payment authorization satisfies a scheme's requirements. Settlement moves value. Resource execution is a third operation, and its success must be reconciled with the payment outcome.

The selected payment flow determines the order of these operations. The default authorization flow verifies before execution and settles afterward; a final response must accurately report the settlement outcome. Processing time depends on the mechanism, facilitator and network.

7.2 Deferred settlement and exposure#

Releasing value before settlement completes creates credit exposure. It can be considered for a separately specified product, with explicit merchant terms and bounded limits, but must not be represented as settled payment.

Cryptographic authorizations do not use card-network chargebacks, but that does not eliminate refunds, fraud, legal disputes, issuer controls or chain risk. Allocation of settlement losses is agreed in the merchant integration terms.

8. Products#

8.1 Merchant application#

The merchant application is the entry point for payment operations and integration setup. Projects, API keys, webhooks, transaction history and wallet settings connect integration work to ongoing operations. The application's documentation specifies supported rails and integration requirements.

8.2 Published API catalogue#

The public X-Pay API catalogue and OpenAPI definition document pay-per-request APIs using USDC on Base. The published groups include:

Read the current schema for methods, required parameters and response formats. Payment requirements returned by the resource govern a particular request.

8.3 Integration libraries#

The merchant SDK is published as @xpay-llc/sdk. Consult its current package and merchant documentation for supported exports, authentication and version compatibility.

The separate x402 reference implementation maintains the protocol libraries. Protocol client/server packages and the X-Pay merchant SDK serve different integration needs; they should not be treated as interchangeable.

8.4 Gateway and usage billing#

A payment gateway connects route pricing, authorization handling, usage records and reconciliation. Metered billing can price a request, model usage or a unit of compute. Supported meters, billing schedules and rail combinations belong in the merchant integration contract rather than being assumed from the x402 protocol.

8.5 Autonomous wallets#

The proposed wallet design combines spending limits, destination policy and auditable payment history. Section 10 defines the control requirements for implementation.

8.6 Robotics and machine payments#

Robots, drones, autonomous vehicles and connected devices can participate in the same payment flow. An operator can assign a machine a wallet or delegated spending authority, with policies that define what it may purchase and how much it may spend.

A delivery robot could receive payment for a task, pay for an AI navigation API, purchase charging and continue to the next job. API purchases can use existing digital interfaces; charging and machine-to-machine services require compatible infrastructure and a reliable way to establish that the physical service was delivered.

The near-term path is integration with individual operators and service providers. It does not require every machine to become autonomous at once. On-chain transactions can record settlement, while device identity, task completion and sensitive operational data need their own verification and privacy design.

8.7 X-Pay facilitator#

The X-Pay facilitator provides payment verification and onchain settlement for resource servers. The merchant defines its price and payment requirements, receives the client’s signed payload, and calls the appropriate facilitator endpoints. The merchant remains responsible for resource delivery, entitlement, idempotency and reconciliation.

Networks and payment methods#

The following methods were advertised by the deployed service on 11 October 2026. Network support does not imply support for every token on that network.

Base USDC uses contract 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. BNB USDC uses contract 0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d. The BNB asset has its own backing and bridge dependencies; sharing the USDC symbol does not make the assets or authorization formats interchangeable.

Read Base supported methods and BNB supported methods before integrating. They identify current versions, schemes and asset metadata. Amounts must use the asset’s actual decimals: 0.002 USDC is 2000 atomic units on Base and 2000000000000000 on the current BNB asset.

Native BNB and USDT payments are not advertised by these endpoints and must not be assumed available. Additional assets and networks require explicit implementation and validation before being listed as supported.

Verification and settlement endpoints#

Verification and settlement requests contain paymentPayload and paymentRequirements. Authenticate server-side requests with Authorization: Bearer <facilitator API key>. The resource server supplies requirements derived from its own pricing and recipient configuration. A valid verification result does not mean funds have settled; check the settlement result, transaction and network before reporting payment success.

Supported methods and health can be inspected without initiating a payment:

curl https://facilitator-xpay.llc/supported
curl https://facilitator-xpay.llc/bsc/supported

A healthy endpoint reports service availability. It does not guarantee a particular payment will settle, sufficient relayer funding, chain finality or an uptime commitment.

Dashboard access and API keys#

1. Sign in or create an account in the X-Pay dashboard.
2. Verify the account’s email and select the relevant project. Workspace owners and administrators can manage facilitator access.
3. Open Facilitator access, name the server key, and enter a public EVM receiving address. No wallet private key or seed phrase is required.
4. Generate the key and copy it when first displayed. The full key is shown once; the service stores a hash for authentication.
5. Store the key in the application server’s secret settings. Review key status in the dashboard and revoke keys that are no longer needed.

A project can hold up to five active facilitator keys. Rotation means creating a replacement, updating the server, and revoking the old key. The receiving address is fixed for that project after registration; integrations must still validate the actual payTo requirement and signed recipient. Key registration does not replace the resource server’s payment checks.

Facilitator keys are separate from merchant dashboard API keys and paid utility API payments. A facilitator key grants access to the settlement service; it is not a payer signature, does not fund a wallet, and does not authorize spending by itself. Self-service access replaces a manual email request for normal onboarding. Disabled access, project limits and exceptional changes still require support.

8.8 Current capabilities and product direction#

Support for Base and BNB is not a claim of cross-chain payment routing. A payment uses the selected network, asset and method. Production integrations should validate both successful and failed settlement paths, use bounded retries, and reconcile resource delivery with the recorded transaction.

9. Security model#

The architecture requires the following controls, validated against the selected implementation.

Replay protection. Track scheme-specific payment identities and prevent concurrent reuse. For EIP-3009 this includes the authorization nonce. See section 5.4.

Quote expiry. Quotes are short lived, which bounds the window in which a payer balance can change between quote and settlement.

Scope binding. An EIP-3009 authorization binds amount, asset, network, recipient and nonce. It does not itself sign a URL or request body. The application must separately bind entitlement and idempotency to the intended operation.

Domain separation. EIP-712 typed data includes the chain id and the token contract address in the signing domain. A signature produced for one chain or one asset cannot be replayed on another.

Key handling. Session keys are scoped and expiring by construction. They are the only credential an agent process should ever hold, and compromise is bounded by the limits attached to the key rather than by the balance of the underlying wallet.

Custody. Merchant balances and payout paths are the highest value target in the system. The intended posture is that X Pay minimizes the period it holds merchant funds, and that the settlement path is independently reviewed before it carries meaningful volume.

9.1 Threat model#

Independent security review should cover the deployed gateway, wallet controls and settlement path. Review scope and findings belong in the deployment's security documentation.

9.2 Facilitator credentials and operations#

Keep facilitator API keys on the server, outside source control, browser bundles, URLs and logs. Dashboard authorization is checked against the signed-in user, verified email, project membership and workspace role. A separate server credential protects provisioning between the dashboard and facilitator; it is not distributed to merchants.

Key revocation stops future authenticated use of that key. It does not cancel an already submitted transaction or invalidate an independently signed payer authorization. Payment cancellation and replay handling follow the selected scheme.

Operators should monitor service health, RPC failures, relayer gas, pending transactions and reconciliation exceptions. A refund or recovery process must identify the original request, asset, network, transaction and recipient, and prevent duplicate disbursement. Monitoring targets, escalation ownership and recovery commitments must be agreed for a production integration.

10. Agent safety#

Delegated spending requires controls enforced by the wallet, signer and network implementation.

An autonomous spender is a new category of risk. A bug, a prompt injection or an unbounded retry loop can turn a well behaved agent into one that drains a balance in seconds. The wallet is where this is contained.

Per call ceiling. A hard maximum for any single payment. Quotes above it are refused without being signed.

Daily and rolling ceilings. A budget across a time window, enforced locally before signing.

Session keys. Scoped, expiring keys that an agent process holds instead of the wallet's main key. The revocation mechanism and propagation time must be documented; already released authorizations may remain usable.

Destination policy. An optional allowlist or denylist, so an agent can only pay endpoints its operator has sanctioned.

Auto pay thresholds. Below a configured amount the wallet pays without asking. Above it, the payment requires explicit approval. This is the dial between autonomy and control.

Complete history. Every quote seen, every authorization signed and every receipt received, queryable. An agent's spending must be auditable after the fact, not merely limited in advance.

11. Token#

The proposed token model connects network participation to utility, staking and governance. Implementation depends on product, security and legal review.

The network settles in stablecoins. The token does not sit between a buyer and a seller, and no user is required to hold it to transact. Its role is to align the parties who route, secure and grow the network.

Fee discounts. Protocol fees settled in $XPAY are charged at a reduced rate, with the largest benefit accruing to the highest volume merchants.

Governance. Fee parameters, supported networks, treasury allocation and protocol upgrades.

Staking. The proposed model would link facilitator capacity to stake and distribute a share of fees to participants securing that capacity. Penalties, custody, participation rules and implementation remain subject to review; the current hosted facilitator is not described as a deployed staking network.

Ecosystem rewards. Merchant incentives, integration grants and volume rebates, denominated in a way that pays for real usage rather than speculation.

11.1 Supply and distribution#

Supply, allocation, vesting schedules and emissions require product and legal approval. The design should align distribution with long-term network participation.

Allocation and emissions should support measurable network usage and sustained participation.

12. Business model#

The proposed transaction model uses a 1% fee on settled volume, with no monthly minimum or setup fee. Commercial terms are agreed per integration, including rail-specific and third-party costs.

Potential additional revenue lines:

• Premium merchant plans. Higher limits, priority settlement, advanced analytics and service levels.
• Marketplace commission. A share of volume on endpoints discovered and sold through the catalogue.
• Enterprise integration. Bespoke deployment, compliance support and dedicated infrastructure.
• White label gateway. The full stack running under a partner brand.
• Cross chain routing. A routing fee when a payment settles across networks or assets.

The intended model aligns platform revenue with merchant activity; the final fee schedule must define exceptions and third-party costs explicitly.

12.1 Commercial and service terms#

The proposed 1% model is not a confirmed price for every deployed service. A production agreement should specify platform fees, network gas, allowance setup costs, minimum charges, refund treatment, rate limits and any service-level commitment. These costs and guarantees must not be inferred from the protocol or a healthy endpoint.

An independent security audit report, fixed uptime target, incident-response commitment and final token distribution schedule are not established in this paper. They should be published or agreed separately when available. Proposed fee discounts, staking rewards and cross-chain routing are not presented as current operating capabilities.

13. Alternatives#

These approaches can coexist. The relevant choice depends on buyer behavior, transaction size, supported rails and the operator's risk policy.

14. Roadmap#

Development priorities follow integration needs, security requirements and demand from operators.

Integration and operations. Maintain the published API catalogue, merchant integration documentation, payment records and reconciliation paths. Validate supported client, server and facilitator versions together.

14.1 WooCommerce and Shopify#

X-Pay plans to extend its payment infrastructure to online stores through WooCommerce and Shopify integrations. The aim is to make X-Pay easier for merchants to connect to their existing commerce workflows, with payment status linked to the corresponding order and visible in merchant operations.

WooCommerce integration. Develop an integration for WooCommerce stores, with merchant setup, payment configuration and order-status reconciliation. Development will include testing successful, pending and failed payments, together with cancellation and refund handling.

Shopify integration and app launch. Build a Shopify integration and launch an X-Pay Shopify app. The planned app will help merchants connect their stores to X-Pay and manage the supported payment workflows. Its final capabilities and distribution will depend on implementation, testing and applicable Shopify platform requirements and review.

These integrations and the Shopify app are future plans. Launch dates, supported assets and networks, fees and final feature sets will be announced separately when confirmed.

14.2 Further development#

Delegated spending. Extend policy-based wallet access, limits, authorization lifecycle management and operational monitoring. Test recovery and revocation as carefully as successful payments.

Machine services. Work toward integrations where robots and connected devices purchase APIs, compute, charging or other infrastructure and receive payments for completed tasks. Physical service verification and operator responsibility are prerequisites.

Network expansion. Evaluate additional settlement networks, partner facilitators, enterprise deployments and discovery mechanisms against actual demand and security requirements.

Token and governance research. Any token issuance, staking or governance design remains subject to product, legal and security review.

15. Risks and open problems#

The proposed architecture has unresolved technical, operational and commercial dependencies.

Standard risk. x402 is young. If the ecosystem converges on a different shape, or fragments across incompatible variants, integration cost rises for everyone. X Pay's answer is to implement the standard faithfully, pin a protocol version, and keep the gateway able to speak more than one dialect.

Regulatory risk. Payment facilitation, custody and token distribution may trigger different legal obligations depending on the activity and jurisdiction. This is a gating dependency on launch sequencing, not a detail to resolve later.

Settlement risk. An authorization can fail to settle. Deferred delivery policies can create merchant credit exposure; Section 7.2 describes the tradeoffs. Controls reduce exposure without eliminating it.

Security risk. Independent review of a specific gateway and settlement deployment must be established separately.

Consistency risk. The nonce store is a single strongly consistent dependency on the hot path. It is also the obvious scaling bottleneck and the obvious availability risk, within this proposed architecture.

Chain dependency. Latency, cost and reliability are inherited from the settlement network. Multichain support is a mitigation and also an increase in surface area.

Adoption risk. A marketplace is a two sided market. Merchants list where buyers are, and buyers arrive where listings are. The plausible wedge is agent frameworks, where the pain of the current model is sharpest.

Agent risk. Spending controls reduce the blast radius of a misbehaving agent. They do not eliminate it, and the failure modes of autonomous spenders are not yet well understood by anyone.

16. Glossary#

Atomic units. An integer amount in the token's smallest denomination. 2000 at six decimals is $0.002.

Authorization. A signed message committing a payer to a specific transfer. Not a transaction.

EIP-712. The Ethereum standard for signing structured data, so a signature is human inspectable and domain separated.

EIP-3009. The token standard that allows a signed transfer to be submitted and paid for by a third party.

Facilitator. The service that submits verified authorizations onchain and reports settlement.

Nonce. A single use value binding an authorization to one specific payment.

Quote. The server issued description of what payment satisfies a request.

Receipt. The record of settlement returned with a paid response.

Scheme. The payment method identifier inside x402. exact means the payer authorizes precisely the quoted amount.

Session key. A scoped, expiring key an agent uses instead of the wallet's main key.

17. Conclusion#

The autonomous economy needs payment infrastructure that software can use under clear authority. x402 provides a common language for resource payments. X-Pay connects that direction to merchant operations, API integrations and stablecoin settlement.

The next step extends beyond software agents. Robots and connected devices can use the same payment principles, with additional requirements for identity, physical service verification and operational control. AI is the brain. Robotics is the body. X-Pay is the payment layer.

References#

• X-Pay API catalogue and OpenAPI definition.
• X-Pay facilitator documentation, Base supported methods, BNB supported methods and dashboard facilitator access.
• X-Pay merchant application and merchant SDK package.
• x402 v2 core specification, HTTP transport and EVM exact scheme.
• EIP-3009 transfer authorization.
• RFC 9110: HTTP 402.

Protocol references were reviewed on 4 October 2026. Facilitator capabilities and dashboard access were checked for this revision on 11 October 2026. Protocol and service documentation can change; pin implementation versions and use current endpoint requirements.

Legal notice#

This document describes X-Pay's technology and product direction. It is not an offer to sell, or a solicitation of an offer to buy, any token, security or financial instrument, and it is not investment, financial, legal or tax advice.

Statements about future products, timelines, token mechanics and network behaviour are forward looking and subject to change without notice. Nothing here is a commitment to deliver any feature on any date.

No representation is made that the systems described have been audited, formally verified or hardened for production use. Digital assets carry risk, including total loss of value.

Truncated addresses, signatures and identifiers in protocol examples are illustrative. Full asset contracts in section 8.7 identify the methods advertised at the revision date; confirm current metadata from the supported-methods endpoints before using them in production.

© 2026 X Pay. All rights reserved.