When should I use hosted checkout instead of a payment link?

Use hosted checkout when the payment should come from a specific order with fixed items, totals, discounts, tax, and downstream lifecycle state. Use a payment link when you need a reusable page that is faster to share.

How is hosted checkout different from an invoice?

Hosted checkout is usually centered on a purchase flow or existing order. An invoice is centered on formal billing and accounts-receivable style follow-up.

Hosted Checkout | Flint Pay

Home FeaturesHosted Checkout

Hosted Checkout

Flint hosted checkout gives you order-backed payment pages when you need more structure than a reusable link can provide.

Launch buyers into a hosted payment page from a specific order instead of rebuilding business context later.

Keep line items, discounts, tax, redirects, and post-payment state tied to the same checkout flow.

Use hosted checkout when a reusable payment link is too loose and a formal invoice is the wrong shape.

Why Developers Reach for This

Teams searching hosted checkout usually want a payment page they do not have to build themselves, but they still need a real order behind it instead of a disconnected payment amount.

Implement This When

The buyer should pay for a specific order, quote, cart, or registration with fixed items and totals.

You want a hosted page now, but you still care about the order lifecycle after payment succeeds.

You need more structure than a generic payment link without building the full checkout UI yourself.

Implementation Path

Start with the docs for this flow

Use the quickstart, API reference, orders model, and benchmark to move from evaluation into implementation.

Quickstart

Ship the first payment flow before you wire the whole stack.

API Reference

Open the REST surface for orders, checkout, subscriptions, and refunds.

Orders First

See the model behind Flint's order-backed payment approach.

Benchmark

Compare Flint against other developer payment workflows.

Common Implementation Patterns

Quote acceptance

Turn an approved quote into an order-backed hosted payment page with exact items and totals already set.

Cart and registration handoff

Move a configured purchase, signup, or event registration into hosted checkout without losing the structured order underneath it.

Existing-order collection

Send buyers back into the current hosted payment path for an order that still needs settlement.

Discount and tax-aware checkout

Use hosted checkout when the page needs to reflect real totals, not just a raw amount to collect.

Choose a Different Primitive When

Use payment links when the real need is a reusable page that operators can share quickly across many buyers.

Use invoices when the workflow is accounts receivable, formal billing, or post-service collection with reminders and due dates.

Use direct subscriptions or plan-based signup when the goal is recurring billing rather than a one-time order-backed payment flow.

Implementation Docs

Checkout Sessions API

Reference for creating hosted checkout tied to a Flint order.

Checkout Sessions Guide

Implementation guide for order-backed hosted checkout flows.

Explore hosted-checkout decisions and nearby payment models

These pages are the next useful stop when hosted checkout is only one piece of the buying decision.

Payment Links

Shareable hosted checkout pages for deposits, donations, event payments, and fast remote collection.

Invoices

Send itemized invoices with hosted payment, reminders, status tracking, and cleaner follow-up than manual chasing.

Payment API

Order-first payments for developers who need line items, tax, discounts, refunds, and a full audit trail in one flow.

Ecommerce Payment API

A payment API built for carts, order state, checkout, and downstream reconciliation rather than isolated charges.

Next Step

Turn this feature into a working integration

Start with the quickstart, pick the Flint primitive that matches the workflow, then wire in the API surface and sandbox behind it.