This is Part 2 of our look at what happens when you tap a card. In Part 1: Inside Card Authorization we followed the message from the POS terminal, through the acquirer and card network, to the issuer’s front door. Here we’ll cover the issuer’s side: the checks that run in milliseconds, why a healthy balance can still be declined, and the fallback used when the issuer is offline.
From tap to decision
When you tap a crypto-linked card, the issuer receives a standardized request with the amount, merchant category code (MCC), merchant country, acceptance method, and a few other fields. It has only tens of milliseconds to answer: approve, or decline with a reason code.
That answer is a sequence of independent gates. Fail any gate and the transaction stops. Having enough funds only gets you past gate two.
Gate 1: card and account status
Is the card active, not expired, and not frozen or reported lost? Is the account in good standing? If the card status is wrong, nothing else matters.
For crypto card users this gate matters: many cards are managed through apps that let you freeze, unfreeze, or set spending controls yourself. If you froze the card after a suspicious alert and forgot to unfreeze, this is the gate that blocks you.
Gate 2: available balance or credit
For a debit or prepaid crypto card, the issuer checks the available balance. For a credit product it checks the available credit line.
“Available” subtracts not only settled purchases but also pre-authorization holds that are frozen but not yet posted. A hotel hold, gas-pump pre-auth, or streaming free-trial check can all reduce the number the issuer sees. Our fee calculator can help you model the real cost before you tap.
Gate 3: fraud and risk scoring
This is the single most common reason for “I had the money, but it was declined.” The issuer’s risk engine scores the transaction in real time: amount patterns, merchant type, location, and whether your card was just used across the world.
A high risk score blocks the transaction even if the funds are fully there. The system wants proof it is really you. See our payment auth wiki.
Gate 4: velocity and spending limits
Velocity rules watch how fast and how often the card is used. Per-transaction caps, daily spend limits, daily transaction counts, and sudden bursts of activity all live here. The pattern of “four small purchases went through, the fifth was declined” is usually a velocity threshold, not a balance problem.
If you are choosing a crypto card, compare how providers set these limits with our card comparison tool.
Gate 5: merchant, category, and country rules
Issuers and programs can block or restrict transactions by MCC, by specific merchant, or by country. A travel block, a restriction on gambling or crypto-related MCCs, or a country-level sanction can decline a transaction that would otherwise pass every other gate.
Gate 6: account health and program-level checks
Finally, the issuer may look at repayment status, program-level restrictions, or account health. A past-due balance, a suspended account, or a temporary hold from the card program can all produce a decline.
Authorization types: hold vs. charge
Authorization is not the same as settlement. When a merchant gets approval, the issuer typically places a hold on the funds. The actual movement of money happens later, during clearing and settlement.
- Standard authorization: the hold matches the expected final amount.
- Pre-authorization: an estimated amount is frozen first, then adjusted at settlement. Hotels, car rentals, and gas pumps do this routinely.
- Incremental authorization: the merchant increases the hold when the final amount will be higher than the estimate.
- Account verification: a zero- or low-value check used to confirm the card is valid, common when adding a card to a wallet or app.
This is why the amount you see “charged” immediately sometimes differs from what settles days later. The hold is a reservation, not the final bill.
Decline codes: hard vs. soft, issuer vs. network
A decline always carries a reason code, and those codes split along two axes.
Hard vs. soft. A hard decline means “do not retry” — lost card, closed account, suspected fraud. A soft decline means “not right now” — temporary limit shortage, risk trigger, or extra verification needed.
Issuer vs. network. An issuer decline comes from one of the gates above. A network decline happens before the request reaches the issuer: malformed message, network compliance rule, timeout, or acquirer-side restriction. The code tells you whose problem it is and whether retrying makes sense. You can also walk through the flow in our auth flow demo.
Stand-in processing
Sometimes the issuer’s authorization system is unreachable — maintenance, outage, network break. Rather than fail every transaction, the card network can step in and make the decision on the issuer’s behalf. This is called Stand-in Processing, or STIP.
STIP uses rules the issuer configured in advance, but they are simpler than the issuer’s live decision engine. Amount caps, count caps, and merchant restrictions are usually more conservative. When the issuer comes back online, the stand-in transactions are reconciled.
Key takeaways
- The issuer decides in tens of milliseconds by running a sequence of gates: card status, available balance, risk score, velocity, merchant/country rules, and account health.
- A healthy balance only clears one gate. Risk, velocity, geography, or card-status rules can decline a fully funded transaction.
- Authorization places a hold; settlement moves the money. Pre-authorizations explain why holds and final charges often differ.
- Decline codes are either hard or soft, and either issuer-side or network-side.
- STIP keeps payments alive when the issuer is offline, using simpler, more conservative rules.