Saved Payment Methods API for Platforms

A saved payment methods API for platforms that need repeat purchases, subscriptions, and off-session billing without losing customer and order context.

Developers searching saved payment methods APIs usually need repeat billing and off-session charging without turning card-on-file into a disconnected billing subsystem.

Flint stores customer-linked payment methods directly in the public API instead of hiding card-on-file setup behind a separate billing product.

Saved payment methods plug into payment intents and subscriptions using the same customer and order model.

Teams can set a default payment method, reuse it later, and still keep readiness checks explicit for safer off-session charging.

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 need repeat purchases, subscriptions, or later collection tied to a real Flint customer record.

Platform 2

Your product wants stored payment methods inside the same API model as orders, subscriptions, and support workflows.

Platform 3

You need explicit readiness and default-payment behavior before charging off-session.

Scenario 1

Repeat customer purchases

Save a customer's payment method once, then reuse it later for faster repeat purchases without rebuilding customer context.

Scenario 2

Subscription defaults

Set a default payment method so later subscription creates and billing runs can use the same customer-linked source cleanly.

Scenario 3

Later balance collection

Bill an existing customer later without turning card-on-file into a separate billing subsystem or shadow data model.

Scenario 4

Operator support workflows

Let support and ops teams see saved-payment state in the same customer and order model they already use.

Choose Something Narrower When

Use immediate one-time payment flows when customers do not need stored payment credentials for later billing.

Use subscription pages when recurring lifecycle logic matters more than card-on-file setup itself.

Use hosted checkout alone when a shareable payment page matters more than storing a reusable payment method.

Implementation References

Reference the platform-level surfaces

Payment Methods API

Create, list, remove, and set default Flint payment methods for a customer.

Customers API

Review the customer model that anchors saved payment methods and default payment state.

Subscriptions API

See how saved payment methods feed subscription billing and default payment behavior.

Explore stored payment methods and later-billing workflows

These pages connect card-on-file setup to subscriptions, off-session charges, and the broader payment model.

Off-Session Payments API

Use this when the real requirement is background charging and later collection behavior.

Subscription API

Go broader when saved payment methods are mainly supporting recurring billing workflows.

Payment API

Use the core page when stored payment methods are only one part of the wider integration decision.

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.