Funding and disbursement
While interbank settlement transfers capital between issuing and acquiring banks, funding is the subsequent disbursement of settled balances from the payment processor or acquirer into the merchant's commercial bank account.
Because the rules governing funding schedules and withholdings originate from private merchant service agreements rather than universal card scheme regulations, diagnosing missing deposits requires analyzing provider contracts.
Commercial nature of funding schedules
Card networks enforce strict timelines for interbank clearing, but they have zero authority over when an acquiring processor disburses capital to a merchant. When payouts are delayed, escalating to Visa or Mastercard achieves nothing: the card network has already settled the funds with the acquirer. Payout frequencies, reserve withholdings, and fund releases are governed strictly by the merchant agreement.
Merchants negotiate funding terms based on operating history, trading volume, and underwriting risk profile:
- T+1 funding: Funds deposit into the merchant operating account one banking day following batch close.
- T+2 or T+3 funding: Standard payout cycles for typical e-commerce and retail merchants.
- Weekly or monthly payouts: Common schedules for international cross-border merchants or higher-risk business models.
Gross funding versus net funding
Payment processors disburse capital under two primary accounting methodologies:
| Funding model | Disbursement calculation | Fee collection mechanics | Accounting reconciliation impact |
|---|---|---|---|
| Net funding | Gross sales minus refunds, chargebacks, and processing fees | Processing fees are withheld automatically from daily batches | Deposit amounts vary dynamically from order totals, requiring fee reports to reconcile |
| Gross funding | Gross sales minus refunds and chargebacks | Processing fees are invoiced and debited separately at month-end | Daily deposits align directly with gross batch capture totals |
Net funding represents the default model among modern Payment Service Providers (PSPs) and payment facilitators. Because merchant discount fees, assessment charges, and refunds are netted out prior to disbursement, daily bank deposits never equal gross sales totals. Understanding whether an account operates on gross or net funding is essential before setting up automated financial reconciliation.
Risk management: holds and reserves
Acquiring banks carry statutory liability for merchant chargeback obligations. To hedge against potential merchant insolvency, acquirers utilize three risk management mechanisms:
- A rolling reserve withholds a fixed percentage (commonly 5% to 10%) of daily gross processing volume for a designated window (typically 90 to 180 days) before releasing it. In steady-state operation, capital releases continuously from historical tranches while new deductions occur, creating a permanent liquidity buffer.
- A fixed reserve (or static reserve) requires the merchant to deposit an upfront lump sum or withholds 100% of processing volume until a specified target capital threshold is reached, maintaining that balance until the contract terminates.
- A funding hold represents an immediate, complete suspension of merchant payouts. Payout freezes are triggered by algorithmic risk monitors following sudden volume spikes, elevated chargeback ratios, unusual refund frequencies, or changes in merchant business profiles.
Reserve terms reflect an acquirer's assessment of delivery horizon and fulfillment risk. Businesses with extended delivery windows (such as airlines, event ticketing, and custom manufacturing) or recurring subscription billing face substantially higher reserve requirements.
Marketplace disbursements and payout flows
In platform business models—such as multi-vendor marketplaces, ride-sharing services, and on-demand delivery apps—collecting revenue from buyers and disbursing proceeds to third-party sellers requires specialized payout architecture:
Designing compliant marketplace disbursements requires answering four architectural questions:
- Who is designated as the merchant of record? The legal entity serving as Merchant of Record holds statutory liability for customer refunds, sales tax compliance, and chargebacks.
- Where does custodial holding occur? If customer payments land in a bank account owned by the marketplace platform before being re-distributed to sellers, the platform is legally holding third-party client money, triggering Money Transmitter Licensing (MTL) and statutory safeguarding requirements. Utilizing split settlement via a licensed payment facilitator prevents platform accounts from taking direct custody of seller balances.
- How are dispute deficits recovered? If a cardholder initiates a chargeback weeks after the marketplace disbursed proceeds to the seller, the platform must establish contractual mechanisms to debit the seller's future earnings or draw from a seller reserve.
- Which rails execute the disbursement? Selecting payout rails involves trade-offs among settlement speed, cost, and finality:
- Automated Clearing House (ACH): Low cost per transaction, but takes 1–3 business days to settle and exposes the platform to delayed ACH returns.
- Real-time push rails (Push-to-Card via Visa Direct/Mastercard Send, or FedNow / RTP): Instant funds availability 24/7/365 with irreversible settlement finality, but commands higher per-transaction processing fees.
Auditing funding settlement reports
Verify four essential reconciliation metrics when analyzing processor settlement reports.
- Confirm the specific batch identifier, transaction date range, and cut-off window represented by the disbursement.
- Identify gross sales volume and review the exact fee deductions itemized by interchange, assessments, and processor markup.
- Verify rolling reserve allocations, calculating withholdings against contractual percentage thresholds and noting release maturity dates.
- Audit historical adjustments, verifying that chargeback debits, refund deductions, and dispute administration fees tie to specific original transaction IDs.
Terms introduced
- Disbursement: paying third parties out of funds you collected.
- Funding: the provider paying the merchant. Not the same as settlement.
- Funding hold: a temporary stop on one payout.
- Merchant of record: the party responsible for the sale and its disputes.
- Net funding: fees deducted before the deposit arrives.
- Reserve: funds an acquirer withholds against future chargeback risk.
How providers do it
Funding schedules and settlement models are governed by commercial merchant contracts rather than network scheme rules. As a result, the parameters below reflect standard provider capabilities and contractual configurations rather than statutory payment laws.
The fundamental operational distinction between these providers lies in their funding architecture: whether funds are disbursed gross (with processing fees invoiced or debited separately) or net (with interchange, scheme fees, and processor margins deducted prior to payout).
| Provider | Funding model | What the schedule is set by | Status |
|---|---|---|---|
| Stripe | Net settlement; processor and card fees deducted per transaction rather than per batch | Account dashboard settings, customizable and subject to underwriting negotiation | unconfirmed per contract |
| Stripe Connect | Internal balance transfers to seller accounts, followed by automated or manual payout sweeps | Programmatic delay_days configuration set per connected account | confirmed |
| Adyen | Direct acquiring settlement; supports gross settlement configurations with separate fee sweeps | Configured per merchant account in the customer management portal | unconfirmed |
| Payrix | Automated disbursement splits to embedded sub-merchants | Commercial contract terms and platform engagement tier | unconfirmed |
| Global Payments | Traditional acquiring structure; typically gross settlement with monthly fee debits | Merchant acquiring processing agreement | unconfirmed |
| Square | Net settlement by default; optional instant payouts available for an additional percentage fee | Square automated payout schedule (next-business-day standard) | unconfirmed |
An organization operating on gross funding with one processor and net funding with another must build two completely different automated reconciliation pipelines:
- A gross deposit matches the exact sales total from a terminal or e-commerce batch settlement file, simplifying financial auditing.
- A net deposit arrives as a blended figure that cannot be tied back to sales ledgers until transaction-level fee files are parsed and credited back to revenue accounts.
- Stripe
- Stripe Connect
- Adyen
- Payrix
- Global Payments
- Square
What they are: the PSP, so funding is Stripe paying the merchant rather than a bank settling to it. Stripe sets the schedule, and the merchant negotiates it.
Stripe funds net, and does it per transaction rather than per batch. Each charge produces a balance transaction carrying the gross amount, the fee, and the net, and payouts sweep the available balance on a schedule. So the deposit ties back to a list of balance transactions and to nothing else.
| Standard term | Their term | Status |
|---|---|---|
| Deposit | Payout | confirmed |
| The ledger line behind a deposit | Balance transaction | confirmed |
| Money not yet payable | Pending balance | confirmed |
| Chargeback debit in a deposit | Dispute, as a balance transaction of its own | confirmed |
| Question | Answer | Status |
|---|---|---|
| What is the payout schedule? | Set per account, and negotiable | unconfirmed; read the account rather than assuming the default |
| Is a reserve held? | unconfirmed | |
| Are fees deducted per charge or invoiced monthly? | Deducted per charge by default | unconfirmed per contract |
Where to look
The balance report reconciles a payout to the transactions inside it. Start there rather than in the payments list, because the payments list has no idea what was deducted.
Last verified: never.
What they are: the mechanism a platform pays sellers with, and the reason the four questions on this page have to be answered before any code is written.
The charge type answers the first two. On a direct charge the money never touches the platform's balance, so the platform is not holding anyone else's funds. On a destination charge or a separate transfer it lands with the platform first and moves on from there, which is a different regulatory position in most countries.
| Standard term | Their term | Status |
|---|---|---|
| Paying a seller | Transfer to the connected account, then a payout from that account to its bank | confirmed |
| Clawing a payment back | Transfer reversal | confirmed |
| Seller's payout delay | delays_days on the connected account | confirmed |
| Seller owing the platform money | Negative balance on the connected account | confirmed |
| Question | Answer | Status |
|---|---|---|
| A chargeback lands after the seller has been paid. Who is out of pocket? | On direct charges, the connected account. On destination charges and separate transfers, the platform balance is debited and recovery means reversing the transfer | confirmed |
| What if the seller's balance is empty by then? | The reversal fails and the loss sits with the platform. Stripe will only debit the seller's bank account where debit_negative_balances is set | confirmed |
| Which product line uses which charge type? | unconfirmed | |
Is delays_days set per seller by risk? | unconfirmed |
The empty-balance case is the one to design for. A seller who takes the money, withdraws it, and stops trading leaves the chargeback with the platform, and no API call reaches money that has left Stripe. Holding a payout longer for a new seller is the only lever that works before the fact.
Last verified: 2026-09-09 against Stripe's public Connect documentation.
What they are: the acquirer, so what reaches the merchant is a settlement rather than a PSP passing money on. Fewer parties, and the same contract questions.
| Standard term | Their term | Status |
|---|---|---|
| Funding report | Settlement details report | confirmed |
| Deposit | Payout, per merchant account and currency | unconfirmed |
| Money held back | Deposit, or reserve, depending on the arrangement | unconfirmed |
| Question | Answer | Status |
|---|---|---|
| What is the payout frequency? | Set per merchant account | unconfirmed; read the contract |
| Gross or net funding? | unconfirmed | |
| Does a refund return the original processing fee? | unconfirmed; this is contract-dependent and worth asking in writing | |
| How are chargebacks presented in the report? | unconfirmed |
Where to look
The settlement details report in the Customer Area, per merchant account. Reconcile against it rather than against the payments list, since the payments list shows no deductions.
Last verified: 2026-09-09 against Adyen's public documentation.
What they are: the party that actually moves money to sub-merchants, which makes the disbursement half of this page their product rather than something a platform builds.
| Standard term | Their term | Status |
|---|---|---|
| Paying a sub-merchant | Disbursement | confirmed |
| The platform's cut of a sale | Fee, configured by the partner | confirmed |
| Sub-merchant | Merchant, onboarded under a partner | confirmed |
| Question | Answer | Status |
|---|---|---|
| Are funds split at settlement or paid out afterwards? | unconfirmed; this decides whether the platform ever holds other people's money | |
| Who is the merchant of record on a sub-merchant sale? | unconfirmed | |
| A chargeback lands after the sub-merchant has been disbursed. Who absorbs it? | unconfirmed; the engagement model decides it, and it is the single most expensive question here | |
| Which rails carry a disbursement, and how fast? | unconfirmed | |
| Can a platform hold a disbursement itself, or only ask them to? | unconfirmed |
Every row above is unanswered on purpose. The PayFac-as-a-service model puts the risk decision with Worldpay, and the contract rather than the API is where these answers live. Get them from the contract before quoting any of them to a seller.
Last verified: never.
What they are: the acquirer, and usually on traditional acquiring terms.
| Question | Answer | Status |
|---|---|---|
| Gross or net funding? | unconfirmed; traditional acquiring is usually gross, with fees invoiced monthly, and that is the arrangement the core page says ties to batch totals | |
| What is the funding schedule? | unconfirmed | |
| Is a reserve held? | unconfirmed | |
| Which reports reconcile a deposit to a batch? | unconfirmed; the answer differs per platform |
Gross funding here alongside net funding at a PSP makes two reconciliations rather than one, and they should not share a runbook. One deposit ties to a batch total. The other ties to nothing until you subtract the fees.
Last verified: never.
What they are: the facilitator, so a seller's deposit is Square paying a sub-merchant out of the master account. Nothing about it is a network schedule.
| Question | Answer | Status |
|---|---|---|
| What is the standard deposit schedule? | unconfirmed | |
| Is faster funding available, and at what price? | Offered as a paid option | unconfirmed per contract |
| Gross or net funding? | Net. Fees come out before the deposit | unconfirmed per contract |
| What triggers a deposit hold? | unconfirmed; a risk review is the usual reason, and the seller is told little | |
| How is a hold appealed? | unconfirmed |
A held deposit is the failure mode that matters here. The seller has no acquirer of its own to escalate to, so the appeal path is Square's support queue and nothing else. Any business running on Square needs enough working capital to survive one.
Last verified: never.