A checkout that only offers what will actually work
Every failed checkout loses a customer who had already said yes. Instead of listing eight logos and hoping, the page works out which rails can complete this payment, for this payer, at this minute — and shows only those.
Every failed checkout has the same shape. The customer has decided to buy. They have reached for their phone. And then the page offers them eight ways to pay, of which two will actually work, and they find that out one failure at a time.
That is the most expensive place in the whole funnel to lose somebody, because it is the one place where they had already said yes.
Lists are optimistic. Routing is not.
Most checkouts show a fixed list of logos. The list is a statement of what the business has signed up for, not what will work for the person standing there.
BitriPay's checkout asks a different question: for this payment, this currency, this payer, at this minute — what can actually complete? It answers from the corridor the payment belongs to, the currency, and the live health of every connector, and it shows only what survives that test.
A connector whose circuit breaker has opened is not on the page. Not greyed out — absent. The customer is routed around a failing rail instead of into it, and never learns that it was failing.
It refuses rather than pretends
This matters more than it sounds. Under the aggregator perimeter the checkout offers the switch rail alone and refuses everything else outright, because the platform may not operate the rest until the corresponding authorisation exists.
A checkout that offered those options anyway would be making a promise the platform is not allowed to keep. Ours would rather show one working option than four hopeful ones.
What the customer sees
Your business name, your reference, and your line items with VAT where you use them — so they are looking at what they are buying, not at a bare amount they have to take on trust.
When they have paid, they go back to your own success page, and you get a signed webhook carrying the reference you set. Your order is marked paid by software.
You do not have to use the page
The same payment intent can be a hosted page, a QR payload, an embedded panel driven by a publishable key, or raw API calls into a screen you built yourself. The routing is the same in every case; only the surface changes.
What it costs
The hosted checkout" data-autolink="1">hosted checkout is part of the merchant gateway. There is no charge for the page. You pay the rate for whichever rail carried the payment, and your dashboard shows that rate before the sale rather than after it.
What you can check
These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.
- The rails offered are computed per payment, from the corridor, the currency, the payer and the live health of each connector.
- A rail whose circuit breaker is open is not offered, so a customer is never sent down a path that is currently failing.
- Under the aggregator perimeter the checkout offers the switch rail alone and refuses the rest, rather than showing options the platform may not operate.
- The session carries line items with VAT where the merchant uses them, so the customer sees what they are being charged for.
What it costs
The hosted checkout is part of the merchant gateway; there is no separate charge for it. You pay the rate for the rail that carries the payment, shown in the dashboard.
Is it switched on?
Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Hosted checkout on the features page.
Read next
- BitriQR payments — One code on the wall. Every payer it can reach.
- Payment links — Get paid by sending a message.
- The gateway API — Three calls and a webhook.
Frequently asked questions
Can I put my own branding on it?
The page carries your business name, your reference and your line items, and returns the customer to your own success and cancel URLs.
What happens if a rail goes down mid-sale?
A connector whose circuit breaker has opened stops being offered, so new customers are routed around it rather than into it. A payment already in flight follows its own state machine and is never marked paid without confirmation.
Do I have to use the hosted page?
No. The same intent can be rendered as a QR payload, embedded with a publishable key, or driven entirely from the API if you want to build the screen yourself.
Send with a QR code, add money by card or mobile money, issue a virtual card. Sandbox balances let you explore before any real money moves.
Keep reading
Une page de paiement qui ne propose que ce qui va réellement fonctionner
Chaque paiement abandonné fait perdre un client qui avait déjà dit oui. Au lieu d’aligner huit logos en espérant, la page détermine quels rails peuvent conclure ce paiement, pour ce payeur, à cette minute — et n’affiche que ceux-là.
Your till is the phone in your pocket
A till does three jobs: add up the parts, get the tax right, produce a receipt both sides accept. None of them need hardware. Line items, VAT per line, a total nobody types, and staff logins that do not hand over the business.
The polite way to be paid back
Asking someone you know for money costs more than the money. A request that waits in their app, that they approve with a fingerprint and that can never take anything by itself, changes the arithmetic.