From Authorization to Deposit: Where the Money Goes and Why It Takes Time

A payment gets approved in seconds. The money shows up later. Here is what happens in between, and why merchants ask your support team about it.

A merchant runs a customer’s card on Friday afternoon. The screen says Approved. On Monday morning they open their bank account expecting the money, and either it is not there yet or the deposit is a different number from the sales they rang up. They do not call the processor. They call the company whose software they use every day.

For a vertical software company whose customers take payments inside the product, that call is predictable. The merchant sees one moment, the approval, and one outcome, the deposit. Everything in between is invisible to them, and most of the confusion about “missing” money lives in that gap.

This piece walks through what actually happens between a card being approved and funds landing in a merchant’s bank account, why each step takes the time it does, and what your product can do so the gap stops generating support tickets.

Approved is not paid

An approval means the cardholder’s bank has agreed the transaction can go ahead and has set the amount aside on the cardholder’s account. That is all. No money has moved yet. The merchant has a promise, not a payment.

That distinction explains a surprising number of merchant questions. A customer sees a pending charge on their card that the merchant believes was canceled. A merchant sees an approved transaction in the software but nothing in the bank. Both are describing an authorization that has not yet become a settled payment, and both make sense once the stages are laid out in order.

The five stages, in order

The details vary by network, processor, and payment type, but card payments follow the same basic sequence.

1. The merchant’s system sends the card details and amount through the gateway to the card network, which routes the request to the cardholder’s bank. The bank checks available funds and risk, then approves or declines. A decline here is the signal covered in our guide to reading decline codes.
2. The merchant confirms the final amount it intends to collect. For a retail sale, authorization and capture usually happen together. For a service visit, a booking, or a tab, the merchant may authorize first and capture later, once the job is done or the tip is added.
3. Captured transactions are grouped into a batch, usually at the end of the business day. Closing the batch is what submits the day’s transactions for payment. Until the batch closes, nothing moves forward.
4. Clearing and settlement. The network passes transaction details to each cardholder’s bank, works out what each party owes, and moves funds from the issuing banks to the acquirer. This is where interchange and network fees are applied.
5. The acquirer or payment facilitator deposits the merchant’s share into the merchant’s bank account, typically by bank transfer. This is the moment the merchant actually sees money.

For a closer look at the authorization side and the infrastructure that carries it, our payment gateway explainer covers it in more depth.

Why it takes time

Merchants often assume a delay means something has gone wrong. Usually it means one of these ordinary features of the chain is doing its job.

• Batch cutoffs. A transaction captured after the day’s cutoff joins the next batch, so it starts its journey a day later than the merchant expects.
• Weekends and bank holidays. Card authorizations run around the clock, but bank transfers run on banking days. A Friday evening sale followed by a Monday holiday can stretch the wait noticeably.
• Network settlement cycles. Each network settles on its own schedule, and funds pass through several institutions before they reach the acquirer.
• The bank transfer itself. Funding travels on banking rails, which have their own processing windows. Bank-to-bank payments behave differently from cards again, which is part of why the choice between ACH and card payments
• New merchant review. First deposits and newly onboarded merchants often go through extra review, and unusual volume can trigger a temporary hold. That is risk management working as intended, but it feels like a delay to a merchant who was never told to expect it.

None of these are failures. They become problems only when the merchant does not know they exist.

Why the deposit does not match the sales total

The second most common call is not about when the money arrives but about how much. A merchant adds up the day’s sales, compares the total to the deposit, and the numbers differ. Usually the gap is the difference between gross and net.

• Processing fees. Depending on the pricing model, fees are either deducted from each deposit or billed separately at month end. Our comparison of interchange plus and flat rate pricing explains why the line items look the way they do.
• Refunds issued during the period are netted out of the deposit.
• A dispute pulls funds back, often out of the next deposit, which is one more reason chargebacks catch merchants off guard.
• Reserves or holds. A portion of funds may be held for a period, especially for higher-risk activity or new accounts.
• A single deposit can include more than one batch, or leave out a batch that closed after the cutoff.

Every one of these has a clear explanation. The trouble is that the merchant usually sees a single number on a bank statement with none of that detail attached.

Where it breaks

Most funding problems trace back to a handful of operational mistakes, and many of them sit inside the software rather than the payments stack.

• The authorization expires before capture. Authorizations do not last forever. If a service business authorizes at booking and captures weeks later, the original approval may have lapsed, and capturing against it invites a decline or a dispute.
• The batch never closes. If closing depends on someone pressing a button, a busy day can leave transactions sitting unsubmitted.
• Tips and adjusted amounts. When the final amount differs from the authorized amount, the adjustment has to follow the rules for that transaction type.
• Void versus refund. Canceling before the batch closes is a void, and the charge never settles. Canceling after is a refund, which settles as a charge and then reverses. Merchants who mix up the two end up promising customers the wrong thing.
• Recurring charges on stale cards. A scheduled charge on an expired card never makes it as far as funding, the failed payment problem covered in our recurring billing guide.

What your software can do about it

Most of the fixes are product decisions, and a software company can make them whatever its payments setup looks like today.

• Show each transaction’s real status. Authorized, captured, settled, and funded are different states. A single “paid” label hides exactly the gap merchants are asking about.
• Tie deposits back to transactions. A deposit view that lists the batches, sales, refunds, fees, and adjustments behind each bank deposit answers the “why is this number different” call before it happens.
• Make the batch cutoff visible. Showing when the next batch closes, and closing it automatically, removes a whole category of late funding.
• Set expectations at onboarding. A short explanation of deposit timing, first deposit review, and how fees appear does more than any support script.
• Warn before authorizations lapse. For businesses that authorize ahead of the work, a prompt to capture or reauthorize prevents avoidable declines, and it matters most for anything that bills on a schedule through a recurring billing setup.

These are the same principles behind embedded payments generally. When payments live inside the product, the product owns the explanation as well as the transaction.

What to ask a payments partner about funding

When the conversation turns to the payments stack, four questions show whether a partner will make this easier or harder.

1. How do deposits map back to individual transactions? If reconciliation takes a spreadsheet and a support ticket, merchants will keep calling.
2. Can batch close be automated and scheduled? Manual closeouts are the most preventable cause of late funding.
3. How are fees shown? Whether fees are netted from deposits or billed separately, merchants should be able to see them clearly in reporting.
4. Where do merchants see funding status? Inside your product, through an API you can surface, or in a separate portal the merchant has never logged into.

The gap is part of the product

The time between “Approved” and a bank deposit will never be zero. What a software company controls is whether its merchants understand that gap or are surprised by it. That understanding is built inside the product, in how statuses are labeled, how deposits are explained, and what merchants are told on day one, and it pays off across every merchant on the platform.

CSIPay is the embedded payments platform built for Constellation Software and Jonas operating companies, covering the US and Canada on PCI DSS Level 1 infrastructure with a 99.9% uptime SLA, 4,000+ merchants, and $40M+ distributed to partners. If your merchants are asking where their money is, talk to our team.