Paying and settlement

Paying is where OpenPayment resolves a stored definition into a real wallet action. By the time the payer reaches checkout, the payment rules are already fixed and the UI only needs to guide settlement.

How a payer enters checkout

There are two entry points:

• a shareable OpenPayment URL
• the Pay page with a paymentId

Both resolve the same payment definition. The payment link is simply the most convenient public wrapper around that identifier.

What checkout already knows

When a valid payment loads, OpenPayment already knows:

• recipient wallet
• network
• token context
• payment type
• fixed or editable amount behavior
• optional description

This removes the most common sources of payment error found in manual wallet transfers.

The checkout sequence

At a high level, checkout does the following:

1. load the payment definition
2. render the payment summary
3. connect a wallet if required
4. switch to the correct network if required
5. collect a final amount if the type is VARIABLE
6. collect optional proxy query parameters if the type is PROXY
7. execute settlement
8. return a receipt and, for PROXY, a protected response

Type-specific settlement behavior

SINGLE_USE at checkout

For SINGLE_USE, the payer sees a fixed amount and a one-time payment flow.

If the link has already been paid successfully, OpenPayment does not allow a second payment. Instead, checkout makes it clear that the request has already been completed.

This is why SINGLE_USE is the safest choice for invoices and order-specific links.

MULTI_USE at checkout

MULTI_USE looks similar to SINGLE_USE during an individual payment, but the payment definition stays active afterward.

Each successful settlement produces its own receipt, which means one MULTI_USE definition can accumulate many independent payment events over time.

VARIABLE at checkout

For VARIABLE, checkout initializes the amount field from the configured value and then allows the payer to change it.

Use this when:

• the merchant wants to suggest an amount but not enforce it
• the payment is customer-driven rather than order-driven

Do not use it when your accounting depends on receiving an exact amount every time.

PROXY at checkout

PROXY adds one more stage after payment: protected resource access.

The payer still completes a normal wallet settlement first. After that:

1. OpenPayment verifies the payment outcome
2. OpenPayment requests the protected HTTPS resource server-side
3. the payer receives the returned JSON or text response in the success screen

If your protected resource needs context, the payer can also provide flat query parameters in the checkout UI before paying.

The most important PROXY rule

Payment success and resource success are not the same thing.

For example:

• the settlement may succeed and generate a valid receipt
• the protected resource may still return an application error

In that case:

• the receipt proves the payment happened
• the protected response tells you whether the gated business action succeeded

Teams building with PROXY should log and reason about both outcomes separately.

Network and wallet expectations

The payer needs a compatible wallet on the correct Base network. The checkout helps with both:

• if no wallet is connected, it prompts for connection
• if the wallet is on the wrong network, it prompts for a switch

This matters operationally because the payment definition is network-specific. A Mainnet payment and a Sepolia payment are not interchangeable.

What a successful payment returns

A successful checkout returns at least one critical output: a receipt.

That receipt is what you use later for:

• confirmation
• support
• reconciliation
• explorer-based verification

For PROXY, the success screen can also include a protected response payload. This is typically the application data the payer was trying to access in the first place.

What this means for product design

OpenPayment deliberately separates three concerns:

• payment configuration
• payer interaction
• post-payment verification

That separation lets you create a payment in one system, share it in another, settle it in a third context, and still verify the outcome later using the receipt.