Payment Links: When They Are Enough and When You Need a Real Checkout

A payment link is a URL that opens a hosted checkout page for a fixed amount. You create it in a dashboard, send it by message or email, and money arrives — no website, no integration, no code. For a great many small businesses that is genuinely enough, and for a while it is the right answer.

The interesting question is not how to make one, which takes about a minute. It is when the link stops being enough — because the transition from links to a real checkout is a real threshold, and crossing it too early wastes months while crossing it too late costs sales.

What a payment link actually is
The four signs you have outgrown them
What a real checkout adds
Things worth getting right either way
How this fits the rest of the stack
FAQ

What a payment link actually is

Every major processor offers a version. You specify an amount, a description and optionally what data to collect, and get a URL. The payer opens it, sees a hosted page branded roughly to your business, pays, and both of you get a receipt.

The important properties, which are what make them attractive:

Card data never touches your systems. The page belongs to the processor, which removes essentially all of your compliance burden. This is the single biggest advantage and it is not a small one.
No website required. The link works from a message, an email, an invoice, a social profile or a printed QR code.
Reusable or single-use. A fixed-price link can be shared repeatedly; a one-off link can be tied to a specific invoice.
Basic data collection. Most support asking for a shipping address, a phone number, or a custom field.

For a consultant invoicing a fixed fee, a tradesperson taking a deposit, a class taking bookings, or a maker selling three products, this is a complete solution. It is worth saying plainly because a lot of businesses build a store when a link would have done.

The four signs you have outgrown them

Each of these is a threshold rather than a preference.

Stock matters. A payment link does not know how many you have. If two people pay for the last item, both payments succeed and you have a refund and an apology to issue. Any unique or limited inventory needs a system that decrements stock at purchase.
The catalogue is more than a handful. Managing thirty links in a dashboard, keeping prices current across the places you pasted them, is worse than a catalogue. Around ten products is where this tips.
Customers need to buy more than one thing at once. Links are single-purchase. No basket, no combined shipping, no order total. If people regularly want two items, you are actively losing revenue on every one of those.
You need the order data connected to something. Fulfilment, accounting, dispatch, a CRM. Copying from a payments dashboard into a spreadsheet works until volume makes it error-prone, and mistakes here mean unshipped orders.

Notably, transaction volume alone is not a reason to move. A business taking a hundred payments a month for one fixed-price service is perfectly served by a single reusable link. It is the shape of what you sell, not the amount of money, that decides.

What a real checkout adds

Beyond the obvious basket, the things that actually matter operationally.

Inventory that decrements, so the same unique item cannot be sold twice.
Shipping calculated from the basket — by weight, destination or threshold — rather than a flat guess baked into the price.
Tax handled per jurisdiction, which stops being optional the moment you sell across a border.
Discount codes and campaigns, which are painful to run with static links.
Abandonment visibility — you can see where people stopped, which is impossible with a link.
Order records that integrate with fulfilment, accounting and support.

The cost of that is a system to run: a catalogue, a runtime, a database, and a checkout flow that must not break. That is the trade — links cost almost nothing to operate and cap what you can do; a checkout costs a monthly line and removes the ceiling.

A useful middle step that plenty of businesses miss: a simple website with product pages that each link to a payment link. You get discoverability, search presence and proper product information without a full ecommerce build. Stock and baskets still are not solved, but presentation is — and for a low-catalogue business that is often the actual bottleneck.

Things worth getting right either way

Use your own domain in the link where the processor allows it. A branded URL converts better than an obviously third-party one, and it survives you changing processor.
Say what happens next on the confirmation. When it ships, when you will be in touch, what the charge will appear as on their statement. Unrecognised statement descriptors cause chargebacks.
Check receipts actually arrive. Test to more than one email provider. Payment confirmations landing in spam generate support tickets.
Reconcile against your accounts properly. Processor payouts are batched and net of fees, so the amount arriving in the bank never matches the sum of sales. Handle that from the start rather than at year end.
Know the refund path before you need it, and make it easy to find. A visible refund policy reduces disputes, which are more expensive than refunds.

The statement descriptor point is worth emphasising: a customer who does not recognise a charge disputes it, and a dispute costs a fee on top of the reversed amount whether or not you win. Setting the descriptor to something recognisable is a two-minute task with a real return.

How this fits the rest of the stack

The step from payment links to a real checkout is the step from no infrastructure to a service and a database running continuously, so it is worth pricing before you cross it. The RunxBuild hosting calculator shows the service, the database, the storage and the bandwidth together. The middle path — product pages that link out to hosted payment links — needs only a static site, which RunxBuild builds from a repository with 120GB of bandwidth included; when the basket and stock become necessary, managed MySQL or Postgres sits alongside the service.

Useful related references:

FAQ

What is a payment link?

A URL that opens a hosted checkout page for a set amount. You create it in your processor’s dashboard and share it by message, email, invoice or QR code. Card data never touches your systems, which removes almost all of your compliance burden, and no website is required.

When should I move from payment links to a real checkout?

When stock matters and two people could pay for the last item, when the catalogue passes roughly ten products, when customers want to buy more than one thing at once, or when order data needs to connect to fulfilment or accounting. Transaction volume alone is not a reason — a hundred payments a month for one fixed-price service is fine on a single link.

Can I sell products with just payment links?

Yes, for a small catalogue of fixed-price items with no stock constraint. A useful middle step is a simple website with a page per product, each linking out to a payment link — you get discoverability and proper product information without a full store, though baskets and stock remain unsolved.

Why do customers dispute charges they made?

Usually because they do not recognise the statement descriptor. Setting it to something obviously matching your business is a two-minute task, and it matters because a dispute costs a fee on top of the reversed amount whether or not you win it.

Do payment links handle shipping and tax?

Barely. Most let you collect a shipping address and add a flat amount, but they cannot calculate by weight or destination, and cross-border tax handling is beyond them. Those are among the main reasons businesses move to a real checkout.