Manual Capture and Authorization API

A manual capture and authorization API for teams that need two-step payment flows, optional partial capture, and cleaner order-aware state transitions.

Flint exposes authorize-and-capture through the same payment-intent surface instead of pushing teams into a separate processor-only flow.

Partial capture is handled on the public capture route, with order-aware payment state instead of a detached auth hold.

Payment-intent status makes the transition explicit, so teams can operate against requires_capture instead of reverse-engineering processor behavior.

Workflow Outline

You need to authorize payment first and capture later after fulfillment, approval, or inventory confirmation.

Your flow benefits from optional partial capture instead of forcing the full amount at authorization time.

You want capture state to stay visible in the same order and payment model as later refunds and support actions.

What This Solves

Teams searching manual capture APIs usually need a two-step payment flow where they can authorize first, capture later, and optionally capture less than the original amount.

Step 1

Fulfillment-gated capture

Authorize first, then capture only when the order is ready to ship, release, or hand off to the buyer.

Step 2

Inventory-sensitive flows

Hold funds before final allocation, then capture only once inventory, seats, or service capacity are confirmed.

Step 3

Partial shipment or staged fulfillment

Capture less than the original authorization when the final shipped or delivered amount changes.

Step 4

Approval-driven collection

Let operations confirm the sale first, then settle the authorized payment without rebuilding the flow in a processor dashboard.

Why Flint Fits

Flint exposes authorize-and-capture through the same payment-intent surface instead of pushing teams into a separate processor-only flow.

Partial capture is handled on the public capture route, with order-aware payment state instead of a detached auth hold.

Payment-intent status makes the transition explicit, so teams can operate against requires_capture instead of reverse-engineering processor behavior.

Choose Another Path When

Use immediate capture when the product does not need delayed settlement or post-authorization decision points.

Use hosted checkout pages when the main problem is buyer payment collection, not later operational capture control.

Use invoice-led collection when formal billing and manual settlement matter more than card authorization behavior.

Implementation References

Reference the exact flow surfaces

Payments API

See payment-intent create, confirm, and capture routes including partial capture support.

Rate Limits Guide

Review the capture route in Flint's public operational guidance for write-heavy integrations.

Orders API

Inspect the order model that stays attached to capture-driven payment state and later refunds.

Explore authorization, capture, and adjacent payment controls

These pages connect two-step payment collection to the broader Flint payment and order model.

Hosted Checkout API for Developers

Use this when the main need is a hosted payment surface, not two-step auth and capture control.

Payment API

Go broader when manual capture is one capability inside a wider payment integration decision.

Idempotent Payment API

Useful when authorize-and-capture flows also need explicit retry safety on create, confirm, and capture.

Next Step

Ship the workflow before polishing the edge cases

Start with the underlying Flint flow, then layer your product-specific UX and recovery paths on top.