Web UI

The Web UI is the fastest way to use OpenPayment because it exposes the entire product lifecycle in one place: create a payment, open checkout, settle it, inspect the receipt, and review protected responses for PROXY payments.

When to use the Web UI

Use the website when you want:

• the shortest path to a working payment link
• a manual end-to-end test before automating anything
• a non-technical workflow for operations or support
• a visual way to inspect how each payment type behaves

The UI is especially useful before adopting the CLI or SDK because it makes the payment model concrete.

Create page

Open the Create Payment page when you want to define a new payment.

Fields in the create flow

UI-specific behavior

• You can populate the recipient field from the currently connected wallet.
• The network is selected from a dropdown rather than entered as a raw CAIP-2 string.
• The description field is intentionally short for readability in the hosted checkout.
• After creation, the UI shows both the paymentId and the public payment URL.
• The result screen supports copy, open, and quick sharing via WhatsApp, Telegram, and email.

Recommended first test

For a first test, create:

• type: SINGLE_USE
• amount: 1
• network: Base Sepolia
• recipient: your test wallet

This lets you verify the full flow without introducing reuse or proxy complexity.

Pay page

Open the Pay page in two ways:

• by following a shareable OpenPayment link
• by pasting a paymentId into the form

What checkout loads automatically

Once the payment is resolved, the UI displays:

• the amount or editable amount field
• token and network information
• recipient address
• description
• payment type behavior

The payer does not have to reconstruct these values manually.

Wallet behavior

During payment, the UI:

• asks the payer to connect a wallet if none is connected
• prompts the payer to switch to the payment's network if necessary
• submits settlement from the connected wallet

Type-specific checkout behavior

Proxy query parameters

For PROXY payments, the checkout UI exposes key/value rows that are forwarded to the protected resource after successful settlement.

Use them when the gated resource depends on runtime context such as:

• city=rome
• lang=en
• report=monthly

The UI validates these parameters before payment so malformed values do not break the protected request.

What success looks like in the UI

After a successful payment, the UI shows:

• success confirmation
• receipt details
• transaction hash
• payer and recipient addresses
• network and token information

For PROXY, the success screen also shows the protected response:

• returned status code
• returned JSON or text body

This is useful for debugging paid APIs and gated content flows.

Receipt page

Open the Receipt page when you want to inspect a previous successful settlement.

You only need the receiptId.

The page shows:

• settled amount
• token and network
• transaction hash
• payer address
• recipient address
• the originating payment ID
• settlement timestamp

It also links out to the block explorer so support or finance teams can cross-check the onchain transaction.

Practical UI workflow

For a complete manual test, use this sequence:

1. Create a payment on Create Payment
2. Copy the generated payment URL
3. Open it in a new tab or wallet-enabled browser
4. Complete checkout
5. Open the receipt from the success screen

If you are testing PROXY, repeat the same flow after adding one or two query parameters so you can verify the protected response path as well.

Best practices for UI users

• Test on Base Sepolia before creating live Mainnet links.
• Double-check the recipient address before generating a shareable link.
• Use SINGLE_USE by default for order-specific requests.
• Use PROXY only when your resource is meant to be read after payment.
• Keep descriptions clear and short so the payer immediately understands what they are paying for.