On Flint, a payment usually belongs to an order. Submit the buyer's payment method to /v1/orders/{order_id}/pay and Flint creates and pays a payment intent for the full balance in one request. To do that, render collection fields from the order or checkout session's payment_collection guidance, create a payment method in the browser, and send it with action: "pay" and payment_source. Payment intents track each payment from creation through confirmation to completion. Order-owned payment legs use /v1/orders/{order_id}/payment-intents, where Flint validates the leg against the order's live outstanding balance. Standalone payment intents use /v1/payment-intents with an explicit amount_money.
A payment intent moves through statuses like requires_payment_method, requires_confirmation, requires_action, processing, and requires_capture before reaching a terminal state of succeeded, canceled, or expired. Standalone intents are confirmed through the payment-intent API. You can update their amount before attaching a payment source or starting the first confirmation attempt. After that, create a new payment intent to collect a different amount. If an amount update is still in progress, retry that update with the same idempotency key before confirming. Order-owned legs are created, confirmed, captured, and canceled only through order routes. Their amounts are immutable: if tax, tip, discounts, or line items change after an explicit leg is staged, cancel and recreate that leg. An order can carry multiple payment intents for split payment, and /v1/orders/{order_id}/pay validates the selected legs against the current outstanding balance before starting an attempt.
Each /v1/orders/{order_id}/pay call runs inside a payment attempt, the resource you inspect and resume when a payment does not complete in one call. The attempt carries a per-leg summary (including last_payment_error for a failed leg) and an is_resumable flag: true means finish the pending action and resume with action: "resume" and order_payment_attempt_id; false means the attempt cannot be resumed, which is not the same as finished: a finalizing attempt is not resumable and has usually charged the buyer already, so read status before starting new work. The open attempt is exposed as active_payment_attempt on order detail, and on checkout-session detail read with the session's own credential, so a lost response can be recovered without double-charging, and past attempts are readable through GET /v1/orders/{order_id}/payment-attempts. See Declines and payment attempts.
A succeeded payment carries processing_fee_money, Flint's all-in fee to process it. It is the complete processing price rather than a provider cost passed through, so your net is captured_money minus that fee. The fee is final at card capture or ACH success, and payments that are canceled or fail before success have none. Refunds do not return or revise it. See Processing fees.
If you are building browser checkout, start with the Embedded payments guide. For how payments relate to orders, see the Orders-first guide.
POST /v1/orders/{order_id}/pay requires an action. Each action accepts only its own fields:
| Action | Required fields | Optional fields |
|---|---|---|
pay | None beyond action | payment_source, save_payment_method |
confirm_payment_intents | Non-empty payment_intents | completion_behavior: complete_order or partial_payment; save_payment_method |
setup | setup_payment_source containing a newly collected token | None |
resume | order_payment_attempt_id | None |
All four actions also accept expected_outstanding_money and buyer_contact. A payment start records buyer_contact on the order; with a checkout session credential, omitted email and phone fields use the session's saved contact. pay collects the full outstanding balance; omit payment_source only when that balance is zero. setup saves a credential on a zero-balance order. save_payment_method: true saves the card the buyer typed once the payment succeeds, with usage: "on_session". It needs the checkout session's own credential, a session whose save_payment_method_offered is true and that acts for a customer, and one confirmation_token created with setupFutureUsage: "on_session"; see Offer to save the card. A session created for no customer acts for one after the buyer confirms their email with a code; until then the save returns SAVE_PAYMENT_METHOD_VERIFICATION_REQUIRED. To continue an open attempt after a pending client action, send action: "resume" with a new Idempotency-Key. Replaying the start request with its own key returns that request's stored response if it completed, or recovers the same attempt if it was interrupted. It never starts a second attempt.
{
"action": "pay",
"payment_source": {"confirmation_token": "ctoken_1kmn0aExample"},
"expected_outstanding_money": {"amount": 2500, "currency": "USD"}
}