Commerce-first payment infrastructure
The commerce API.
Built for humans and AI agents.
Payment APIs push commerce complexity into your app. Flint keeps every step connected through one order model, from cart to refund.
- Line items, payments & refunds in sync
- Totals, tax & discounts computed server-side
- Agent-safe schema hints on every call
- Free sandbox, keys in minutes
flintord_01JX4QT8KDstatus · ORDER_STATUS_OPEN
01The problem
You become the commerce database.
A payments API gives you a charge. An amount, a currency, nothing else. It moves the money and stops there. Everything that makes it commerce is now your problem: four systems, one transaction, and a full-time job keeping them in sync.
redis://cart≠postgres://orders≠processor://charges≠sheets://reconciliation
State drifts.
Line items, tax, and discounts live in your app. The charge lives somewhere else. They disagree, and you find out from a customer.
Refunds become detective work.
The charge says $94.50. Which two of the five items came back? Your payments API has no idea, so you reconcile by hand.
Every new flow is a new model.
Subscriptions, checkout, in-person: each one adds objects, webhooks, and sync code. The complexity compounds.
02The model
One order. Cart to refund. Always in sync.
Flint starts one level up. The order is the record: line items, modifiers, tax, discounts, tips, payments, and refunds all compute on it, with one audit trail. There’s nothing to reconcile, because there’s one system.
The payment is a field, not the foundation
Money lands on the order. Nothing to join, nothing to drift. The charge can never disagree with the cart again.
Totals you never compute
Tax, discounts, tips, and balances are calculated on the record, server-side, every time it changes.
Refunds against what was bought
Refund two of five line items in one call. Balances, tax, and inventory reconcile automatically.
{"lineItems": [{ "name": "Cold brew", "quantity": 2,"unitPriceMoney": { "amount": 650, "currency": "USD" } },{ "name": "Croissant", "quantity": 1,"unitPriceMoney": { "amount": 495, "currency": "USD" } }],"customerId": "cus_01JX4QSEW2","idempotencyKey": "order-9f31"}
totals, tax, and balance come back computed · you never wrote the math
03AI agents
The commerce layer agents can actually use.
A charge is opaque to an LLM, an amount with no meaning. A Flint order is semantic: an agent can read what was bought and reason about it. Every money-moving call ships machine-readable safety hints, so an agent knows what’s irreversible before it acts. A payments-first API structurally can’t give you this. Its primitive is the charge.
rpc CreateRefund(CreateRefundRequest) { option (agent_hints) = { operation_type: OPERATION_TYPE_CREATE side_effect_level: SIDE_EFFECT_LEVEL_FINANCIAL requires_human_confirmation: true terminal_states: "REFUND_STATUS_SUCCEEDED" terminal_states: "REFUND_STATUS_FAILED" } }
Semantic by default
An agent can read what was bought, not just what was charged: orders, line items, balances, and refund state are all one legible object.
Safety hints on every call
agent_hints annotate every call with side effects, idempotency, scopes, and terminal states, so agents know what's irreversible before they act.
Humans stay in the loop
Anything that moves money can demand explicit confirmation. Agents do the work; people approve the consequences.
the capability ceiling
An agent is only as capable as the API you hand it.
A payments API gives an agent two verbs: charge and refund. The asks that actually land are bigger, and agents can carry them now. The ceiling is the API, not the model.
| the ask | a payments API | Flint |
|---|---|---|
| “Charge my card $94.50.” | ✓can: the verb it has | ✓can: POST /v1/payment-intents |
| “Refund the grinder, not the whole order.” | ✗can't: no line items | ✓can: POST /v1/refunds · lineItems[] |
| “Add a bag of beans to my order before it ships.” | ✗can't: no order to edit | ✓can: POST /v1/orders/{id}/line-items |
| “Is the dark roast back in stock?” | ✗can't: no inventory | ✓can: GET /v1/products · stock |
| “Has my order shipped yet?” | ✗can't: no fulfillment | ✓can: GET /v1/orders/{id} · fulfillment |
| “What sold best this week?” | ✗can't: no record of what sold | ✓can: GET /v1/orders · line items |
| five asks · one missing object · the order | ||
04Use cases
Built for the whole transaction, not just the charge.
1
Refunds that know what was bought
Refund two of five line items in one call. Balances, tax, and inventory reconcile automatically, and it all lands on the order’s activity trail. No “which charge was that?”
2
Agentic commerce, safely
Give an agent a semantic order model plus per-call safety hints. It reads orders, answers “what did I pay for?”, and pauses for a human on anything that moves money.
3
Subscriptions without the price-object maze
One plan with multiple line items, a trial, a setup fee, and a dunning policy, created in a single call. No products × prices × items juggling to bill a bundle.
4
In person and online, one ledger
Hosted checkout, payment links, a virtual terminal, and POS devices all write to the same order and balance model. Sell anywhere; reconcile once.
5
Catalog, inventory & tax built in
Products, variants, and bundles with stock that deducts on payment and tax computed per line item. No separate catalog database to keep in sync.
6
Flexible ways to get paid
Pay-what-you-want donations, event tickets with numbering, deposits with auth-only capture, and custom fields to collect what you need. No custom checkout code.
7
The money-out half, too
Balances broken out as available, pending, and reserved; standard or instant payouts; a full transaction ledger. The whole money cycle, not just the inbound charge.
05The trade
The systems you don’t build.
Per-transaction pricing is the visible cost. The real one is the commerce stack around the charge: designed, hosted, monitored, and kept in sync by your team, quarter after quarter. On one order record, that backlog isn’t abstracted. It’s gone.
06Pricing
One rate. The whole stack.
No add-ons for orders, tax, subscriptions, payouts, or agent tooling. One per-transaction rate covers all of it. The fee is the product, not a line in a bigger bill.
Everything included. Start in the sandbox, go live the same day, pay only when you get paid.
- Orders, catalog, tax & discounts
- Hosted checkout, links & subscriptions
- Refunds, balances & payouts
- agent_hints on every call
- Full sandbox & API access
free sandbox · no card · keys in minutes
Rates that scale with you. Built for high volume, marketplaces, and platforms running agents at scale.
- Everything in Free, at negotiated rates
- Volume & interchange-plus options
- Dedicated support & onboarding
- SLAs & higher rate limits
talk through volume & get a quote
07How it works
Four calls from first order to full commerce.
Create the order once
Line items, totals, buyer: exactly what's being sold, written down before money moves.
POST /v1/ordersAttach checkout, get paid
Hosted checkout, a payment link, or a saved card. The payment lands on the order, not as a disconnected charge.
POST /v1/checkout-sessionsHandle the support moment
Refunds and “what did I pay for?” resolve against the order, line by line, not across systems.
POST /v1/refundsAdd the next flow later
Subscriptions, in-person, new channels: the same order model underneath. No rewrite.
POST /v1/subscription-plans08Start small
Need just a payment today? That works too.
You don’t have to adopt the whole model on day one. Charge a card in one call. When the product needs orders, checkout, or subscriptions, the upgrade is one field, not a migration. Same API, same keys.
{"amountMoney": { "amount": 2500, "currency": "USD" },"paymentSourceToken": "tok_sandbox_4242","autoConfirm": true,"idempotencyKey": "pi-20260609-001"}
drop amountMoney, add orderId · the amount now derives from the order’s balance
09Try it live
Run a real flow, before you sign up.
One click provisions a throwaway merchant, a seeded catalog, and a real API key. Pick a flow and run it against a live key for 30 minutes. No card. When it expires, it shreds itself.
creates a temporary merchant + sandbox key · free · expires after 30 minutes
Pick a flow below. Spin up a sandbox above to run it live.
The order models what's being bought
Send line items. The server prices them against the catalog, sums the subtotal, and returns the total. You never wrote the math.
- liveGET List the seeded catalog
curl 'https://api.withflintpay.com/v1/products' \ -H "Authorization: Bearer $FLINT_API_KEY"
returned2 records - livePOST Create an order from a variant
curl 'https://api.withflintpay.com/v1/orders' \ -X POST \ -H "Authorization: Bearer $FLINT_API_KEY" \ -H "Content-Type: application/json" \ -d '{"line_items":[{"variant_id":"$VARIANT_ID","quantity":2}]}'orderord_01JXDEMO0001total$128.00
the calls fill in with your key once a sandbox is live · until then $FLINT_API_KEY is a placeholder
10FAQ
Questions, answered.
Is Flint a Stripe alternative, or built on Stripe?
What's the best payment API for AI agents and agentic commerce?
agent_hints: machine-readable side-effect levels, idempotency, required scopes, and terminal states, so an agent knows what’s irreversible before it acts, and anything financial can require human confirmation. It’s plain HTTP and JSON.Do I need to build my own order or cart service if I use a payments API?
Can I refund a single line item instead of the whole charge?
POST /v1/refunds with the line items returns the money, recomputes the balance and tax, and restocks inventory automatically. A charge-only payments API can only refund an amount, so you map charges back to items by hand. Flint never loses the link between what was charged and what was bought.Do I have to adopt the whole order model on day one?
POST /v1/payment-intents call and stop there if that’s all you need. Orders, checkout, subscriptions, and payouts are the same API and the same keys when you want them. No migration, no new account.Does Flint handle tax and totals?
How does money out work with Flint?
How do I get started with Flint?
Build on the order, not the charge.
Free sandbox. No credit card. One order model from day one, for your team and the agents they ship.
POST /v1/orders · everything else follows