Credit card processing is the transaction lifecycle that connects merchant acceptance, issuer authorization, capture, clearing, settlement, refunds, and disputes.
Credit card processing is the transaction lifecycle that lets a merchant accept a credit card and exchange payment information through a gateway or terminal, processor, acquirer, card network, and issuer. The lifecycle includes authorization, capture, clearing, settlement, merchant funding, refunds, and possible disputes.
The customer can receive an approval within seconds, but the merchant does not receive final, irreversible funds at that moment. Each stage creates different records, fees, timing, and risks.
| Party | Primary role | Typical record |
|---|---|---|
| Cardholder | Presents the card or credential and owes the issuer under the account terms | Receipt and issuer account posting |
| Merchant | Sells the goods or services and submits the transaction | Order, invoice, receipt, fulfillment, and refund evidence |
| Gateway or terminal | Captures, protects, and transmits payment data | Transaction ID, entry mode, token, and response |
| Processor | Handles or routes transaction messages | Authorization log, batch, clearing, and settlement report |
| Acquirer | Provides merchant acceptance and settlement | Merchant statement, funding, fee, and chargeback record |
| Card network | Supplies transaction rules and routing infrastructure | Network response, clearing, fee, and dispute data |
| Issuer | Provides the card account and approves or declines | Authorization, account posting, statement, and dispute decision |
The commercial provider shown on a merchant statement may perform several roles. Role names describe functions, not necessarily separate companies.
flowchart LR
A["Cardholder and merchant"] --> B["Terminal or gateway"]
B --> C["Processor and acquirer"]
C --> D["Card network"]
D --> E["Card issuer"]
E -->|"Approve or decline"| D
D --> C
C --> B
B --> A
A --> F["Capture and batch"]
F --> G["Clearing and settlement"]
G --> H["Merchant funding and reconciliation"]
The merchant sends the amount, account or token data, merchant information, entry mode, and other required fields. The issuer evaluates account status, available credit, fraud signals, card controls, and transaction rules before approving or declining.
An approval may create an authorization hold. It does not prove delivery, capture, settlement, or the absence of later dispute rights.
The merchant submits the final amount for completion. Capture may occur immediately, at batch close, after shipment, or after an adjustment permitted by the transaction type and rules. Hotels, restaurants, fuel merchants, and other businesses may use estimated or adjusted authorization workflows.
Detailed transaction data moves through the acquiring and network process. Obligations, fees, and net positions are calculated and settled among participants under the applicable arrangements.
The acquirer or merchant-service provider funds the merchant according to the agreement. The deposit may combine many transactions and subtract refunds, fees, reserves, chargebacks, or adjustments.
A merchant refund is initiated by the merchant. A chargeback is a dispute-related reversal through the issuer, network, acquirer, and merchant process. A void generally cancels a transaction before completed settlement. These terms should not be used interchangeably.
A customer buys two items for a total of $120. The issuer approves $120, the merchant captures the transaction, and it enters clearing and settlement. The merchant later receives a deposit that includes this and other transactions, net of charges under its agreement.
The customer returns one item for $45. The merchant submits a $45 refund linked to the original sale. A useful reconciliation preserves:
The refund should not be recorded as a chargeback, and the original $120 authorization should not be rewritten as a $75 sale. Each event needs its own date, amount, identifier, and accounting treatment.
| Attribute | Card-present | Card-not-present |
|---|---|---|
| Customer interaction | Card, phone, or wearable interacts with an acceptance device | Credential entered or supplied remotely through web, app, phone, mail, or stored account |
| Common evidence | EMV or entry-mode data, terminal ID, and verification result | Checkout session, device and account signals, address or security-code result, and authentication data |
| Main fraud concern | Counterfeit, lost or stolen use, tampered terminal, and fallback | Stolen account data, account takeover, automated testing, and false identity |
| Merchant control focus | Device security, staff process, fallback, and terminal reconciliation | Application security, authentication, bot controls, tokenization, and fulfillment evidence |
Neither channel is automatically safe. Risk and liability depend on payment method, credential, controls, merchant behavior, issuer decision, network rules, and jurisdiction.
A merchant’s total acceptance cost can include:
Quoted rates are not directly comparable unless the merchant compares the same transaction mix, sales channel, card type, geography, average ticket, refund rate, fraud exposure, equipment, and services.
Card-network rules, merchant agreements, credit laws, consumer protections, data-security requirements, and processing practices vary. Review the current rules governing a particular transaction.
This article provides general financial education. It is not merchant, accounting, payment-security, credit, legal, or compliance advice.