Omnichannel Commerce API for POS and Ecommerce

An omnichannel commerce API for teams that need online orders, in-person payments, devices, and refund state to stay aligned across channels.

Teams searching omnichannel commerce APIs usually need online orders, in-person payment flows, devices, and post-purchase state to stay coherent instead of becoming two separate systems joined by support work.

Flint already models order-backed payment flows across multiple sources including `checkout`, `payment_link`, `api`, `pos`, and `subscription`.

Devices, order state, hosted fallback collection, and refund workflows can stay inside one public platform instead of splitting ecommerce and POS into unrelated payment stacks.

The order-first model is especially useful once a buyer can start online, finish in-person, or need later recovery and refund work across both channels.

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

Buyers can start online, finish in person, or need later recovery and refunds across both ecommerce and POS-adjacent flows.

Platform 2

Your product needs device context, order state, and hosted fallback collection to stay aligned instead of becoming two separate systems.

Platform 3

Support and finance need one record of the sale even when payment can happen through different channels and sources.

Scenario 1

Online to in-person completion

Let a buyer begin from a storefront or operator-created order, then finish collection in a POS-aware flow without losing the original business record.

Scenario 2

In-person to hosted follow-up

When a register or operator flow cannot collect the full amount immediately, hand the remaining balance into hosted checkout or another Flint collection surface later.

Scenario 3

Cross-channel refunds

Keep post-purchase adjustments attached to the same order even if the original payment path crossed online and in-person contexts.

Scenario 4

Device-aware operations

Track merchant devices and POS source context without creating a second payment system beside the ecommerce stack.

Choose Something Narrower When

Use the POS page when the problem is overwhelmingly device-driven and in-person rather than a true online-plus-in-person commerce architecture.

Use the ecommerce-platform page when the concern is primarily storefront and checkout rather than cross-channel order coherence.

Use checkout-specific pages when the current question is only which buyer payment surface to show, not omnichannel state ownership.

Implementation References

Reference the platform-level surfaces

Devices API

Create and manage merchant devices and device metadata for in-person and device-aware flows.

Orders API

Use the order model that survives across online and in-person payment moments.

Payments API

Review payment-intent sources, including `pos`, `checkout`, `payment_link`, and `api`.

Explore the POS, ecommerce, and hosted-flow surfaces around omnichannel state

These pages help split true cross-channel architecture from narrower POS or ecommerce-only evaluations.

Payments for POS Integrators

Use this when the evaluation is more POS-heavy and device-driven than omnichannel architecture-heavy.

Payments API for Ecommerce Platforms

Use this when the primary architecture question is ecommerce platform state rather than the crossover between channels.

Hosted Checkout API for Developers

Useful when an in-person or operator-driven workflow still needs to hand a remaining balance into Flint-hosted checkout later.

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.