Best when one reusable collection surface serves the job.
Best when the payment page belongs to one specific order, quote, or balance due.
What This Page Answers
Should this flow start from a reusable payment link or a one-off hosted checkout session?
Use payment links when the collection surface needs reuse or operator delivery. Use checkout sessions when the buyer should land on a page tied to one specific order, quote, registration, or balance.
Teams usually choose the wrong hosted surface when they optimize for speed instead of workflow fit.
Payment links and checkout sessions can both get a buyer onto a hosted page quickly. The difference shows up later: whether the page needed to be reusable, whether operators were going to send it manually, and whether the resulting payment had to stay attached to a specific order record from the start.
Because Flint gives both surfaces on one public platform, the choice can stay about workflow fit instead of forcing you into separate systems.
Code comparison
The shape of the first write tells you which hosted surface you really need
Create a payment link when you are publishing a reusable collection surface. Create a checkout session when the page belongs to one business record already in motion.
const link = await flint.paymentLinks.create({title: "Collect membership dues",amountMoney: { amount: 15000, currency: "USD" },source: "payment_link",});return link.url;
const order = await flint.orders.create({lineItems: [{ name: "Event registration", quantity: 1, unitPriceMoney: { amount: 15000, currency: "USD" } }],});const session = await flint.checkoutSessions.create({orderId: order.orderId,});return session.url;
Comparison
Use reuse and business specificity to make the choice
Both surfaces are hosted. The difference is whether the page is generic and reusable or attached to one known workflow instance.
| Capability | Payment links | Hosted checkout sessions |
|---|---|---|
Primary job What the hosted page is optimized for | Reusable collection surface | Specific order-backed payment moment |
Who typically sends it Operator, system, or app workflow | Operators, email, SMS, QR, public pages | Application flow for one buyer and one record |
Reusability Can the same hosted URL be used repeatedly? | Yes | No, it belongs to one checkout instance |
Best starting record What should already exist | A collection use case or reusable offer | A specific order, quote, or balance due |
Operational feel How the flow behaves day to day | Good for remote collection and operator-driven sharing | Good for app-driven checkout with a known transaction context |
The right choice is usually obvious once you ask whether the page should be reused or whether it belongs to one known business record.
Flint keeps both surfaces on one model
This comparison matters because many platforms force teams to choose one hosted primitive and then stretch it into jobs it was not designed for.
Flint keeps both payment links and checkout sessions in the same public platform, so the choice can stay about workflow shape rather than long-term system fragmentation.
Decision path
How to choose quickly
Ask these questions in order and the answer is usually straightforward.
Is the hosted page reusable?
If yes, start with a payment link. If no, keep going toward checkout session.
Does one specific order already exist?
If the answer is yes, a checkout session is usually the better fit because the flow belongs to that order.
Will operators manually send the page often?
If the flow is often texted, emailed, or posted by operators, payment links are usually cleaner.
Implementation
Read the hosted-flow docs that prove the surfaces are distinct
These docs are the fastest way to validate which hosted collection primitive maps to your workflow.
Frequently asked questions
Related Pages
Read the adjacent hosted-flow pages next
These pages go deeper on each hosted surface once you know which workflow shape you actually need.