Getting started

This getting started guide walks through the full OpenPayment lifecycle: choose the correct payment type, create the link, collect settlement, and verify the receipt.

The fastest path to a correct integration

If you want to learn OpenPayment quickly, think in this order:

1. choose the environment
2. choose the payment type
3. create the payment definition
4. distribute the payment link
5. let the payer settle in checkout
6. verify the resulting receipt

The same lifecycle applies whether the definition is created from the Web UI, CLI, SDK, or Skill.

Step 1: Choose the environment

Use Base Sepolia while testing and Base Mainnet when you are ready for live settlement.

When in doubt, start on Sepolia, validate the full flow, then switch the exact same payment design to Mainnet.

Step 2: Pick the right payment type

This is the main product decision. Everything else is implementation detail.

Two practical rules help most teams:

• default to SINGLE_USE if the payment maps to a single order or invoice
• use PROXY only when payment must immediately gate access to a server-side resource

Step 3: Create the payment definition

A payment definition always captures the same business inputs:

• recipient wallet
• network
• payment type
• amount or suggested amount
• optional human-readable description
• protected resource URL for PROXY

After creation, OpenPayment returns:

• paymentId: the persistent identifier of the payment definition
• url: the shareable checkout URL

Step 4: Share the link

The payment URL is the public entry point. You can place it in:

• an invoice email
• a checkout button
• a chat conversation
• a CRM or support workflow
• an agent response

If you created the payment in the Web UI, the result screen already gives you copy and share actions. If you created it with the CLI, SDK, or skill, you can store or forward the returned URL directly.

Step 5: Payer completes checkout

When the payer opens the link, OpenPayment loads the definition and configures checkout automatically.

The payer does not have to manually enter:

• the token contract
• the recipient address
• the intended network
• the base amount for fixed-price payments

Depending on the type:

• SINGLE_USE: the payer can complete the payment once
• MULTI_USE: the same link remains reusable after each successful payment
• VARIABLE: the payer can edit the amount before settlement
• PROXY: successful settlement returns a protected resource response

Step 6: Verify the result

A successful settlement creates a receipt. That receipt is the record you use for:

• confirming payment to a customer
• checking who paid
• checking how much was paid
• reconciling transactions
• linking the payment to a business event

Key identifiers to keep

Keep these three identifiers distinct in your system:

Where to go next

• Read Creating Payments for detailed guidance on choosing the correct type
• Read Paying and Settlement to understand payer-side behavior
• Read Receipts and Verification for post-payment operations