Payment link or checkout: which to pick
Payment link or hosted checkout: two ways to get paid online, two very different workloads. The criteria that decide — volume, amount, team, customisation.
The question comes up on every integration: should you send a payment link, or build an order funnel with a checkout session? Both get you paid. What separates them is the work you will have to do and the control you will keep over the journey.
The payment link: one call, and you are paid
You create a payment link with an amount and a description, you share it, the customer pays on a page hosted by ChariPay. You write no payment page, you host no card data, and you have nothing to get certified.
It is the right choice when payment is an isolated event rather than a step inside a funnel:
- an invoice sent by email or WhatsApp;
- a quote accepted over the phone;
- a remote sale on social media;
- an over-the-counter payment, with the QR code or the printed poster.
The link carries everything needed to track it: your own order identifier, an expiry date, and a payment status you find in the portal as well as in the API. Every setting, from the portal to the API, is described in creating a payment link.
A merchant who sells on Instagram and invoices over WhatsApp needs nothing else. Building an order funnel for that case means paying a month of development to replace a copy-paste.
The checkout session: payment inside your funnel
Here, an order from your shop becomes a session. You redirect the buyer to the hosted checkout, and they come back to your URLs — one for success, one for failure.
This is what you need when:
- payment sits inside a cart and a funnel you control;
- you must show a confirmation page of your own, with your products and your delivery;
- your order system has to change state at the exact moment of payment;
- you measure a funnel and want to know where buyers drop off.
The price is modest: two URLs to expose, and a webhook handler to write. What happens when the session expires or the buyer closes the page is described in checkout session expiry and return.
The trap common to both: trusting the redirect
This is the mistake we see most often, and it is expensive.
When the buyer lands on your success URL, it means they came back. Not that the payment succeeded. Between the two sit their bank, a 3-D Secure challenge, sometimes a delay — and a buyer who closes the tab too early, or a mobile network that drops.
The rule is simple and has no exception: the redirect is for display, the webhook is for the decision. Show a pending state on return, and only release the order when the payment event arrives. The guide to getting your webhook integration right shows how to verify and deduplicate it.
What about direct checkout?
A third door exists: build your own card form and call the direct checkout endpoints yourself. It is open, but it puts you inside the card-data compliance perimeter — with everything that implies in audits, hosting and liability.
Only take it if you have a precise reason the hosted page does not cover. In the vast majority of cases it buys you a little styling and a lot of obligations. If you take it anyway, the direct checkout guide walks through it call by call, and PCI DSS for merchants sets out the compliance perimeter.
The criteria, one by one
Volume. Ten sales a day are perfectly manageable with links: creation takes a few seconds in the portal. At a hundred sales a day, manual creation becomes a job — that is the signal for checkout, or at least for links created through the API.
Who closes the sale. A human in conversation with the customer? The link slots naturally into the exchange. A site that sells on its own, nights included? Checkout, obviously. A booking site that holds a slot at the moment of payment is the typical example: see taking payment for online bookings.
The amount. Fixed and known in advance — a course, a subscription, a single product — both work. Variable with the cart: checkout computes it; links would require one creation per sale. The case of a course sold online is covered in selling online courses.
The team available. Links require no developer. A checkout session requires a server-side integration — modest, but real: session creation, return page, webhook handling.
The need for customisation. The link shows your name and logo on a ChariPay page. The session carries your colours inside your funnel. The direct API lets you design every screen — at the price of owning the whole thing.
Migrating from one to the other
The choice is not forever, and migration is gentler than expected: both products share the same wallet, the same portal, the same webhooks and the same accounting export. Moving from links to checkout changes neither your cash position nor your reconciliation — only how the payment starts.
The usual path: start with links to validate the offer, wire checkout when volume justifies it, keep links for the cases outside the funnel — a special order, a phone follow-up, an event. The two coexist very well; that is in fact the stable state of most businesses: checkout for the flow, links for the exception.
In short
| You want to… | Take |
|---|---|
| Get an invoice, a quote or a remote sale paid | The payment link |
| Take payment inside your site's order funnel | The checkout session |
| Take a cash payment, at an agency | The payment link, cash method |
| Build your own card form | Direct checkout — and a compliance project |
In every case, begin with the sandbox: Start in test mode only asks for a name, a work email and your company name, then a password chosen from the activation link sent by email — free, with no time limit. The test key, which you create from the portal, cannot reach production, and you can replay a journey as many times as you need before you go live for real.
Written by ChariPay team.