Payment links vs checkout sessions
When to use a reusable payment URL and when to create a one-time checkout from your backend.
A payment link is a reusable offer. A checkout session is a one-time payment instance. They can lead to the same hosted checkout, but they solve different integration problems.
Use a payment link when the product, price and billing mode are fixed. Use a server-created checkout session when the order is dynamic or the customer reference must be trusted.
Reusable payment links
A payment link can be placed on a landing page, sent in a message or turned into a QR code. Each buyer opens the same public URL. The payment service creates a separate checkout transaction after the buyer starts payment.
The public URL should not allow a buyer to change the price, project, payout address or billing mode.
A query parameter such as client_reference_id can help the merchant reconcile a payment:
https://app.stendly.com/p/pl_example?client_reference_id=workspace_42Because the parameter is public, it must be treated as untrusted input. It is suitable for labels and low-risk attribution, not proof of identity.
One-time checkout sessions
A checkout session is created by the merchant backend for one customer or order. The request can contain a trusted external customer ID, merchant order reference, dynamic amount, return URLs and an idempotency key.
The resulting URL normally expires and should be used for one purchase. This model is safer for account credits, private workspaces and orders where changing the reference could give value to the wrong person.
Comparison
| Need | Payment link | Checkout session |
|---|---|---|
| Same fixed plan for many buyers | Good fit | Works, but adds server work |
| Dynamic price or order | Poor fit | Good fit |
| No backend integration | Good fit | Not possible |
| Trusted customer binding | Not through public query alone | Good fit |
| Share by email or social channel | Good fit | Possible, but usually generated per order |
| Idempotency for order creation | Limited to checkout start | Controlled by merchant backend |
Fulfillment is separate
Neither URL type should activate a product merely because the browser reached a success page. The merchant should wait for a signed payment event, verify it and process it idempotently.
For a no-code product, hosted success may be enough. For SaaS access, credits or subscriptions, a webhook or another server-side integration is normally required.
How Stendly uses both
Stendly Payment Links store a fixed product and price and can be shared repeatedly. Starting payment creates a new checkout session, invoice and payment intent. The public link can carry an untrusted client_reference_id.
Stendly's Billing API and SDKs can also create checkout sessions directly. That route supports backend-controlled customer and order references.
Questions people ask
Can a payment link replace an SDK?
It can replace the SDK for a fixed hosted checkout. It does not replace backend logic when the merchant must update its own database after payment.
Can the buyer change the amount in a payment link?
A well-designed link ignores public attempts to change protected fields. The server should load the amount and billing mode from the stored payment-link configuration.
Should a subscription use a payment link?
A fixed subscription plan can start from a payment link. Whether future charges happen automatically depends on the payment authorization model. Many wallet-based flows require the buyer to approve later payments or invoices.