What is the simplest way to explain payment links versus hosted checkout?

A payment link is a reusable URL. Hosted checkout is the specific checkout session the buyer lands in. In Flint, payment links create fresh checkout sessions and orders when a buyer uses them.

Are payment links and hosted checkout competing products in Flint?

Not really. Payment links sit on top of hosted checkout. The real decision is whether you need a reusable public entry point or a one-off hosted session tied to a specific payment flow.

When should I start with payment links?

Start with payment links when the main job is sharing one hosted page repeatedly by text, email, QR code, social, or a website. They are usually the fastest route live.

When should I start with checkout sessions?

Start with checkout sessions when you already have exact order or plan context and want a hosted payment page for that one flow. That is common in app-driven or order-backed experiences.

Can payment links still support recurring billing or events?

Yes. Flint payment links support plan-backed subscription signup, donation flows, and event-mode links with event-specific settings. That is part of why links are more than a generic pay-now URL.

Can checkout sessions be reused?

No. Checkout sessions are the one-off hosted payment page itself. If the workflow needs repeated public reuse, payment links are the better primitive.

Workflow guide

Hosted checkout vs payment links is really a question about reuse vs specificity

In Flint, payment links are reusable hosted URLs. Checkout sessions are one-off hosted payment pages created from quick pay, an existing order, or a plan. The right choice depends on whether you are publishing one repeatable entry point or issuing one exact payment page for one exact flow.

Payment links create fresh checkout sessions and orders when buyers use them.

Checkout sessions can start from quick pay, an existing order, or a subscription plan.

Both surfaces share hosted checkout controls, but they solve different workflow problems.

Start with the actual distinction

Flint's payment links and hosted checkout are adjacent, not interchangeable

Payment links sit above hosted checkout. They are reusable link templates for public or repeated distribution. Checkout sessions are the concrete hosted payment page itself. Once you understand that split, the decision gets much simpler.

Choose payment links

You need one reusable URL that keeps working across many purchases

Payment links are Flint's shareable distribution layer. The same link can live in a text thread, email template, website, QR code, or social profile and create a fresh hosted checkout each time a buyer opens it.

Best for repeatable one-off collection, donation pages, event sales, and reusable subscription signup links.

Supports custom fields, quantity adjustments, donation amounts, event settings, redirects, tips, and coupons.

A strong fit when the operator wants to publish once and reuse the same path everywhere.

Choose hosted checkout

You need one specific hosted payment page for one specific payment flow

Checkout sessions are Flint's one-off hosted pages. They are the right fit when you already know the exact order, quick-pay amount, or subscription plan and want a single checkout URL for that specific flow.

Best for exact balances, buyer-specific follow-up, order-backed payments, and one-time plan signup sessions.

Create from quick pay, an existing order, or a plan depending on how much state already exists.

A stronger fit when the hosted page should reflect one precise payment attempt, not a reusable public link.

Comparison

Choose based on how the payment flow begins

Buyers do not care what primitive you chose. Your operators and developers do. Use the surface that matches how the money request starts and how often the exact same path needs to be reused.

Payment links

Hosted checkout

Lifecycle

The URL either behaves like a reusable entry point or a single payment instance.

Reusable link template that spawns a fresh checkout session and order whenever it is resolved.

One checkout-session URL for one concrete hosted payment flow.

Best distribution model

This decides whether you publish once or issue a new link each time.

Text, email, QR code, website button, social bio, event page, donation page, or recurring reuse.

Send a specific payment page from your app, dashboard, CRM, quote flow, or order follow-up message.

Source of truth

Teams either start from a reusable template or from known order state.

A hosted template with line items or a plan that generates new payment state on each visit.

A specific quick-pay amount, an existing order, or a specific plan signup flow.

Customer specificity

Shared public links and buyer-specific sessions are different operational tools.

Built to be shared broadly. Payment links do not attach a specific customer ID ahead of time.

Can be more buyer-aware through existing order context, prefilled customer info, or customer linkage.

Where Flint adds extra workflow depth

Some needs are link-first, others are session- or order-first.

Donation mode, event mode, custom fields, max completions, activate/deactivate, and reusable public URL management.

Order-backed payment pages, quick-pay generation, validation callbacks, close session control, and explicit session status handling.

When teams usually graduate

Growth often means moving from simple collection into more exact operational state.

Start here when the main problem is getting a hosted page live fast and reusing it repeatedly.

Move here when the business needs the hosted page tied tightly to a known order, balance, or one-off billing action.

Common picks

What this decision looks like in real Flint workflows

The choice becomes obvious when you anchor it to an operator job: send a reusable link, launch checkout from an order, or start a recurring signup page that stays live after the first buyer pays.

Text-to-pay

Use payment links when the link itself is the product

If the workflow is 'text the customer a link and let them pay now,' a reusable payment link is the cleaner default.

Deposits

Use payment links when you need repeatable prepayment collection

Booking deposits, travel fees, and simple retainers usually want one reusable hosted path rather than a new session every time.

Exact balance

Use hosted checkout when you already have the order

If the line items, discounts, tax, or remaining balance already live on an order, launch checkout from that order and keep the payment attached to it.

Recurring signup

Choose based on whether the signup page is reusable or one-off

Use a subscription payment link for a reusable public signup page. Use a checkout session when you need a specific hosted session from a particular plan flow.

Events

Use payment links when the page should stay public and repeatable

Event and ticket sales fit reusable hosted links because buyers keep arriving from many channels and each visit should create fresh checkout state.

Developer app handoff

Use hosted checkout when your app is issuing payment pages programmatically

If your own app decides when to create a buyer-specific page, checkout sessions are the more direct primitive.

Product reality

Flint already supports the hosted controls most teams need on both paths

This is not a choice between a simple product and an advanced one. It is a choice between two hosted surfaces that share a lot of checkout capability but differ in reuse, order context, and lifecycle behavior.

Hosted payment UI without building card forms

Both surfaces give you a Flint-hosted checkout instead of forcing a custom payment frontend first.

Checkout controls around the payment

Theme, payment settings, tax, legal, expiration, redirects, coupons, and tips are part of the hosted surface model on both paths.

Customer information capture

Both flows can collect buyer contact details and checkout context instead of reducing everything to a blind charge.

Payment links add reusable public-link behavior

Activate or deactivate a link, cap total completions, attach custom fields, run donation mode, or configure event-specific behavior for ongoing public use.

Checkout sessions add one-off operational control

Create from quick pay or an existing order, attach a precise hosted session to a known flow, and close the session when the payment window should end.

Both paths can participate in recurring billing

Payment links are stronger for reusable public signup pages, while checkout sessions are stronger for a specific hosted plan flow initiated by your system.

Docs handoff

Go one level deeper once the workflow choice is clear

The fastest implementation path depends on whether you are starting from reusable link distribution or from known payment state already living in your system.

Payment Links API

Review reusable hosted links, custom fields, donation mode, event mode, and plan-backed link creation.

Checkout Sessions API

See how Flint creates hosted checkout from quick pay, an existing order, or a subscription plan.

Orders API

This matters when checkout should start from a real order record rather than from a reusable public link.

Subscription Payment Links Guide

Use this when the question is not one-time checkout, but reusable hosted signup for recurring billing.

FAQ

Questions teams usually ask before choosing

The confusion usually disappears once the team stops comparing two checkout pages and starts comparing two different workflow entry points.

Keep exploring

Related Flint pages for the next workflow question

These pages go deeper into the use cases most teams evaluate right after they settle the hosted-checkout versus payment-links question.

Collect Deposits

A workflow page for booking deposits and prepayments where reusable payment links are often the fastest fit.

Event Ticket Payments

A workflow page showing why event collection usually wants a reusable hosted link rather than a one-off session.

Payment Links vs Invoices

A related decision page for teams replacing slower accounts-receivable workflows with hosted payment flows.

Payment API

The broader Flint page for order-backed payment flows when hosted checkout needs stronger commerce context.

Start with the right surface

Use payment links when you need reuse. Use hosted checkout when you need exact flow control.

That is the real decision. Flint supports both paths, so you do not need to force every workflow into the same hosted payment shape.