Checkout flow

1. 1 The customer opens a payment link (picks a coin and, for one on several networks, the network, and can enter one of your coupon codes when one could apply to the link, unless the link's URL already applied one) or a charge's checkout_url. A payment started from a payment link or an invoice records the IP address and browser it came from under the charge's customer, for you to check before you ship.
2. 2 The page shows the exact amount, the deposit address, a QR code that opens their wallet, and a countdown for the 30-minute rate lock.
3. 3 The page polls for the payment: it shows "Payment detected" with the confirmations counting up, while your webhook endpoints receive charge.payment_detected, then flips to "Payment received" on its own. If a success_url is set, the customer gets a button back to your site.
4. 4 Your webhook endpoints receive charge.paid, the customer receives a receipt if they left an email, and the charge shows as paid in the dashboard and the API.

How the page looks

The page carries your display name, your logo and your brand colour, and follows the light or dark setting of the customer's device unless you fix it to one. A second logo for dark backgrounds is optional: without one, your logo sits on a white tile in dark mode. You also choose the order coins are listed in, with Litecoin already selected unless you move another coin to the top, and default return addresses and a message for charges and payment links that set none. On Pro you can hide Powered by VeliraPay. Your public profile can also link your terms of sale and refund policy, and a payment link can have a product image. All of this is in your organization's settings and your payment links in the dashboard, and none of it changes what the API returns. The receipt and the invoice document stay white whatever the setting, because they are meant to be printed and filed.

Before and while paying

Before continuing, the customer sees about how much they will send in the coin they picked and how long it usually takes to confirm. The page remembers the coin their browser last paid with, and the browser tab shows where the payment stands. The checkout comes in English, French, German, Spanish, Turkish, Portuguese, Russian and Arabic, following the browser unless you set a language for your account.

A customer with a browser wallet such as MetaMask or Phantom can pay ETH, BNB, USDT, USDC or SOL in one click: the wallet is moved to the right network and asked to send the exact amount, and the customer confirms it there. WalletConnect does the same for a wallet on their phone or another device.

Switching coin

Until something has been sent, a customer paying through a payment link or an invoice can go back and pick another coin. The charge they leave is canceled, with a charge.canceled webhook, and a new one is created, with charge.created, so one purchase can leave more than one charge behind.

A payment request emailed from the dashboard that expired before anything was sent can be quoted again by the customer from its page: they get a new charge at the current rate, with an id of its own.

When the payment falls short

If what arrives falls short of your underpayment tolerance, the page asks for the rest and the customer is emailed when their email is known. They can send it until the rate lock ends; after that the charge stays underpaid until you accept it in the dashboard.

A transfer of no more than a few cents is not counted at all, which on Bitcoin means under 0.000006 BTC. Look-alike addresses send specks like this to whatever was just paid, hoping to be copied from its history, and each one would otherwise reach you as a late payment.

Limits

So that a script cannot pile up deposit addresses, one network (an IPv4 address, or an IPv6 /64) may try 10 times a minute to start a payment and may start 20 payments every 30 minutes, switching coins included, while one IPv6 /56 may start 200 and one IPv6 /48 1000 every 30 minutes; past any of these the customer is asked to wait and try again. Checkout never stops taking payments for your account as a whole, and the payments started there do not count towards the cap on charges you create through the API, MCP or the dashboard. So that coupon codes cannot be guessed, one network may try 10 wrong codes every 10 minutes; after that, codes are refused until the window passes.