How Merchants Get Paid After Card Transactions

When a customer taps a card, inserts a chip, swipes, enters card details online, or pays through a digital wallet, the checkout may display Approved almost immediately. That approval is important, but it usually does not mean the merchant already has the customer’s money in its bank account.

So, how do merchants get paid? In a typical card transaction, the payment is authorized first, then captured, submitted for processing, cleared through the appropriate card network, settled between participating financial institutions, and finally funded to the merchant’s designated bank account. 

The exact path depends on the payment processor, acquiring relationship, card network, merchant agreement, transaction type, payment-facilitator structure, and funding schedule.

Understanding those stages helps explain why a $100 approved sale may not appear as a $100 deposit that same day. It also explains why deposits may include multiple transactions, why processing fees or refunds can change the amount received, and why weekends, cutoffs, reserves, disputes, or account reviews can delay merchant funding.

The card-payment ecosystem includes several participants. Depending on the setup, those may include the customer, merchant, point-of-sale system, payment gateway, payment processor, acquiring bank, card network, issuing bank, merchant account or payment facilitator, and the merchant’s business bank.

Some modern payment providers combine several of those functions behind one interface. The merchant may therefore interact with only one company even though several institutions and systems participate behind the scenes.

For additional background on the full transaction lifecycle, see this guide to how credit card processing works.

How Merchants Get Paid After Card Transactions: The Complete Journey

A card transaction has two broad parts. The first is the fast exchange of messages that determines whether the transaction can proceed. The second is the financial processing that ultimately moves value through the payment system and results in merchant funding.

A typical transaction follows these stages:

1. Payment initiation: The customer presents a card or card-backed digital credential.
2. Payment authorization: The issuing bank decides whether to approve the request.
3. Authorization hold: Available credit or funds may be reserved for the approved amount.
4. Payment capture: The merchant confirms the amount that should be submitted for payment.
5. Transaction batching: Captured transactions may be grouped for processing.
6. Clearing: Transaction records are exchanged and financial obligations are calculated.
7. Settlement: Financial obligations between participating institutions are fulfilled.
8. Merchant funding: The processor, acquirer, or payment provider sends the merchant’s deposit to its designated bank account.

Major card networks themselves describe authorization, clearing, and settlement as distinct transaction-processing activities. Mastercard, for example, identifies authorization, clearing, and settlement as separate components of its switching services.

That distinction matters because an authorization is essentially permission for the transaction to move forward. Settlement and funding happen later.

The route is also not identical for every merchant. A traditional merchant-account arrangement may have clearly identifiable gateway, processor, acquirer, and merchant-account relationships. A payment facilitator may aggregate many smaller merchants within a broader processing arrangement and handle funding through its own platform.

From Customer Payment to Capture and Batching

The first half of the merchant payment processing journey begins at checkout. Although these steps can happen rapidly from the customer’s perspective, several separate decisions are being made.

Step 1: The Customer Initiates the Card Payment

The process starts when the customer supplies a payment credential. In a store, that might happen by tapping a contactless card, inserting an EMV chip card, swiping a magnetic stripe where supported, or using a digital wallet.

Online, the customer may enter card details into a checkout page or choose a stored credential. An app, invoice, virtual terminal, or other card-not-present system can initiate essentially the same underlying payment-processing sequence.

The POS system, terminal, application, or checkout creates a transaction request containing information needed to process the payment. Depending on the situation, that may include the transaction amount, merchant information, payment credential, terminal or channel information, and security-related data.

Online transactions commonly involve a payment gateway, which securely transmits transaction information between the merchant’s checkout environment and processing infrastructure. 

A merchant using an integrated platform may not see a separate gateway brand because gateway functionality can be bundled with the processor or commerce platform.

Sensitive payment information should be handled through appropriately secured systems. The PCI Security Standards Council establishes industry security standards for organizations that store, process, or transmit cardholder data.

Step 2: Payment Authorization

Once the transaction request enters the processing system, it is routed toward the cardholder’s issuing bank. Depending on the merchant setup, the request may travel through a gateway, payment processor, acquiring side, and card network before reaching the issuer.

The issuing bank is the institution responsible for the customer’s card account. It evaluates whether the transaction should be approved.

Its decision may take into account factors such as:

• Available credit or account funds
• Card status
• Transaction amount
• Fraud-risk signals
• Account restrictions
• Authentication information
• Merchant and transaction data

If approved, the issuer sends an approval response, commonly including an authorization code, back through the payment system. If declined, the transaction generally cannot proceed as an ordinary approved sale unless another payment method is used.

Authorization therefore answers a narrow but essential question: Will the issuer approve this transaction request?

It does not mean merchant settlement has completed.

Visa’s merchant guidance explains that successful authorizations can reduce the cardholder’s available funds to cover the approved amount, commonly creating an authorization hold. For a deeper comparison of the stages, see payment authorization vs. settlement.

Step 3: The Authorization Hold

An approved authorization commonly reserves some of the cardholder’s available credit or funds. This reservation helps prevent that same spending capacity from being used elsewhere before the transaction is completed.

For a simple retail purchase, the authorized amount may already equal the expected final amount. Other businesses may not know the exact final charge when authorization first occurs.

Examples include:

• Restaurants that add a tip later
• Hotels that authorize for room charges and estimated incidentals
• Rental businesses that may authorize an estimated amount
• Fuel stations where the final purchase amount is initially unknown
• Certain delivery or service transactions with adjustable totals

Depending on applicable network rules and processor capabilities, merchants may use authorization adjustments, incremental authorizations, reversals, or other procedures when the final amount changes.

Authorization holds do not remain indefinitely. Authorization validity periods and reversal requirements depend on factors such as card network rules, merchant category, transaction type, and processing circumstances. Visa, for example, maintains specific authorization and reversal requirements rather than treating every transaction category identically.

Merchants should therefore follow their processor’s procedures rather than assuming an approved authorization can be captured at any time.

Step 4: Payment Capture

Capture tells the processing system that an authorized transaction should move toward clearing and settlement for the amount being submitted.

Authorization and capture can occur nearly together, but they are not the same operation.

Many ordinary retail transactions are configured for automatic or immediate capture. Other transactions may be authorized first and captured later.

Delayed capture is common when:

• An online retailer wants to authorize an order before shipping
• A restaurant needs to add a tip
• A merchant needs to verify inventory
• A service has not yet been fully delivered
• The final transaction amount can change
• An employee must manually finalize the charge

If a merchant authorizes a transaction but never properly captures it, the transaction generally will not proceed through the ordinary funding lifecycle simply because it once displayed as approved. The authorization may eventually expire or require another action under applicable rules.

That is why a missing deposit investigation should begin by checking both authorization status and capture status.

Step 5: Transaction Batching

After transactions are captured, merchants or processors may organize them into groups known as batches.

Historically, merchants often manually “closed” or “settled” a terminal at the end of the business day. Many modern POS systems and processors now automate this process, but batch timing still matters.

A batch may contain:

• Completed sales
• Tip-adjusted transactions
• Refund activity
• Other eligible adjustments

The processor sends the completed transactions onward according to its processing schedule. A transaction submitted before the provider’s cutoff may qualify for one funding schedule, while a transaction submitted after the cutoff may fall into the next processing period.

Consider two transactions at the same restaurant:

• A payment completed at 8:30 p.m. is included in the evening batch.
• Another payment completed after that batch closes goes into the following batch.

Both happened on the same calendar date, but they may not reach the merchant’s bank account together.

For a more detailed look at this stage, see how batch processing works for merchants.

Clearing, Card Settlement, and Merchant Funding

Capture is not the end of card payment processing. Captured transactions must still be cleared and settled before the merchant funding process is complete.

These terms are sometimes used casually as though they describe one event. Operationally, they represent different stages.

Step 6: What Clearing Means

During clearing, financial transaction information moves through the processing ecosystem so the participating parties can determine what each transaction represents and what financial obligations result from it.

The card network plays a central routing and rule-setting role. Transaction information submitted by the acquiring side is routed through the applicable network so issuers can process the financial records associated with earlier authorizations.

Clearing may also involve information used to determine interchange and other network-related obligations. The precise calculations, files, message formats, timing, and institutional arrangements differ among networks and processing structures.

An easy way to distinguish the concept is this:

Authorization asks whether the transaction may proceed. Clearing establishes the financial records and obligations associated with the completed transaction.

Clearing is therefore more than merely sending the authorization message a second time. The amount presented for clearing can, in permitted circumstances, differ from the initial authorization amount because of tips or other valid adjustments.

The Federal Reserve separately refers to payment, clearing, and settlement activities in its oversight framework, which reinforces that clearing and settlement should not be treated as interchangeable concepts.

Step 7: Card Payment Settlement

Settlement is the stage in which financial obligations established through payment processing are fulfilled between participating institutions.

At a high level, funds attributable to card transactions move from the issuing side toward the acquiring side according to network and banking arrangements. The exact technical route varies and should not be reduced to a single universal bank-to-bank sequence.

Settlement calculations may account for:

• Completed transactions
• Interchange-related amounts
• Network obligations
• Credits or adjustments
• Reversals
• Other settlement entries

From the merchant’s perspective, the important result is that completed card transactions move from approved payment records toward money available for merchant funding.

The merchant settlement process, however, may include additional steps after network-level settlement. The acquirer, processor, or payment provider must still determine the merchant’s fundable amount and initiate the deposit according to the merchant agreement.

A settlement report may therefore show that transactions have reached a settled status even though the merchant’s operating bank has not yet posted the corresponding deposit.

Step 8: Merchant Funding

Merchant funding is the stage most business owners mean when they ask when they are “getting paid.” This is when the processor, acquiring institution, payment facilitator, or related provider sends the merchant’s eligible funds to the bank account designated for deposits.

The destination is typically the business’s regular deposit or operating account.

Depending on the processing relationship, funds may move through or be associated with a merchant account, settlement arrangement, or payment-facilitator ledger before final funding. A traditional merchant account should not be confused with the merchant’s ordinary checking account.

The deposit the merchant receives may represent:

• One batch
• Several batches
• Multiple business locations
• Gross card sales
• Net card sales after certain deductions
• Adjustments from prior processing periods

Settlement between payment institutions and the bank deposit visible to the merchant are therefore connected, but they are not necessarily the same timestamp.

A processor may mark transactions as settled, initiate the merchant’s funding entry, and then rely on banking rails and the merchant’s financial institution to post the deposit.

Card Payment Settlement Process at a Glance

The following table separates each major stage and answers the question merchants commonly care about most: Does the business actually have the money yet?

Stage	What Happens	Main Participants	Does the Merchant Have the Money Yet?
Payment initiated	Customer presents a card or digital payment credential	Customer, merchant, POS or checkout, gateway when applicable	No
Authorization	Issuer evaluates the transaction and approves or declines it	Processor, acquirer, network, issuing bank	No
Authorization hold	Approved amount may reduce available funds or credit	Issuing bank, cardholder	No
Capture	Merchant confirms the transaction amount for submission	Merchant, POS/gateway, processor	Usually no
Batching	Captured transactions are grouped for processing	Merchant, POS, processor	No
Clearing	Transaction data is exchanged and obligations are calculated	Processor/acquirer, card network, issuer	No
Settlement	Financial obligations between participating institutions are fulfilled	Issuer, network, acquirer and settlement participants	Not necessarily in the merchant’s bank yet
Merchant funding	Eligible merchant funds are deposited according to the funding schedule	Processor/acquirer/payment facilitator, merchant’s bank	Yes, once the deposit is posted and available

The critical distinction is between transaction approval and merchant access to funds.

An approved sale can still require capture, batch submission, clearing, financial settlement, and the provider’s merchant funding process. That sequence explains why authorization can occur in seconds while the resulting bank deposit follows a separate schedule.

A $100 Card Transaction From Checkout to Merchant Deposit

Suppose a customer buys $100 worth of merchandise with a credit card.

First, the merchant’s terminal sends a $100 authorization request into the processing system. The request reaches the issuing bank through the applicable processor, acquiring relationship, and card network.

The issuer approves the transaction. The checkout displays Approved, and the issuer may place an authorization hold affecting $100 of the cardholder’s available credit.

At this point, the merchant has a valid approved transaction, but the $100 has not simply jumped from the customer’s bank into the merchant’s checking account.

The merchant then captures the transaction. It becomes part of the merchant’s batch, which closes according to the processor’s schedule.

During clearing, transaction information is exchanged through the payment system. The obligations associated with the sale are calculated.

Settlement then addresses those financial obligations between the participating institutions.

Finally, the processor, acquirer, or payment facilitator determines the amount eligible for merchant funding and initiates the deposit.

The final deposit may be less than the $100 sale if the merchant’s agreement uses net settlement and processing fees or other adjustments are deducted before funding. Under another agreement, the merchant could receive the gross sale amount while processing charges are collected separately.

Neither structure should be assumed without reviewing the merchant’s pricing and funding terms.

The transaction could also be combined with many other sales in a single deposit. A $100 card payment therefore rarely needs to produce a separate $100 line item on the business’s bank statement.

Who Is Involved in Merchant Payment Settlement?

Card processing looks simple at checkout because technology hides much of the infrastructure. Behind the transaction, however, several participants perform different jobs.

Merchant

The merchant is the business accepting the card payment.

The merchant initiates the payment-processing workflow through its terminal, POS system, online checkout, mobile app, virtual terminal, or other acceptance system. It is also responsible for operational actions such as properly completing sales, capturing transactions when required, managing refunds, monitoring batches, and reconciling deposits.

Merchants should understand the conditions in their processing agreements because funding policies can differ considerably. Batch deadlines, reserves, funding frequency, chargeback procedures, prohibited activities, transaction limits, and account-review provisions can all affect the merchant settlement process.

The merchant may contract directly with several payment companies or use a bundled platform that combines processing, gateway, risk, reporting, and merchant funding functions.

Customer or Cardholder

The cardholder is the person or organization whose payment credential is used for the transaction.

The cardholder initiates the purchase and may authenticate the transaction using a chip, contactless credential, wallet, security code, PIN, or other mechanism depending on the payment method.

During authorization, the cardholder’s issuing institution evaluates whether the account can support the transaction. An approval may cause the authorized amount to affect the cardholder’s available funds or credit.

The customer’s role continues after purchase. Refunds, transaction inquiries, disputes, and chargebacks can create later entries that affect merchant funding even after the original sale has settled.

That is one reason card settlement should not be viewed as permanently irreversible in the same way as receiving physical cash.

Issuing Bank

The issuing bank, or issuer, is the financial institution responsible for issuing the customer’s card account.

During payment authorization, the issuer receives the transaction request and decides whether to approve or decline it. Its decision can consider account status, available funds or credit, authentication information, fraud indicators, and transaction details.

If approved, the issuer sends the response back through the card network toward the merchant.

Later, the issuer participates in clearing and settlement processes associated with completed transactions. It also posts transactions to cardholder accounts and handles the cardholder side of disputes.

The issuer should not be confused with the merchant’s bank. It sits primarily on the cardholder side of the transaction.

Acquiring Bank

The acquiring bank, often called the acquirer, sits on the merchant side of card acceptance.

An acquirer participates in the card-network ecosystem and supports merchants’ ability to accept card transactions. In traditional arrangements, it may sponsor merchant processing and work with processors or other service providers that handle the day-to-day technology.

The acquiring side receives or processes information from merchants and sends transactions into the card-network environment. It also participates in clearing, settlement, dispute processing, and merchant funding arrangements.

Merchants may never communicate directly with the acquiring bank because a processor, independent sales organization, or other provider manages the relationship.

The economic and contractual responsibilities can vary substantially depending on the structure.

Payment Processor

A payment processor provides technology and operational services used to move card transaction information through the payment ecosystem.

A processor may handle functions such as:

• Authorization routing
• Transaction formatting
• Batch processing
• Clearing submissions
• Settlement reporting
• Funding calculations
• Risk controls
• Refund processing
• Dispute workflows

Not every processor performs every role directly. Some companies combine gateway, processor, acquirer-processing, risk, and merchant-services functions, while others specialize in only part of the chain.

Visa’s technical glossary, for example, describes a processor as a company that can provide authorization, clearing, settlement, or other payment-related processing services.

Card Network

A card network provides the rules and communication infrastructure that connects acquiring and issuing participants.

Networks help route authorization messages and clearing information while maintaining operating rules governing transaction processing, disputes, security, and related card-payment functions.

A card network generally should not be described as the customer’s bank or the merchant’s bank. Instead, it provides the infrastructure through which participating institutions exchange payment information and satisfy network obligations.

For example, Mastercard publicly describes separate authorization, clearing, and settlement systems within its switching infrastructure. Visa similarly describes its network as providing authorization, clearing, and settlement services.

Payment Gateway

A payment gateway is especially important in eCommerce and other card-not-present environments.

It acts as a secure technology layer that accepts transaction information from the merchant’s checkout or application and transmits it toward processing services. Gateways may also provide tokenization, fraud screening, recurring billing tools, hosted payment forms, and application programming interfaces.

The gateway does not automatically perform every part of merchant settlement. It may pass payment data to a separate processor and acquirer.

Bundled platforms can make the distinction less visible because one provider may supply the gateway and processing services together.

This is why saying “the gateway holds the merchant’s money” is generally too broad. Funding depends on the merchant’s actual contractual and processing structure.

Merchant Account

A merchant account is part of the traditional infrastructure that allows a business to accept and settle card payments.

Although people sometimes describe it as though it were simply another checking account, its function is different. It exists within the merchant’s card-acceptance relationship and supports the processing and settlement of card transactions.

The merchant’s eligible card-payment proceeds are ultimately routed toward its designated business bank account under the provider’s funding arrangement.

Merchant accounts also operate within a risk framework because card transactions can later generate refunds, disputes, chargebacks, or other adjustments.

For more detail on how the roles differ, see payment processor vs. merchant account.

Payment Facilitator

A payment facilitator, often shortened to PayFac, enables businesses to accept card payments under an aggregated or platform-based processing arrangement.

Instead of every smaller business establishing the same kind of separately structured traditional merchant relationship, the payment facilitator can onboard participating merchants within its broader arrangement and maintain merchant-level records, risk controls, reporting, and funding processes.

This structure is common in software platforms and all-in-one payment services.

For the merchant, the practical experience can be simpler because one platform may handle checkout technology, processing, risk review, reporting, and deposits.

However, that convenience does not eliminate clearing, settlement, compliance, dispute, or risk functions. The payment facilitator simply changes how certain responsibilities are organized.

Business Bank Account

The business bank account is the deposit account where merchant funding commonly ends up.

It is usually the business’s normal operating account rather than the merchant account used within card-processing infrastructure.

When funding is initiated, the payment provider sends eligible merchant proceeds to the bank details on file. The merchant’s bank must then receive and post that deposit.

Incorrect routing details, a closed bank account, banking restrictions, or a failed deposit can therefore cause problems even after card transactions have processed successfully.

Merchants should keep deposit instructions current and use account-verification procedures required by their provider whenever bank information changes.

Authorization vs. Capture vs. Settlement

Authorization, capture, and settlement answer different questions.

• Authorization: Is the issuer willing to approve the transaction?
• Capture: Is the merchant submitting the approved transaction for completion?
• Settlement: Are the resulting financial obligations being fulfilled through the payment system?

Imagine an online retailer receives a $250 order. The retailer authorizes the card when the order is submitted but does not immediately capture it because inventory must be confirmed.

The issuer approves the $250 authorization. No ordinary merchant funding occurs merely because the authorization succeeded.

When the order is ready, the retailer captures the appropriate amount. That capture allows the transaction to move toward clearing and settlement.

A restaurant illustrates the distinction differently. It may obtain an initial authorization before the customer adds a tip, then capture an adjusted final total using procedures supported by the applicable network and processor.

Using these terms interchangeably makes troubleshooting difficult. A merchant support representative asking, “Was it captured?” is asking a different question from “Was it authorized?” or “Was it funded?”

Clearing vs. Settlement

Clearing and settlement are closely related but should not be collapsed into one definition.

During clearing, participating systems exchange transaction records and determine financial obligations. The transaction presented for clearing represents the completed financial information that needs to be accounted for between the acquiring and issuing sides.

During settlement, those obligations are fulfilled through the applicable network and banking arrangements.

A useful comparison is an invoice between businesses. Determining that Company A owes Company B $5,000 resembles the accounting function of clearing. Actually transferring the money to satisfy the obligation resembles settlement.

Card-network processes are much more sophisticated than that analogy, but the distinction is useful.

The technical implementation varies between networks. Messages, files, timing windows, settlement accounts, currencies, adjustments, and participant relationships are governed by network-specific systems and rules.

This is why a general explanation should focus on the functional difference rather than claiming every network sends funds through an identical path.

For merchants, clearing and settlement matter because they sit between captured sales and final funding. If transactions fail to move successfully through those stages, expected deposits can be affected.

When Does the Merchant Actually Get Paid?

The merchant effectively gets paid when eligible card proceeds are funded to the designated bank account and become available according to the receiving bank’s posting practices.

That moment is later than authorization and may also be later than the processor’s technical settlement event.

Merchant settlement time can depend on:

• Processor funding schedules
• Acquiring-bank arrangements
• Batch close time
• Day of the week
• Bank holidays
• Merchant risk profile
• Account history
• Transaction type
• Card type or payment method
• Bank posting procedures
• Reserve arrangements
• Account reviews
• Payment-facilitator policies
• Expedited-funding eligibility

Many providers offer schedules described as standard, next-business-day, same-day, or expedited funding. Those terms are provider-specific and may have eligibility requirements, cutoff times, fees, transaction restrictions, or banking requirements.

Accordingly, the most useful answer to how long does it take merchants to get paid is not a universal number. A merchant should check the funding terms applicable to its specific account.

A transaction processed late on Friday, for example, may interact differently with provider cutoffs and banking days than a transaction processed early on Tuesday.

Credit Card and Debit Card Settlement Timing

Credit and debit card transactions both move through authorization, processing, clearing, settlement, and merchant funding functions, but businesses should not assume that every transaction uses the same routing or timing.

For credit card transactions, authorization evaluates the cardholder’s available credit and other issuer controls. Captured transactions then proceed through network clearing and settlement before merchant funding.

Debit transactions can vary depending on how they are authorized and routed. Some involve PIN-based debit routing, while others are processed through card-network pathways that resemble signature or card-not-present card transactions.

The Federal Reserve’s debit-card reporting separately recognizes authorization, clearing, and settlement costs within debit transaction processing.

Funding timing ultimately depends on the merchant’s processor and acquiring arrangement rather than simply whether the customer used the word “debit” or “credit” at checkout.

Weekends and holidays can also matter. Payment systems and financial institutions operate according to specific settlement calendars, and the merchant’s receiving bank has its own posting procedures.

Same-day funding may be available in some processing arrangements, while another merchant may operate on next-business-day or longer standard schedules.

Merchants comparing programs should therefore examine the complete merchant funding time, not simply the speed of authorization.

What Happens to Processing Fees Before the Merchant Gets Paid?

Card acceptance can involve several categories of cost. The way those costs appear in merchant deposits depends on the pricing and funding agreement.

Common categories include:

• Interchange-related costs, generally associated with the issuing side
• Network assessments or fees
• Processor or acquiring markup
• Transaction or authorization charges
• Gateway charges
• Monthly or service charges
• Chargeback-related fees where applicable

Some merchants operate under net settlement. In that structure, applicable fees or other deductions may be removed before the provider sends the deposit.

Other arrangements use gross settlement, where the merchant receives gross eligible transaction proceeds and fees are collected separately, such as through a later debit or monthly billing cycle.

Hybrid arrangements also exist.

Suppose a merchant has $10,000 in eligible card sales. Under a gross-settlement arrangement, it might receive the $10,000 deposit while applicable processing costs are billed separately. Under a net-settlement structure, the bank deposit would reflect deductions before funding.

That example describes the accounting concept only. It does not imply a particular processor, fee amount, or pricing schedule.

For more background on how underlying fees and processor markup can be presented, see merchant service pricing models.

Why Merchant Deposits Do Not Always Match Sales Totals

A common reconciliation problem occurs when the POS shows one sales total but the bank account shows a different deposit.

That difference does not automatically indicate missing money.

Possible causes include:

• Processing fees deducted before funding
• Refunds
• Chargebacks
• Tips added after initial authorization
• Manual adjustments
• Split batches
• Multiple batches combined into one deposit
• Transactions crossing a batch cutoff
• Payment holds
• Rolling or fixed reserves
• Transactions funded on different schedules
• Failed or reversed transactions
• Deposit grouping across locations or channels

For example, a restaurant could report $8,000 in base card sales while final captured amounts are higher because tips were added. A retailer could show $8,000 of gross sales but have refunds or processing adjustments included in the same settlement period.

The correct reconciliation comparison is therefore usually POS transactions → captured batch → processor settlement report → funding report → bank deposit, rather than POS sales directly to bank deposits.

Merchant settlement reports are especially useful because they may contain a batch ID, transaction total, refund amount, adjustments, processing fees, funding amount, settlement date, and deposit reference.

Terminology varies by provider, so merchants should learn which report represents the actual funding calculation.

What Can Delay Merchant Settlement?

A funding delay does not automatically mean the transaction was lost or the processor has failed. Several operational, banking, and risk conditions can move an expected deposit to a later date.

Common causes include:

• Missing the processor’s batch cutoff
• Failing to close a manual batch
• Weekends or banking holidays
• Receiving-bank posting delays
• Processor or acquiring-bank reviews
• Unusually large transactions
• Sudden increases in processing volume
• Suspected fraud
• Elevated chargeback activity
• Account-verification issues
• Reserve requirements
• Compliance reviews
• Incorrect banking information
• Failed bank deposits
• Higher-risk transaction patterns
• Technical processing incidents
• Transactions that were authorized but never captured

Merchants experiencing a delay should first determine whether the issue affects one transaction, one batch, or the entire account.

A single missing transaction often points to capture or batch issues. A full missing deposit may point toward funding timing, banking information, account review, reserve treatment, or a failed transfer.

Large changes in sales volume can also trigger review because processors and acquiring institutions manage exposure to refunds, fraud, and chargebacks.

That does not necessarily mean the business has done anything improper. It means the provider may need to assess transactions before releasing funds under its risk policies and merchant agreement.

Payment Holds, Rolling Reserves, Refunds, and Chargebacks

Card payments remain subject to adjustments even after the original transaction has been processed. Holds, reserves, refunds, and disputes can therefore affect the amount or timing of merchant funding.

Payment Holds and Rolling Reserves

A payment hold generally refers to funds that are temporarily not being released according to the merchant’s normal funding schedule.

A reserve is money retained to help cover potential merchant obligations such as refunds, disputes, or chargebacks. Reserve structures can include rolling reserves, fixed reserves, or other risk-based arrangements.

Under a hypothetical rolling reserve, a provider might retain an agreed percentage of each settlement and release eligible reserved funds later according to the merchant agreement.

The exact percentage and release schedule vary. There is no single reserve percentage that applies to all merchants.

Reserves may be influenced by factors such as business model, delivery timeframe, chargeback exposure, processing history, ticket size, financial condition, or sudden changes in transaction activity.

Merchants should review reserve provisions carefully and ask how withheld amounts appear in settlement reporting.

How Refunds Affect Settlement

A refund creates a financial adjustment in the opposite direction of the original sale.

Depending on the provider’s procedures and the merchant’s available processing balance, the refund amount may be deducted from upcoming settlement funds, debited from another balance, or handled through another funding mechanism.

Timing can differ between the merchant’s refund submission and the cardholder seeing the credit.

A merchant should therefore reconcile refunds based on both processor records and bank activity.

Refund procedures are provider-specific. Merchants should verify whether refunds can exceed the current settlement balance, how negative balances are handled, and whether processing fees associated with the original transaction are returned.

How Chargebacks Affect Merchant Funding

A chargeback occurs when a transaction is formally disputed through the card-payment system.

Depending on the dispute process and applicable rules, the disputed transaction amount may be debited from the merchant or otherwise reflected in its processing balance while the case proceeds. Chargeback fees may also apply under some merchant agreements.

Merchants can be given an opportunity to respond with documentation when representment is available and appropriate. Evidence might include transaction records, proof of delivery, refund policies, customer communications, or authorization information.

Submitting evidence does not guarantee that a merchant will prevail.

Chargebacks can also affect broader account risk. Elevated dispute activity may lead to monitoring, reserves, funding changes, or other risk-management action depending on processor, acquirer, and network requirements.

How Tips and Adjusted Transactions Reach Settlement

Businesses such as restaurants may not know the final transaction amount when the initial authorization occurs.

Suppose a restaurant authorizes a customer’s card for the pre-tip amount. The customer then adds a gratuity.

The merchant’s system subsequently captures the final transaction amount using the procedures supported for that transaction type. The final amount submitted for clearing can therefore reflect a valid adjustment to the original authorization.

Other industries can use different authorization-management procedures when final amounts are uncertain. Hospitality, rental, fuel, and other merchant categories may operate under specific network rules involving estimated authorizations, incremental authorizations, adjustments, or reversals.

Merchants should not assume that simply increasing a transaction after authorization is acceptable in every situation.

Processors and card networks define procedures for these merchant categories because authorization management affects both cardholder funds and settlement integrity.

For reconciliation purposes, businesses with tips should compare the final captured transaction totals with settlement reports rather than comparing only initial authorization totals.

That is another example of why authorization does not represent the final financial state of a card sale.

How Online, POS, and Digital Wallet Payments Reach Merchants

The customer’s checkout experience can differ substantially, but many transactions converge on similar card-processing infrastructure after payment information enters the system.

Online Card Payments

In eCommerce, the customer enters a card or selects a stored payment method at checkout.

A payment gateway or similar acceptance layer securely sends transaction information toward the processor. Fraud-screening tools may evaluate device information, velocity, address data, authentication signals, or other indicators.

The authorization request travels through the acquiring and network infrastructure to the issuing bank. If approved, the transaction can later be captured, cleared, settled, and funded.

Card-not-present transactions can have greater fraud and dispute exposure because the physical card and cardholder are not standing at a terminal. Merchants should therefore use appropriate security and risk controls without making checkout unnecessarily difficult for legitimate customers.

In-Person POS Transactions

At a physical location, the POS system or terminal collects payment through chip, contactless, swipe where applicable, or another supported payment interface.

The authorization process still reaches the issuing bank through the card-payment infrastructure.

Once transactions are captured, the POS or processor may automatically close the merchant’s batch at a configured time. Other businesses may manually initiate batch closing.

Integrated systems can make batching nearly invisible to staff, but cutoff times still influence funding.

A successful terminal approval therefore represents only the beginning of the merchant’s settlement journey.

Digital Wallet Payments

When a digital wallet transaction is funded by a payment card, the customer’s experience may look different while the merchant’s underlying card settlement remains broadly similar.

The wallet can present a tokenized or device-associated payment credential rather than exposing the underlying card number directly to the merchant.

Once that credential enters supported card-payment rails, authorization, clearing, settlement, and merchant funding functions can resemble those used for another card transaction.

Tokenization is one reason modern wallets can reduce direct exposure of underlying card numbers. PCI SSC guidance explains that tokenization can affect the scope of cardholder-data environments depending on implementation.

Merchant Account vs. Business Bank Account

The terms merchant account and business bank account describe different things.

A merchant account is associated with the merchant’s card-processing relationship. It supports acceptance, settlement, risk management, and other aspects of card transactions.

A business bank account is the ordinary deposit account used by the business for operations.

A simplified flow looks like this:

Card transaction → payment-processing and settlement environment → merchant funding → business bank account

That does not mean every transaction sits in a separately visible merchant-account bank balance before being deposited.

Modern payment-facilitator arrangements may maintain merchant balances and funding records within a platform rather than giving the business a separately identifiable traditional merchant account.

Regardless of the structure, merchants should know which account receives deposits and who is responsible for initiating those deposits.

This distinction becomes especially important when troubleshooting. A transaction may be successfully processed in the merchant-payment environment but fail to reach the business bank account because of incorrect banking information or a rejected deposit.

Payment Processor vs. Acquiring Bank

The processor and acquiring bank also perform different roles, even though one organization or corporate group can sometimes provide or coordinate several functions.

The payment processor generally provides technology and operational processing. It routes transaction messages, supports batching, processes transaction records, produces reports, and can perform other payment functions.

The acquiring bank participates in the merchant side of the card-network system and supports the merchant acceptance relationship.

A merchant may sign paperwork with a processor or merchant-services provider while the acquiring institution appears elsewhere in the agreement.

Payment facilitators add another layer because the merchant may interact primarily with the platform rather than directly with the underlying acquiring institution.

When merchants investigate funding, they therefore should not assume that “processor,” “gateway,” “acquirer,” and “merchant bank” all refer to the same entity.

Understanding who actually controls settlement, risk holds, and merchant funding can make support conversations substantially more productive.

Batch Cutoffs and Same-Day, Next-Day, or Standard Funding

Batch timing can directly affect when a merchant receives deposits.

Suppose a processor closes eligible batches at a particular evening cutoff.

Transaction A occurs two hours before the cutoff and is captured immediately. It enters that day’s batch.

Transaction B occurs shortly after the cutoff. Although the purchases happened on the same calendar date, Transaction B enters a later processing cycle.

Funding programs can generally be grouped into three broad descriptions:

• Standard funding: Deposits follow the provider’s normal multi-stage processing schedule.
• Next-day funding: Eligible transactions submitted within required cutoffs may be funded on the next qualifying business day.
• Same-day or expedited funding: Certain providers may offer faster access for eligible merchants and transactions.

Those labels are not universal service guarantees.

Eligibility may depend on:

• Processing history
• Risk category
• Transaction type
• Batch submission time
• Receiving bank
• Merchant account status
• Additional fees
• Provider capabilities

A merchant evaluating faster funding should consider both speed and cost. Paying for expedited deposits may help a business with tight operating cash flow, but another merchant may have no need to accelerate funds by several hours.

How Merchants Can Reconcile Card Deposits

Reconciliation connects card sales recorded by the business with deposits actually received.

A disciplined process can identify missing batches, unexpected deductions, duplicated transactions, refunds, and funding delays before they become month-end accounting problems.

Use this sequence:

1. Check POS or checkout sales totals. Confirm which transactions were completed during the period.
2. Verify capture status. Remove authorizations that were voided, expired, or never captured.
3. Review batch reports. Confirm which transactions were included in each closed batch.
4. Compare processor settlement reports. Identify the transactions, refunds, adjustments, and fees applied to the settlement.
5. Review funding reports. Determine what amount the processor says it sent to the merchant.
6. Match funding to bank deposits. Use deposit dates and references rather than only sales dates.
7. Investigate differences. Check fees, reserves, refunds, chargebacks, split batches, and cutoff timing.
8. Keep supporting records. Preserve settlement reports, receipts, refund records, dispute documents, and bank confirmations according to appropriate recordkeeping requirements.

A settlement report may contain a batch number, gross transaction amount, refunds, credits, fees, net funding total, settlement date, funding date, and reference number.

Labels vary significantly, so merchants should learn the terminology used by their specific provider.

Common Merchant Settlement Problems and Troubleshooting

Card funding problems are easier to solve when merchants isolate the stage where the problem occurred.

Common issues include:

• Missing deposits
• Partial deposits
• Duplicate transactions
• Failed or unclosed batches
• Unexpected settlement delays
• Unrecognized processing fees
• Incorrect bank information
• Chargeback deductions
• Refund mismatches
• Reserve withholding

If a card payment has not reached the bank account, work through this checklist:

1. Confirm that the transaction was approved.
2. Confirm that it was captured.
3. Check whether it was included in a batch.
4. Verify that the batch closed successfully.
5. Check the transaction or batch settlement status.
6. Review the scheduled merchant funding date.
7. Look for holds, reserves, refunds, or chargeback adjustments.
8. Confirm the bank account information on file.
9. Consider weekends and banking holidays.
10. Check whether the provider reports a failed funding attempt.
11. Contact the processor or payment provider with the transaction ID, batch ID, funding reference, and amount.

The more specific the information supplied to support staff, the easier it is to determine whether the issue involves authorization, settlement, risk review, or bank posting.

A generic statement such as “my money is missing” usually takes longer to investigate than providing the exact batch and funding reference.

How Merchants Can Improve Settlement Reliability

Merchants cannot control every part of the card-payment ecosystem, but they can reduce avoidable funding problems through consistent operational practices.

Useful steps include:

• Close or verify batches on schedule.
• Understand processor cutoff times.
• Keep business and bank information accurate.
• Monitor unusual processing spikes.
• Review settlement and funding reports.
• Reconcile card deposits frequently.
• Respond promptly to account-verification requests.
• Maintain clear refund procedures.
• Monitor chargebacks and customer complaints.
• Keep required business information current.
• Notify payment providers of material business changes when the merchant agreement requires it.
• Use secure, supported payment technology.
• Maintain adequate operating liquidity rather than assuming every card sale will fund instantly.

Cash-flow planning deserves particular attention.

An approved transaction is not cash in the business bank account. Businesses with payroll, inventory, supplier payments, or daily operating obligations should plan around their actual funding schedule rather than gross POS sales.

The merchant agreement remains the best source for provider-specific terms involving holds, reserves, cutoff times, funding eligibility, fees, and account review procedures.

Security During the Card Settlement Process

Security is relevant throughout card payment processing, not only at checkout.

Merchants handle or transmit sensitive payment information through terminals, POS systems, gateways, applications, and service providers. Security controls are intended to reduce opportunities for cardholder data to be stolen or improperly exposed.

Common protections include:

• Encryption
• Tokenization
• Secure payment applications
• Access controls
• Authentication
• Network security
• Fraud monitoring
• Transaction-risk controls

The PCI Data Security Standard establishes technical and operational requirements for protecting cardholder data environments. PCI SSC describes the standard as applying to organizations involved in storing, processing, or transmitting cardholder data.

PCI DSS compliance should not be treated as a guarantee against fraud or breaches. It is one component of a broader security program.

Merchants should also reduce unnecessary storage of raw card information, keep systems updated, restrict administrative access, investigate suspicious processing patterns, and use payment providers that support appropriate security controls.

Security failures can eventually become funding problems if fraud generates refunds, disputes, chargebacks, or account reviews.

Common Myths About Merchant Payment Settlement

Several misconceptions make the card settlement process seem simpler than it actually is.

• Myth: “Approved” means the merchant already has the money: Approval generally means the issuer authorized the transaction. Capture, clearing, settlement, and funding still follow.
• Myth: All card payments settle instantly: Authorization can happen rapidly, but financial settlement and merchant funding operate on separate schedules.
• Myth: Authorization and settlement mean the same thing: Authorization is the issuer’s decision on a transaction request. Settlement concerns fulfillment of financial obligations after transactions are completed.
• Myth: Every processor uses the same funding schedule: Funding depends on provider policies, merchant agreements, cutoffs, risk considerations, banking days, and other factors.
• Myth: Every merchant deposit should equal that day’s POS sales: Deposits can reflect batches, fees, refunds, chargebacks, tips, reserves, and other adjustments.
• Myth: The payment gateway always holds merchant money: A gateway is primarily a transaction-acceptance and transmission layer. The funding structure depends on the broader provider arrangement.
• Myth: A merchant account is the same as a business checking account: The merchant account relates to card acceptance and settlement, while the business bank account is where funded proceeds generally become available for ordinary use.

Merchant Payment Settlement Best Practices

The most reliable settlement operations are built around visibility.

Merchants should know when transactions are captured, which batch they enter, when the processor considers them settled, and when the resulting funding is expected at the bank.

A useful settlement checklist is:

• Know the processor’s funding terms.
• Document batch cutoff times.
• Understand same-day or next-day eligibility.
• Review settlement reports regularly.
• Match processor funding to bank deposits.
• Understand whether fees are deducted gross or net.
• Track refunds separately.
• Monitor chargebacks.
• Review reserve activity.
• Investigate unusual delays promptly.
• Keep banking information accurate.
• Maintain supporting transaction records.
• Understand which company controls gateway, processing, acquiring, and funding functions.
• Plan cash flow around actual deposit timing rather than approval timing.

Merchants should also periodically review their statements and pricing structures. A settlement problem can sometimes appear to be missing funding when the real cause is an unfamiliar fee, refund, reserve, or adjustment.

The objective is not simply faster funding. Reliable merchant settlement means predictable timing, understandable reporting, accurate reconciliation, and enough visibility to explain every meaningful difference between card sales and bank deposits.

Frequently Asked Questions

Conclusion

Understanding how merchants get paid requires looking beyond the instant approval message at checkout.

The process begins when a customer presents a card or digital credential. The issuing bank then evaluates the payment authorization request and may place an authorization hold on the customer’s available credit or funds.

The merchant captures the transaction and submits it for processing, often through transaction batching. Clearing exchanges the completed transaction information and determines financial obligations, while settlement fulfills those obligations through the applicable card-network and banking arrangements.

Only after those stages does the merchant funding process result in eligible proceeds being sent to the business’s designated bank account.

The timing and amount of that deposit can vary because of processor schedules, batch cutoffs, weekends, holidays, processing fees, refunds, chargebacks, reserves, risk reviews, and receiving-bank procedures.

That is why an approved transaction should never be treated as identical to money already available in the merchant’s bank.

Businesses that understand their capture procedures, batch schedules, settlement reports, fee structure, and funding terms are better positioned to reconcile deposits, investigate delays, and manage cash flow with fewer surprises.