---
title: "Payment processor holding funds on a large invoice"
description: "A processor holding funds on a large invoice is running a risk review. Why Stripe and PayPal hold big payments, how rolling reserves work, how to avoid it."
url: "/blog/processor-froze-funds-mid-project/"
date: "2026-07-15"
updated: "2026-09-29"
author: "Valeria Vahorovska"
tags: ["Guides","Trust & Safety"]
---

Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “Payment processor holding funds on a large invoice”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks.

# Payment processor holding funds on a large invoice

A payment processor holding funds on a large invoice is running an automated risk review, not judging your business. A payment far above your usual size looks like stolen-card fraud to the model, so it holds the money and asks for proof. The fix is structural: stage payments, bank rails for big balances, a current profile.

The distress is real and it repeats across every operator community: *"PayPal keep stopping my withdrawals."* A processor that *"flagged the second payment as fraudulent and withheld it"* — the second stage payment of a project, money already earned and already spent. A three-year-old thread asking *"how do you collect large invoices without getting funds frozen?"* still gets replies, because most stacks never built the answer in. This guide covers the large one-off invoice specifically. For account freezes in general, start with [7 reasons fintechs freeze accounts](/blog/7-reasons-fintechs-freeze-accounts/).

## Why a large invoice trips the risk engine

A large invoice trips the risk engine because risk models score deviation, and a big project payment deviates on every axis at once. Stripe's reserve policy lists *"an unexplainable sharp increase in processing volume"* as a reason to place a reserve ([Stripe support](https://support.stripe.com/questions/reserves-frequently-asked-questions)). PayPal's merchant guide names a change in your average selling price.

- **Size against your history.** An account that averages $400 payments suddenly takes $9,000. That jump is the loudest fraud signal there is, because most stolen-card schemes look exactly like it.
- **Card-not-present, high-dispute category.** A remote card payment for services or custom project work inherits the whole category's dispute risk.
- **The processor holds the loss.** If that $9,000 was a stolen card, the chargeback lands on the processor after it has paid you out. Holding funds while the risk expires protects its balance sheet with your working capital.

There is also an incentive problem: the processor [earns on funds while they clear](/blog/fynex-vs-stripe/), so "hold when unsure" is the comfortable default.

## Hold, reserve or freeze: what the processor is actually doing

A processor has five tools, and each keeps your money for a different length of time. Knowing which one you're under tells you how long to plan around. PayPal's 2024 merchant guidance says funds are [usually held for up to 21 days](https://www.paypal.com/us/brc/article/funds-availability). Reserves run longer.

| What you see | What's held | How long | Typical trigger |
|---|---|---|---|
| **Payment hold** | One payment | Days to weeks | Payment far above your usual size |
| **Rolling reserve** | A % of every payment | A rolling window, often months | Rising volume, higher-risk category |
| **Fixed reserve** | A set dollar amount | Until the processor reviews it | New account, elevated disputes |
| **Payout pause** | Your whole balance | Until the review closes | Information request outstanding |
| **Account closure** | Balance, released later | Until chargeback windows expire | Review fails or AML trigger |

In its 2024 guide to rolling reserves, Stripe says the processor usually withholds [5% to 15% of each transaction for a rolling period, such as 180 days](https://stripe.com/resources/more/rolling-reserves-101-what-they-are-why-they-matter). The same guide ties reserve length to card-network chargeback time frames, which it says range from 45 to 120 days. That is why [held funds](/glossary/held-funds/) on a big invoice rarely come back in a week.

## A worked example: the $9,000 invoice

Here is how one large invoice turns into a cash gap. Say your agency usually takes $400 card payments. A client pays a $9,000 project invoice by card on day one. The processor holds it for review, then releases it under a 10% rolling reserve over 90 days.

1. **Day 1:** $9,000 lands. Available to you: $0.
2. **Day 12:** the review clears after you send the contract and delivery proof. Available: $8,100. Held in reserve: $900.
3. **Day 15:** payroll and four freelancer payouts, $7,600 in total, are due from the same balance. They clear, just.
4. **Day 102:** the $900 reserve is released.

Now split the same project into three $3,000 stage payments, and take the final one by bank transfer. No single card payment sits far outside your pattern. The engine sees a business billing normally, and payroll never waits on a reviewer. The processing fee is a separate cost of size; [what a $45k invoice costs to process](/blog/what-a-45k-invoice-costs-to-process/) runs those numbers.

## What happens during the review, and why support can't say

During the review, three things run at once: an information request, a model re-scoring your account, and sometimes an anti-money-laundering check. The request asks for invoices, contracts, proof of delivery and sometimes your client's identity. The model decides whether your account profile still fits.

The AML part explains the copy-paste replies. In an AML review, telling you the details can itself be an offence, known as "tipping off". The silence is statute, not rudeness.

Outcomes run from full release, to a rolling reserve on every future payout, to account closure with the funds following later. The step-by-step response lives in [the rescue playbook](/blog/fintech-froze-my-funds-what-to-do/). The short version:

1. Answer the information request completely and **once**. Partial answers restart the queue.
2. Reroute new collections to a different rail immediately.
3. Check what else the held balance was due to fund, and fund it elsewhere today.

## How to take large payments without tripping a hold

You avoid a hold on a large invoice by making the payment look normal to the model and keeping it off the card rail. These five moves do that, in order of impact.

1. **Shrink the outlier.** [Deposits and stage payments](/blog/deposits-and-stage-payments/) fix your risk profile as well as your cash flow. Three $3,000 payments read as a business pattern; one $9,000 lump reads as an anomaly.
2. **Match the rail to the amount.** Cards suit card-sized payments. For big balances, use bank rails, [which trip different machinery, with different fixes](/blog/bank-blocked-customer-payment/), or a payment link that offers bank transfer next to card.
3. **Keep the profile current.** Processors score payments against the business they think you are. An account opened for $50 bookings that now bills $15,000 projects is the flag. Update the profile.
4. **Warn before it lands.** Where the platform allows it, flag a large incoming payment in advance.
5. **Never one provider for everything.** [The two-account rule](/blog/the-two-account-rule/) — an operating layer that routes and a chartered bank that vaults — means a review costs you patience, not wages.

Freelancers face a sharper version; [payment platforms for freelancers who can't afford a freeze](/blog/freelance-payment-platforms-freezes/) covers that case.

## Where Fynex sits in this

Fynex is the layer that makes this structure automatic, so the business runs even while one processor reviews a payment. Collections run across **multiple rails**: card links for small amounts, bank rails for large ones, so no single provider's risk engine sees your whole flow. Stage-payment billing keeps every payment inside a normal pattern.

Your [cash position](/features/cash/) spans every account and processor, so a hold in one shows its blast radius at once. And Fynex keeps client funds **safeguarded by default** with Fondy Ltd, an FCA-authorised e-money institution (FRN 900705). A review means a named human and an appeal path, [not a black box](/blog/where-your-money-sits/). For agencies billing project fees and paying freelancers from them, see how Fynex runs [project margin and freelancer payouts for agencies](/agencies/).

Related: [why banks freeze business accounts](/blog/why-banks-freeze-business-accounts/) covers the bank-side trigger list. [Fintech with real support](/blog/fintech-with-real-support/) is worth checking before you need an appeal path, not during one. If the delay is on the payout side, [why is my Stripe payout delayed](/blog/why-is-my-stripe-payout-delayed/) has the timing version.

A hold on a large invoice feels like an accusation. It's a model seeing an outlier. Stop being an outlier — smaller payments, the right rails, a current profile, nothing concentrated — and the engine goes back to ignoring you.