Digital Business / Online sales / Implementation guide
Use a payment link when customers already know what they are buying and you can reliably connect the payment to delivery. Choose a connected website checkout when buyers need a cart, live availability, product choices, or an order workflow that updates automatically. A payment link still opens a checkout page. The decision is about the sales process around that page, not simply whether payment happens on your domain.
A consultant selling a defined session and a retailer selling sizes, colours, and delivery options have different needs. Start by mapping one complete sale, including the work after payment, before choosing a platform or commissioning development.
In this guide, “payment link” means a shareable route to a configured payment page. “Connected website checkout” means checkout linked to your store, booking system, or application’s order records. Either approach can use a provider-hosted payment page.
01 / Understand what each option does
A payment link packages an offer into a URL you can share on a website, in a message, or through another channel. Stripe’s Payment Links reference explains that a link can be reused, with a new checkout session created when a customer opens it. A reusable offer link is therefore different from a unique order reference.
A connected checkout receives context from the system where the buyer is shopping: selected items, quantities, availability, customer information, and an order identifier. The payment interface can still be supplied by a provider. Stripe’s Checkout documentation, for example, describes hosted and embedded payment interfaces using its Checkout Sessions API.
| Question | Payment link | Connected website checkout |
|---|---|---|
| Where does the offer begin? | A configured link or buy button | A cart, booking, or application record |
| How is the sale matched? | Provider details plus your reference or matching process | An integration should connect payment and order identifiers |
| Who manages availability? | Check the link’s controls and any connected system | The store or booking integration should enforce it |
| What needs maintenance? | Links, offer details, permissions, and post-payment handling | Those tasks plus the store and integration |
These are implementation patterns, not universal product restrictions. Some payment-link tools connect to inventory or support multiple items. Some website checkouts are poorly connected to fulfilment. Evaluate the specific product and configuration rather than relying on the label.
02 / Match the workflow to your sales
A link can fit a clearly defined offer
Hypothetical example: a designer sells a fixed-scope website review. The sales page states the deliverable, price, turnaround, and information required. After a confirmed payment, a named person matches the payment to the buyer, requests the website details, and records the delivery deadline.
A payment link may serve that process well if the team can perform those steps consistently. It should be clear whether payment buys the review immediately or follows acceptance of a proposal. If each engagement has different scope, a customer-specific invoice may fit better than a public reusable offer link.
A connected checkout fits decisions made during the purchase
Hypothetical example: a small shop sells clothing in several sizes, shares stock with a physical location, and offers different delivery services. The checkout needs to use the selected variant and current inventory, then create the correct fulfilment record.
As a concrete platform example, Shopify documents inventory checks during checkout. That is the kind of behaviour to verify in your chosen store, including how stock is reserved and released after failed payments.
A workshop with limited places is another capacity problem. Confirm that two buyers cannot both pay for the last available place. Collecting a fee and reserving a seat are separate requirements unless your chosen integration joins them.
Write down the condition that must never be wrong: stock availability, a booked time, a negotiated amount, or access to a paid service. Choose a workflow that enforces that condition, then assess convenience and appearance.
03 / Check availability and required features
Begin with the seller’s eligibility, not the customer’s location. Stripe’s supported-country list currently includes the US, UK, Canada, and Australia, among other markets. A provider accepting buyers internationally does not mean a business in every country can open the same account or use every feature.
Check your merchant country, business type, settlement requirements, currencies, and the payment methods actually available for your transaction. Do this in the relevant regional documentation and account, rather than assuming a US product page applies everywhere.
Examples illustrate why the details matter:
- Stripe Payment Links supports product and subscription pricing, but its customer-chooses-the-amount model does not support recurring payments.
- Square’s US payment-link guide describes different link types and distinguishes which can be created in its dashboard versus its point-of-sale app.
- PayPal’s Payment Links and Buy Buttons documentation describes hosted payment pages and explicitly notes regional variation in payment methods.
These are examples of capabilities, not a ranking of providers. Shortlist against your actual requirements: shipping information, quantity controls, recurring billing, cancellation handling, customer references, and exports.
Also separate payment limits from shared inventory. Stripe lets you limit how many times a link can be paid. That can be useful, but a limit on one link is not automatically a live stock connection across your other sales channels.
04 / Plan what happens after payment
The most consequential decision is often who turns a confirmed payment into a delivered order. Define a record containing the buyer, offer, amount, currency, payment identifier, delivery status, and responsible person. A confirmation email should help locate that record rather than become the only record.
Stripe’s post-payment guidance describes dashboard tracking and automation through partners or an API. It also explains that some payment methods require additional events because confirmation is delayed. Design around the provider’s confirmed payment status before releasing the purchase.
| Stage | Define before launch | Failure to check |
|---|---|---|
| Payment confirmation | The authoritative status and record | A submitted or pending payment treated as paid |
| Order matching | A dependable reference or matching procedure | Payment assigned to the wrong booking or customer |
| Delivery | Owner, deadline, and completion record | Money received but no action taken |
| Exceptions | Handling for duplicates, cancellations, and refunds | Conflicting records or repeated delivery |
For a manual process, assign a primary and backup operator and agree how often the queue is checked. For automation, ask the implementer how retries, duplicate notifications, failed delivery, and delayed payments are handled. An automated notification arriving twice should not create two shipments.
A receipt, a booking confirmation, and a shipping notification communicate different things. Write each message to describe the actual state. For a shared customer-support address, our email alias versus shared mailbox guide explains how team access and reply history affect handovers.
05 / Compare the complete operating cost
Compare the cost of taking and completing an order, not just launching the payment page. Include processing, platform subscriptions, integration maintenance, automation services, reconciliation time, and exception handling.
On its current US pricing page, Stripe lists basic Payment Links and Checkout acceptance as included with standard Payments pricing. That does not make transactions free, and optional services have separate pricing. Check the applicable regional schedule, including international payments, currency conversion, subscriptions, refunds, and disputes where relevant.
If manually matching and recording each sale takes four minutes, 30 monthly sales require two hours. At 300 sales, the same task requires 20 hours. These are invented planning assumptions, not measured results. Time your own process, including corrections, before using labour savings to justify an integration.
Use our website running-cost checklist to capture recurring commitments. Keep one-time setup work separate so a cheap launch does not hide ongoing manual work, and an expensive implementation is not mistaken for a recurring monthly charge.
06 / Run a practical launch check
Use the provider’s supported test or sandbox process where available. Walk through the buyer and operator journeys together. Record what happened rather than marking “payments work” after seeing a confirmation screen.
- Offer: correct item, currency, amount, quantity rules, and clear one-time or recurring terms.
- Customer information: collect the fields required for delivery and check where operators retrieve them.
- Availability: verify stock, seat, or appointment behaviour, including competing purchases.
- Payment states: check success, cancellation, failure, and delayed confirmation when supported.
- Order handling: confirm matching, notifications, delivery ownership, and duplicate prevention.
- Customer support: check receipts, contact details, cancellation requests, and the documented refund process.
- Mobile journey: check readable terms, field completion, navigation, and the return path.
- Account access: ensure the business controls the account and another authorised operator can manage orders.
Before a wider release, compare the test payment record, order record, and customer message. The amount and purchase should agree across all three. Resolve unclear ownership or missing delivery information before increasing traffic.
Keep a simple link register containing the offer, destination, owner, publication locations, and retirement date. Stripe documents link deactivation and the behaviour of QR codes pointing to deactivated links. Remember printed codes and old emails when retiring an offer; removing one website button does not remove those copies.
07 / Know when to connect a fuller checkout
Move toward a store, booking integration, or application checkout when manual coordination is causing missed orders, duplicated data, or availability errors. More product choices, repeat customers, and several fulfilment operators can also make a connected system useful.
Define acceptance criteria before commissioning it: a confirmed payment updates the correct order once; failed payments do not trigger delivery; refunds can be reconciled; and staff can resolve exceptions. Ask who maintains the integration when the website or payment provider changes.
You can retain payment links for a narrow campaign while using a connected store for your main catalogue. Give each route a clear purpose and make sure both feed a record your team can manage. Review the decision using actual order volume, handling time, and error patterns rather than assuming every business eventually needs a custom checkout.
Frequently asked questions
Do I need a website to use a payment link?
Many providers support sharing hosted payment pages without a store website. You still need an eligible merchant account, a clear offer, and a process for delivering and supporting purchases.
Is a payment link the same as an invoice?
Not necessarily. A reusable offer link can serve many buyers. If you need a customer-specific amount, due date, and outstanding-balance record, compare the provider’s invoicing workflow as a separate option.
Can payment links take subscription payments?
Some can. Stripe supports subscription products, while particular pricing models have restrictions. Check the chosen provider’s recurring-payment, cancellation, and customer-management features before selling a membership.
Does website checkout have to collect card details on my server?
No. A connected website can use a provider-hosted or embedded payment interface. Choose a supported integration and confirm its responsibilities with the implementer instead of building your own card-data collection form.
Map one sale from offer to delivery. Identify the record that confirms payment, the person or system that fulfils it, and the rule protecting stock or capacity. Choose the simplest supported route that satisfies those requirements, then verify the full journey.
Sources and editorial notes
Primary provider documentation was checked on 24 October 2026. Regional eligibility, payment methods, and pricing vary. Named products illustrate implementation options; this is not a hands-on product test. Business scenarios and workload figures are hypothetical.
Add comment