Introduction
Start here: understand what OpenPayment is, how x402 makes payment part of the request flow, and where to go next in the documentation.
This documentation is the entry point for understanding how x402-based payment-aware requests become real payment links, hosted checkout flows, receipts, and protected resource access using OpenPayment.
About OpenPayment
OpenPayment is an x402-based payment layer for USDC on Base.
At a protocol level, x402 makes payment part of the request lifecycle: an HTTP request can declare that payment is required, settlement can happen in the same flow, and access can continue only after payment is verified.
At a product level, OpenPayment turns that model into something practical:
- shareable payment links for humans
- hosted checkout for wallet-native settlement
- reusable payment definitions for products and operations
- receipts for verification and reconciliation
- protected resource access through
PROXYpayments
That is why OpenPayment is both a payment-link product and a payment-aware HTTP access model.
What you can do with it
OpenPayment is built for flows such as:
- creating one-time or reusable payment links
- collecting fixed or variable USDC payments
- embedding payment creation in apps, scripts, and agent workflows
- gating JSON or text resources behind payment
- verifying successful settlement with receipts
If you only need a shareable link, OpenPayment gives you that. If you need payment to control whether a request may continue, OpenPayment gives you that too through x402-style flows.
How the docs are organized
| Section | What you will learn |
|---|---|
| Fundamentals | What OpenPayment is, how x402 fits, and how to get oriented quickly |
| Payment flow | How to design a payment, how settlement works, and how receipts should be used |
| Interfaces | How to work with the Web UI, CLI, SDK, and skill |
Recommended reading paths
If you are new to the product, start here:
If you care about protected resources and paid access flows, continue with:
If you already know the model and just need an interface:
A simple way to think about it
OpenPayment separates four concerns cleanly:
- define the payment
- share the entry point
- settle the request
- verify the result
That separation is what makes the system usable across manual, programmatic, and agent-driven workflows.