B2B Commerce API | Flint Pay

B2B Commerce API

A B2B commerce API for teams that need order-backed balances, invoice collection, manual settlement, and post-payment workflow state on one platform.

Teams searching B2B commerce APIs usually need more than checkout. They need quote-like pre-payment order state, customer-specific balances, invoice collection, manual settlement, and post-payment operations that survive beyond one card attempt.

Flint already supports order-backed invoices, quick-pay invoices, hosted invoice checkout, reminders, and manual payment recording through one public API family.

Balances stay attached to an order and can later become receivables, which is stronger for B2B workflows than treating each collection moment as a disconnected payment request.

Hosted checkout, invoices, and manual settlement can coexist without the app inventing a separate billing subsystem beside the payment 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

The workflow starts with an order or balance, then later becomes invoice-led receivables, hosted collection, or manual settlement.

Platform 2

Your product needs pay-now and pay-later collection paths on the same business record instead of separate checkout and billing systems.

Platform 3

Support and finance need one place to read the balance, hosted attempts, reminders, and offline payment history later.

Scenario 1

Order first, invoice later

Start from an open order and convert the remaining balance into an invoice when the buyer needs a formal receivable instead of immediate checkout.

Scenario 2

Quick-pay invoice workflows

Create a direct invoice flow without creating the order separately when the B2B product starts from billing rather than storefront-style checkout.

Scenario 3

Mixed online and offline settlement

Support hosted invoice card collection plus manual payment recording on the same collectible balance instead of splitting AR across tools.

Scenario 4

Post-payment support and finance

Keep reminders, delivery attempts, partial payments, and later reversals visible on one receivables workflow record.

Choose Something Narrower When

Use direct checkout pages when the workflow is immediate payment only and does not need receivables, reminders, or manual settlement.

Use the invoice-collection page when the evaluation is mainly about receivables mechanics rather than the broader B2B commerce model.

Use the commerce API flagship when the product scope goes well beyond B2B billing and order-backed balances.

Implementation References

Reference the platform-level surfaces

Invoices API

Create, send, collect, remind, and track invoices as receivables records.

Invoicing Guide

Walk through hosted invoice payment, reminders, and manual payment recording.

Orders First Guide

See how an open balance can begin as pay-now and later become an invoice-led receivable.

Explore receivables, manual settlement, and Flint's broader commerce model

These pages narrow the next step once you know the product needs a real B2B order-and-balance workflow instead of one-off payment collection.

Invoice Collection API for B2B Platforms

Use this when the current focus is the receivables side of the workflow rather than the broader B2B commerce model.

Bank Transfer and Manual Settlement API

Use this when the immediate requirement is recording offline or external payments against open receivables.

Commerce API

Go broader when the product surface extends beyond B2B billing and receivables flows.

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.