Embedded Payments API for SaaS

An embedded payments API for SaaS teams that want to keep checkout on their own surface while still using Flint's order-backed payment model.

Teams searching embedded payments APIs usually want to keep checkout on their own surface, but they still need the backend payment state tied to a real order instead of a generic amount.

Flint supports order-linked embedded payments with Stripe Elements instead of forcing teams to choose between embedded UX and order-backed commerce state.

The embedded flow still starts with a Flint order and payment intent, so totals, discounts, and later refunds stay attached to the same business record.

Teams can keep Stripe.js on the frontend while moving backend order and intent creation into Flint's public API.

Open the Technical Surface

Quickstart

Start with the first request.

API Reference

Open the REST surface.

Orders First

See the core model.

Benchmark

Compare developer workflows.

Use This Platform Shape When

Platform 1

You want checkout to stay on your own domain, but you still need Flint to own the order and payment-intent model.

Platform 2

Your SaaS product wants embedded card collection with Stripe Elements without falling back to a charge-first backend design.

Platform 3

You need line items, totals, and later refunds to stay attached to the same Flint order that launched the payment flow.

Scenario 1

In-app SaaS checkout

Create the Flint order and payment intent on the backend, then confirm the payment with Stripe Elements inside your own product UI.

Scenario 2

Order-linked embedded billing

Keep discounts, totals, and later payment lifecycle state attached to the order instead of a raw embedded charge amount.

Scenario 3

Stripe.js frontend, Flint backend

Keep Stripe.js and Elements on the frontend while moving backend order and payment orchestration into Flint's public API.

Scenario 4

Supportable post-payment workflows

Avoid the usual embedded-payments tradeoff where the UX is in-product but the order and refund model still has to be rebuilt elsewhere.

Choose Something Narrower When

Use hosted checkout when Flint should own the payment page and you do not need checkout embedded inside your app.

Use payment links when the main need is a shareable hosted collection surface rather than embedded buyer UX.

Use the broader payment API page when embedded checkout is only one capability in a larger integration decision.

Implementation References

Reference the platform-level surfaces

Embedded Payments Guide

Step-by-step guide for order-linked embedded payments with Flint and Stripe Elements.

Payments API

Create the payment intent that powers the embedded checkout flow.

Orders API

Create the order that anchors totals, line items, and later payment lifecycle state.

Explore embedded checkout, hosted checkout, and adjacent SaaS payment flows

These pages help place embedded payments inside Flint's wider order-backed payment model.

Hosted Checkout API for Developers

Use hosted checkout when Flint should own the payment page instead of the buyer staying on your domain.

Payment API

Go broader when embedded payments are only one part of the larger payment-platform decision.

Payments API for Vertical SaaS

Useful when the embedded flow belongs inside a wider software-platform payments strategy.

Next Step

Wire the platform boundary first

Define auth, merchant scope, and install flow first, then let the narrower payment and checkout pages sit underneath it.