Hosted Checkout API for Developers

Hosted checkout for teams that want a real order-backed payment page without rebuilding checkout state around a generic amount.

Checkout sessions stay attached to the order, so line items, discounts, tax, and refund state stay intact after payment.

The same order can move between direct payment, hosted checkout, invoices, and refunds without creating a second business record.

Hosted checkout is one step in the order lifecycle, not a detached page you reconcile later.

Workflow Outline

Each buyer should land on a payment page tied to one known order, quote, registration, or balance.

You want hosted checkout now, but you still need order lifecycle and refund state to stay intact.

You need more structure than a reusable payment link, but you do not want to build the full checkout UI yet.

What This Solves

Teams searching hosted checkout APIs usually want a page they do not have to build themselves, but they still need it tied to a real order, quote, registration, or balance.

Step 1

Quote acceptance

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

Step 2

Registration and booking collection

Move a signup, appointment, or reservation into hosted checkout without losing the structured order underneath it.

Step 3

Existing-order balance collection

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

Step 4

Discount and tax-aware checkout

Use hosted checkout when the buyer page must reflect real line items, discounts, and computed totals.

Why Flint Fits

Checkout sessions stay attached to the order, so line items, discounts, tax, and refund state stay intact after payment.

The same order can move between direct payment, hosted checkout, invoices, and refunds without creating a second business record.

Hosted checkout is one step in the order lifecycle, not a detached page you reconcile later.

Choose Another Path When

Use payment links when the same hosted path should be reused across many buyers or messages.

Use invoices when billing record, reminders, and receivables workflow matter more than checkout speed.

Use direct embedded payments when the product experience should stay inside your app from the start.

Implementation References

Reference the exact flow surfaces

Checkout Sessions API

Reference for creating, retrieving, and managing Flint-hosted checkout sessions.

Checkout Sessions Guide

Implementation guide for order-backed hosted checkout flows.

Orders API

Inspect the order model that anchors hosted checkout and later refund state.

Explore nearby hosted-checkout decisions

These pages are the next stop when hosted checkout is only one part of the integration design.

Payment Links API for Platforms

Use this when the real need is a reusable hosted link rather than a specific checkout instance.

Invoice API with Hosted Payments

Use this when the billing record itself should be the first-class object instead of an order checkout flow.

Payment API

Go broader when the real decision is order-first payments, not just the hosted collection surface.

Next Step

Ship the workflow before polishing the edge cases

Start with the underlying Flint flow, then layer your product-specific UX and recovery paths on top.