What happens when you swipe a credit card or tap one at a contactless terminal isn't a single transaction. It's a coordinated message exchange between five separate parties that completes in roughly two seconds, then quietly keeps running for another 24 to 72 hours after you walk out the door. I've watched terminals reject cards, watched the same card work ten minutes later on the same terminal, and watched merchants get charged for transactions they thought had failed. Most of that confusion comes from people not knowing what's really happening inside those two seconds.
The Five Parties Behind Every Card Tap
A single card tap involves more parties than most people guess. The cardholder is one. The merchant is another. Behind them sit three more: the acquirer (the merchant's processing bank), the card network (the global rails that route the message), and the issuer (the bank that issued the card and lent the money). A successful tap requires every one of them to agree, in sequence, in under two seconds. If any link fails or hesitates, the terminal beeps red.
The acquirer is the one most merchants interact with by name, since it's the processor they've contracted with. The card network is the part most people don't think about at all. The issuer is the bank printed on the front of the card. Each one charges a fee for its role, which is where interchange and assessment fees come from, but that economic question sits separate from the technical mechanics of a single tap.
What Happens When You Swipe a Credit Card, Step by Step
The moment a chip card touches a contactless reader or gets inserted into a slot, the terminal pulls a small bundle of data off the chip. That bundle includes the card number (encrypted), an expiration date, a one-time cryptogram generated by the chip, and a few flags about what kind of authentication was used. According to EMVCo, the global body that publishes EMV specifications, that cryptogram is unique to the single transaction and can't be replayed by anyone who later intercepts the message. The terminal hands that bundle to a payment gateway, which is the software layer that knows how to format and forward payment messages. The gateway sends it to the acquirer. The acquirer reads the leading digits of the card number, the BIN or Bank Identification Number, to figure out which network the card belongs to, then transmits the message to that network. The network looks at the same BIN to identify the issuing bank and routes the message to that issuer's authorization system. The credit card transaction process touches four different organizations before any decision is made about whether the charge gets approved.
The issuer is where the actual decision happens. Up to this point, every party has been a courier. The issuer is the only one with access to the cardholder's available credit, fraud history, and account flags. Its authorization system runs the message through a stack of checks in milliseconds and returns one of three answers: approve, decline, or refer (rare, and almost always means call the bank). That answer travels back through the same path, network to acquirer to gateway to terminal. The terminal beeps. You take your card.
What the Issuing Bank Actually Checks
The issuer is checking more than just whether you have money available. It's looking at four things at once. Available credit is the obvious one. The second is fraud scoring, where machine-learning models compare the transaction against the cardholder's normal patterns and against current fraud trends. A $7 coffee purchase at 8 a.m. in a familiar zip code scores very differently than a $1,200 electronics purchase at 3 a.m. across the country. The third check is velocity. If the same card has been used four times in the last ten minutes at four different merchants, that's a velocity flag. Most issuers have rules that throttle approvals after certain rapid-fire patterns, even when the credit is technically there. The fourth is account status: holds, locks, expired records, or compromised-card flags from a recent breach response.
Federal Reserve research on payment fraud has documented that authorization fraud losses move with the sophistication of these scoring models, not just with the volume of attempted fraud. Issuers tune these rules every day.
How Long Does a Credit Card Authorization Take
End to end, a typical credit card authorization flow takes between one and three seconds. The single biggest chunk of that time is network round-trip latency, the physical time required for the message to travel through fiber and switches between the merchant's location and the issuer's data center. The actual decisioning at the issuer is usually under 100 milliseconds.
Some taps take longer. Chip cards that fall back to contact mode add a half-second of card-and-terminal handshake. Debit transactions that prompt for a PIN add the time you take to type. Transactions flagged for additional authentication, like 3-D Secure on a card-not-present transaction, can add several seconds. And some issuers run a slower secondary check on transactions that score high for fraud, letting them through but logging them for review.
Authorization vs. Settlement: Two Different Events
This is the part most business owners get wrong. Authorization isn't payment. Authorization is the issuer agreeing to hold funds and approving the merchant to capture them. The actual movement of money happens later, during settlement.
When the terminal beeps green, the authorization is logged but no money has moved yet. The merchant has a reservation against the cardholder's available credit. Settlement is the second event, when the merchant tells the acquirer to go ahead and pull the money the merchant was authorized for. That second event triggers the actual fund movement through the network's clearing system. For most card-present transactions, the merchant's terminal captures all authorizations automatically at the end of the business day in what's called a batch. The batch goes to the acquirer, the acquirer submits clearing files to the network, and the network instructs each issuer to debit cardholder accounts and credit the acquirer. The acquirer then deposits funds to the merchant's bank account, typically one to two business days later.
Why a Credit Card Sometimes Declines and Then Works
Customers see this all the time. The first tap fails, the second tap succeeds, and nobody can explain it. The most common reason is a velocity rule that triggered on the first attempt and cleared by the second. Another common cause is a transient network timeout: the message didn't make it back to the terminal fast enough, so the terminal called it a decline. The same card, retried thirty seconds later, sails through.
Some declines clear because the issuer ran a fraud-prevention soft hold and lifted it after a quick automated check. Some clear because the cardholder confirmed the transaction in their banking app between attempts. And some declines aren't really declines at all. They're "do not honor" responses that the network passes through, where the issuer's reasoning isn't communicated to the merchant. Merchants typically can't get an explanation from the network in real time. The card either approves or it doesn't.
Offline and Deferred Authorization
Not every transaction reaches the issuer in real time. When a terminal can't connect to the network, when the network can't reach an issuer, or when a merchant accepts payments in an environment without reliable connectivity (think airplanes, some transit systems, certain mobile setups), the transaction has to be authorized through a different process.
Stand-in authorization lets the network or the acquirer approve transactions on behalf of the issuer when the issuer is unreachable, using rules the issuer has pre-configured. Floor limits allow merchants in certain categories to approve small transactions without a real-time check. Both create a small risk window where the issuer might later refuse the charge, leaving the merchant's acquirer to absorb the loss or pass it back. Card network rules govern who's responsible in each scenario, and those rules vary by region and merchant category.
Batch Settlement at Day's End
A merchant's settlement batch is the file containing every authorization captured for fund movement that day. Most card-present merchants close their batch automatically at a fixed time, often overnight. Card-not-present merchants generally settle in near-real-time or in smaller frequent batches, depending on the processor's setup.
When the batch is transmitted, the acquirer assembles clearing files for each card network. Each network processes its files, instructs the appropriate issuers, and confirms the transfers. Funds typically arrive in the merchant's bank account one to two business days after the batch closes, though the exact timing depends on the merchant's processor agreement, the merchant's bank, and the time of day the batch was submitted. Same-day funding is available from many providers, usually for an additional fee.
Why the Card Tap Behind the Scenes Actually Matters
Understanding what happens behind the scenes during a card tap changes how you think about a few things. It explains why a declined transaction isn't always a bad card. It explains why funds don't appear in your bank account the moment a customer pays. It explains why fees layer the way they do, with each party in the chain charging for its role. It also explains why processors can offer such different experiences in chargebacks, holds, and settlement timing, even when the underlying network rules are the same for everyone.
For business owners evaluating card processing options, the takeaway isn't that any specific provider runs this process better. The mechanics are largely set by the card networks. What varies is how a processor handles the parts they actually control: settlement speed, batch flexibility, fee transparency, dispute support, and how clearly they communicate during the inevitable edge cases. Providers in this market differ widely on those operational dimensions, and that's where buying decisions actually get made.