Commerce API with Server-Computed Totals

A commerce API with server-computed totals for teams that want subtotal, discount, tax, paid, refunded, and balance to live on the order instead of in application glue.

Why teams choose this primitive

Flint's order model exposes computed net amounts directly, so the API can return subtotal, discount, tax, total, paid, refunded, and remaining balance as one coherent state surface.

Hosted checkout, embedded pay, invoices, and refunds all work against the same server-computed order balance instead of each surface maintaining its own math.

This makes support, finance, and automation easier because the order record is already the authoritative total source, not just a copy of frontend calculations.

Build This When

The team is tired of recalculating subtotal, discount, tax, paid, refunded, and balance in many different places every time the order changes.

Checkout, invoices, and refunds all need to depend on the same authoritative order totals rather than copies of frontend math.

Support, finance, and automation should be able to read one server-computed state surface instead of reconciling many application tables.

Quickstart

Start with the first request.

API Reference

Open the REST surface.

Orders First

See the core model.

Benchmark

Compare developer workflows.

Why Developers Reach for This

Teams searching commerce APIs with server-computed totals usually want to stop recalculating subtotal, discount, tax, paid, refunded, and balance in many places every time the order changes.

Case 1

Authoritative checkout totals

Let hosted and embedded checkout work from server-computed order net amounts so the frontend never becomes the source of truth for payment amount.

Case 2

Refund-aware balances

Keep refunded, paid, and remaining balance fields attached to the same order record after post-purchase changes happen.

Case 3

Invoice conversion from open balance

Turn an order balance into an invoice later without recalculating what is owed from scratch in a separate billing subsystem.

Case 4

Operational reporting from one record

Give support and finance one computed totals surface instead of making them interpret cart state, payment records, and refund ledgers separately.

Choose Something Else When

Use the broader payment API page when totals computation is only one capability inside a larger order-first integration decision.

Use embedded-payments pages when the current problem is buyer-facing collection implementation rather than state ownership of totals.

Use invoice pages when the immediate need is receivables behavior rather than computed order amounts themselves.

Implementation References

Orders API

Inspect the `net_amounts` fields Flint computes and maintains on the order record.

Orders First Guide

See why hosted and post-payment surfaces should attach to one order-defined balance.

Payments API

Review how order-linked payment intents derive the amount from the current order balance.

Explore order-backed totals, refunds, and checkout state

These pages connect computed totals to the broader order, checkout, and refund workflows that depend on them.

Payment API

Use this when the real evaluation is Flint's broader order-first payment model, not totals computation alone.

Payments API That Keeps Cart, Order, and Refund State in Sync

Use this when the question expands from totals into the broader workflow state around checkout and refunds.

Embedded Payments API for SaaS

Useful when server-computed totals need to power embedded checkout without frontend amount math becoming the source of truth.

Next Step

Move from evaluation into a real integration

Start with the quickstart, wire the right Flint primitive, then issue keys when the flow is ready for real traffic.