Splintr
← All documentation
// agent payments · comparison

Splintr vs x402

Beyond the API paywall: multi-asset checkout, invoicing, and one clean settlement for people, businesses, and agents.

x402 and Splintr solve related problems at different layers. x402 standardizes payment signaling for resources. Splintr brings routing and a commerce lifecycle to payments. Neither needs to erase the other's use case.

The important distinction

x402 is not USDC-only or inherently single-chain. Its current specification supports multiple networks and assets, and includes MCP payment signaling. Splintr's distinction is not simply “MCP instead of HTTP.” It is a set of commerce tools and cross-chain routing workflows around a payment intent.

Splintr is a separate integration, not an x402 facilitator or drop-in x402 replacement. It does not currently return x402 payment challenges, accept x402 payment proofs, or implement the x402 verification and settlement handshake.

Compare the workflows

A protocol's scope is different from what an application can build on top of it.

Core purpose

x402A standard for requesting and proving payment for a resource.

SplintrA payment platform for checkout, invoices, routing, and settlement.

Payment interface

x402HTTP 402 payment signaling; the specification also defines an MCP transport.

SplintrHosted checkout, REST API, SDKs, and authenticated MCP commerce tools.

Assets & networks

x402Extensible across assets and networks. USDC is common, not a protocol-wide restriction.

SplintrSupported tokens and chains discovered through providers, subject to execution and safety checks.

Cross-chain funding

x402A payment requirement identifies a network, asset, and scheme; routing or conversion is implementation-specific.

SplintrRoutes eligible payer balances toward the receiver's chosen settlement asset and chain.

Invoicing

x402A resource-payment standard; business invoicing can be built around it.

SplintrShareable payment links, expiry, cancellation, and tracked payment intents.

After payment

x402Application-specific fulfillment and commerce workflows sit around the standard.

SplintrSigned settlement webhooks, payment status, payouts, and refund workflows.

When x402 fits

Choose x402 when your main requirement is standardized payment-gated access to an API or resource and your client, seller, and facilitator support the relevant payment scheme.

When Splintr fits

Choose Splintr when customers hold balances across tokens and chains, sellers need invoices, or agents need tools for managing a payment lifecycle rather than only purchasing a resource.

From agent invoice to settlement

  1. The agent uses list_merchants and create_payment_intent to create an invoice for an authorized merchant.
  2. The customer opens the hosted checkout and authorizes an eligible route from their wallet. Creating an invoice over MCP does not authorize spending from a customer's wallet.
  3. The agent follows status with get_payment_intent or poll_settlement.
  4. The merchant fulfills only after verifying a payment_intent.settled webhook, not from a redirect or client callback.

Coverage depends on live liquidity, provider support, wallet signing, and safety screening. A listed network or recognized stock token does not guarantee an executable payment route. Test-mode settlement is simulated.

MCP agent guide Invoicing guide SDK quickstart

Official x402 references

Reviewed October 18, 2026. Implementations and supported schemes continue to evolve. Splintr is not affiliated with x402 or Coinbase.

Networks & token support x402 MCP transport specification