Processing Fees

Flint charges one fee to process a payment: the processing fee. It is the complete price for the payment itself, calculated by the one rule that prices that payment. It is not a processor's cost with a Flint margin stacked on top, so there is no second fee to look up, reconcile, or subtract on a payment that succeeds.

Some later events cost separately. A dispute, an ACH return, a failed ACH payment, and instant bank verification each carry an event fee charged to your merchant account rather than deducted from the payment.

Two fields carry it. processing_fee_money on the payment is the non-negative fee for that payment once it is final. A payment priced at zero reports zero. fee_money on the corresponding balance transaction is the same fee as it hits your balance, carried as a negative number because it reduces the balance.

What You Net#

Cards, wallets, and Affirm are priced as a percentage plus a fixed amount, always in the payment's own currency:

processing fee = captured_money * rate percentage + fixed amount
net            = captured_money - processing_fee_money

The percentage applies to the amount you actually captured or collected, and the fixed amount applies once per payment, never once per capture or per line item.

Two things change that arithmetic. Both are reflected in the rates listed on the Payments tab in dashboard settings, so do not assume the single-rate formula holds:

• ACH debit is a percentage bounded by a minimum and a maximum fee, with no fixed amount. The bounds are $1.00 and $700.00 on every published plan. A $20.00 ACH payment costs $1.00 rather than the percentage, and a very large one stops climbing at $700.00.
• Card payments can add conditional percentage components. Manual card entry, an international card, and currency conversion each add to the base rate when they apply, and more than one can apply to the same payment. Apple Pay and Google Pay are priced without these additions.

curl https://api.withflintpay.com/v1/payment-intents/pi_1kmn0aExample \
  -H "Authorization: Bearer YOUR_API_KEY"

{
  "data": {
    "payment_intent_id": "pi_1kmn0aExample",
    "status": "succeeded",
    "amount_money": { "amount": 5000, "currency": "USD" },
    "captured_money": { "amount": 5000, "currency": "USD" },
    "processing_fee_money": { "amount": 175, "currency": "USD" }
  }
}

That payment collected $50.00 and cost $1.75 to process, so you netted $48.25. Read the fee from the payment rather than recomputing it from your rates: it is the amount actually charged, already rounded half-up to the minor unit, and it reflects the pricing that was locked in when the payment was processed. Your own rates are on the Payments tab in dashboard settings, and published plan rates are on the Flint pricing page.

processing_fee_money is absent until the fee is final, so treat a missing field as "not charged yet" rather than as a zero fee. A deliberate zero is possible if your rates price a payment at zero, and it comes back as an explicit {"amount": 0}.

A paid payment also carries processing_fee_application, a breakdown of the percentage, fixed amount, rounding, and any minimum or maximum fee that produced the amount. It is deprecated. Build on processing_fee_money on the payment and fee_money on the balance transaction; those are the amounts Flint actually charged.

When the Fee Becomes Final#

The fee is decided before Flint contacts the processor and becomes final at exactly one moment per payment method:

• Card payments: at capture. With automatic capture that is when the payment succeeds. With manual capture it is when you capture, and the percentage applies to the amount you actually captured, so a partial capture is charged on the partial amount.
• ACH debit: when the payment succeeds. ACH takes days to clear, so processing_fee_money is not final on the day you confirm. See ACH Debit Payments.

Payments that never reach that moment are never charged. An authorization you let expire, a payment you cancel before capture, and a card that declines all have no final processing fee.

When Pricing Rejects a Payment#

Flint prices a payment before it reaches the processor, and it never falls back to a nearby rate or quietly drops the fee to zero. If no authorized price covers the payment, the request fails and nothing is submitted:

• PROCESSING_FEE_PRICING_NOT_AUTHORIZED (400) means no authorized price covers this payment. Your account may have no approved price for its payment option, its currency, or the way it was started (a direct API call, hosted checkout, a payment link, a subscription, or the virtual terminal). Or the amount may fall outside what your price covers: below the smallest payment your rates allow, or too small to carry its own fee. Retrying the same request will not succeed until the account's pricing changes.
• PROCESSING_FEE_PRICING_UNAVAILABLE (503) means Flint could not resolve pricing right now. Retry the same logical request with the same idempotency key.

The Payments tab in dashboard settings lists the payment options and currencies your rates cover, and the smallest payment amount they price. If the option or amount you need is missing, ask the account owner to have the account's pricing changed. No retry succeeds until it is.

The trap worth planning for is a small partial capture. The price applies to the amount you actually capture, so authorizing $50.00 and then capturing $0.40 can be rejected at capture, with the authorization already placed. If you capture variable amounts, compare the amount against the minimum on your rates first, and cancel the authorization instead of capturing below it.

The same check runs at confirmation, so a payment your pricing does not cover is rejected before the buyer is charged.

Refunds Do Not Return the Fee#

Refunding a payment returns the buyer's money. It does not return or recalculate the processing fee Flint already charged on the original payment, and it does not add a new one.

A $50.00 payment that cost $1.75 to process and is then fully refunded leaves you at negative $1.75 on that order: you are out the fee, not the principal. Partial refunds work the same way, with the original fee untouched.

Disputes and ACH failures do not revise the original payment's processing fee either. They create separate event fees instead. Refunds have no event fee.

Event Fees#

An event fee is charged for something that happens after or instead of a successful payment. It never revises the processing fee on the original payment, and it is charged to your merchant account rather than deducted from a balance transaction. Four events carry one, at these default amounts:

Two of these behave in ways worth planning for:

• An ACH return is not a failed ACH payment. A payment the bank rejects before it settles is the $4.00 case. A payment that succeeds and is pulled back later arrives as a dispute and is the $15.00 case. An ACH payment that fails before Flint submits it to the bank carries no event fee at all.
• A card dispute is capped, and the cap is a rejection boundary rather than a ceiling on what you pay. Your offer authorizes a maximum, $50.00 by default. A dispute whose network cost exceeds that maximum is not charged down to it. Flint declines to assess the fee at all and absorbs the cost, so you are charged either the exact network cost or nothing.

Read your own event fee amounts on the Payments tab in dashboard settings. Event fees flow into your Flint billing balance; use the merchant_billing_itemized_v1 report for entry-by-entry history.

Reading Fees on Your Balance#

Every payment that moves your balance produces a balance transaction, and it carries the same fee as a signed amount:

• amount_money: the gross movement.
• fee_money: the Flint fee on that movement, negative because it reduces your balance.
• net_money: the actual effect on your balance.

Because fee_money is already signed, the three add up rather than subtract:

net_money = amount_money + fee_money
5000 gross + (-175) fee = 4825 net

That is the same $1.75 the payment reports as processing_fee_money, with the sign flipped to match the direction of the movement. Only payment transactions carry a fee here: refund, dispute, return, and standard payout transactions all report fee_money of 0.

A zero there does not mean the event was free. Event fees are charged to your merchant account and never appear as fee_money on this ledger, so a period that ties out on balance transactions alone will still understate what a disputed or returned payment cost you. Reconcile them through Flint billing.

Sum net_money over a period to get what actually reached your balance. Do not subtract fee_money from net_money: it is already accounted for, and subtracting a negative would add the fee back instead of removing it. See Money & Currency and the Money Movement API Reference.

What This Fee Is Not#

• Not a processor passthrough. Flint never exposes a separate processor or network cost as a deduction from your payment. What Flint pays its providers is Flint's cost, not a line on your payment.
• Not the buyer-facing charges you set. Delivery, service, and convenience charges you add to an order increase what the buyer pays and are part of the payment amount. They are not processing fees. See Tips & Fees.
• Not a subscription's plan fees. setup_fee_money and early_termination_fee_money on a subscription plan are prices you charge your customer. See Subscription Billing.

For the fee on every payment over a period as a downloadable CSV, see Reports.