A Stripe Payment Link and a Stripe Checkout Session can show customers a similar hosted payment page. The important difference sits before that page opens: a Payment Link is a reusable object with a public URL, while a Checkout Session is usually created for a particular attempt to pay.

That distinction affects how much context your application can attach, how you manage returning customers, and which event should start fulfilment.

Documentation checked: 29 October 2026. Stripe changes product capabilities over time, so confirm the current API reference before implementation.

Stripe’s API describes a Payment Link as an object with its own public url and an active state. You configure what is sold, then share that URL in a website, email, QR code or support conversation. The same link can be opened repeatedly until it is deactivated.

The object can hold checkout settings such as promotion-code support, address and phone collection, automatic tax, shipping options and post-purchase behaviour. Its strength is distribution: the seller can publish one stable route without building a server endpoint for every buyer.

That stability is also the constraint. A public link is not automatically tied to the signed-in user, cart or quotation that led to it. If an order needs a unique internal reference, entitlement or amount, you must design that relationship deliberately.

What a Checkout Session changes

A Checkout Session is created for a payment flow. Stripe’s hosted Checkout example starts with a button that calls a server endpoint, creates a Session with line items and a success URL, then redirects the customer to the returned Session URL.

Because your server creates the Session, it can choose the line items and attach the correct customer or internal reference at that moment. Stripe documents support for associating a Session with a customer object and for prefilling eligible saved-card details. That makes Checkout the more direct fit when price, inventory, account state or access rights are computed inside your application.

The Session URL should be treated as the route for that attempt, not as a permanent product page.

The practical decision

Use a Payment Link when the offer is intentionally reusable and the buyer does not need a unique server-generated cart before reaching the payment page. Typical examples include a fixed-price download, a donation, a booking deposit or a simple subscription offer.

Use a server-created Checkout Session when any of these conditions apply:

  • the amount or items depend on the current cart;
  • only a signed-in customer may buy;
  • your system must attach a unique order or account reference;
  • availability must be checked immediately before payment;
  • the customer should see saved payment details linked to an existing customer record.

A Payment Link can still create Checkout Sessions behind the scenes, and it supports many of the same collection options. The choice is therefore not “simple page versus real checkout.” It is whether the payment configuration begins as a reusable public object or as application state created for one flow.

Do not fulfil from the return page

Both approaches need server-side event handling. Stripe explicitly warns that starting fulfilment only after the customer reaches your success page is unreliable. A customer can close the tab, lose connectivity or complete a delayed payment method after the redirect.

For Checkout, Stripe documents the checkout.session.completed event, plus asynchronous success and failure events for delayed payment methods. Your webhook handler should verify the event, make fulfilment idempotent and record which internal order has already been processed.

The success page can explain what happens next. It should not be the only system that decides whether access, shipping or a confirmation is issued.

A small implementation checklist

Before choosing either route, write down the values that must remain unique: customer, cart, price, currency, entitlement and internal order ID. If several of them are calculated at request time, create a Checkout Session on the server. If the offer is deliberately fixed and shareable, a Payment Link removes application work without removing the need for webhook-based fulfilment.

Also decide what happens when a link is deactivated, a price changes, a payment is delayed or the webhook is delivered twice. Those cases reveal the real integration boundary more clearly than the appearance of the hosted form.

Sources

For the next layer of the integration, see Webtamine’s guide to Stripe webhook signature verification.