What is OpenPayment

OpenPayment is an x402-based payment layer that turns payment into part of the request flow: it can expose shareable payment links for humans, payment-aware HTTP access for applications, and protected resource delivery after verified settlement.

What OpenPayment solves

OpenPayment is designed for flows where payment should not live outside the request. In traditional crypto UX, an application usually asks the user to stop what they are doing, send funds manually to a wallet address, and then return with separate proof that payment happened.

OpenPayment uses x402 to invert that model. Instead of treating payment as a side quest, it makes payment part of the request/response lifecycle:

• a client attempts to access a paid action or resource
• the system can declare that payment is required
• settlement is completed in the same flow
• the request can continue only after payment is verified

At the product level, OpenPayment packages that model in a way that is easy to use for both humans and applications:

• it creates shareable payment links
• it hosts checkout for wallet-based settlement
• it records receipts for each successful payment
• it can unlock protected HTTP resources after payment

Instead of publishing a raw wallet address and an informal instruction such as "send 10 USDC," OpenPayment creates a durable payment definition that captures:

• who receives funds
• which network is used
• whether the amount is fixed or payer-defined
• whether the link can be reused
• whether payment should unlock a protected follow-up result

That definition becomes a public payment URL. The payer opens the link, completes checkout, and receives a verifiable outcome.

For simple use cases, this means better payment links. For advanced use cases, it means payment can become part of API access control, gated content delivery, and payment-aware HTTP flows.

Core model

Every OpenPayment flow is built from four objects.

1. Payment definition

A payment definition is the canonical configuration of the payment request. It is created before any money moves.

It includes:

• payment type
• recipient wallet
• network
• amount model
• optional description
• protected resource configuration for PROXY

2. Payment link

The payment link is the public URL generated from the definition. It is the artifact you share in chat, email, invoices, agents, dashboards, or apps.

The link is not the payment itself. It is a stable entry point that resolves the stored payment definition into checkout and into the underlying x402-style payment flow.

3. Checkout and settlement

When a payer opens the link, OpenPayment loads the definition and renders a wallet-based payment flow. At that point the payer can inspect the request, connect a wallet, switch to the correct network if needed, and authorize settlement.

This stage is where OpenPayment moves from configuration to execution.

In PROXY flows, this same settlement stage also decides whether the protected HTTP request may continue. That is the clearest expression of the x402 model in the product.

4. Receipt

Every successful settlement produces a receipt. The receipt is the durable record of what actually happened: payer, recipient, amount paid, token, network, and transaction hash.

This separation matters:

• the payment definition describes the intended payment behavior
• the receipt proves a specific successful settlement event

Supported network and asset

Today the product-level OpenPayment experience is focused on USDC on Base:

Across the website, CLI, SDK, and skill, the standard flow is: choose the Base network and OpenPayment handles the corresponding USDC configuration for that environment.

Payment types at a glance

The payment type is the most important design choice in OpenPayment because it changes reuse, amount behavior, and what happens after settlement.

Why x402 matters

OpenPayment is powered by x402, a protocol model for payment-aware internet flows. The important idea is that payment is not treated as a disconnected side action. It is part of the same HTTP request lifecycle that decides whether a client may continue.

In other words, OpenPayment is not only "a tool that creates crypto payment links". It is also a product that can make HTTP resources payment-aware.

That becomes especially powerful for PROXY payments:

• a payer attempts to access a protected resource
• OpenPayment requires settlement
• after successful payment, OpenPayment returns the protected response

You do not need to implement raw x402 mechanics to use OpenPayment through the website, SDK, CLI, or skill, but understanding x402 explains why OpenPayment can do more than generate static transfer links. It explains why payment can be integrated into the request itself and why access to a response can depend on verified settlement.

Interfaces

The payment model is the same across all interfaces. What changes is how the definition is created and who drives the workflow.

Settlement itself always happens through the OpenPayment checkout flow. The creation interfaces generate the definition and the shareable link.

When OpenPayment is a good fit

OpenPayment is particularly effective when you need:

• non-custodial settlement directly to a recipient wallet
• a reusable payment request instead of one-off manual transfer instructions
• a clean separation between payment setup and payment execution
• verifiable receipts for support, reconciliation, or automation
• paid access to protected JSON or text resources

Next steps

If you are new to the product, continue with:

1. Getting started
2. Creating Payments
3. Paying and Settlement
4. Receipts and Verification
5. Web UI