Card Authorisation Lifecycle. A practitioner deep dive into the real-time US card authorization lifecycle across credential capture, acquiring and network routing, issuer decisioning, EMV and CNP signals, PIN and security checks, fraud, approvals and declines, partial and incremental authorization, reversals, holds, timeouts, reconciliation and production controls.
Card authorization is the moment when a card transaction asks a very specific question: should this transaction be allowed to proceed now? That question is answered in seconds, sometimes in fractions of a second, but the answer depends on a long chain of data capture, cryptography, routing, account checks, fraud controls, network rules and issuer decisioning.
Chapter 27 established the participant model: cardholder, merchant, acquirer, network, issuer and the processors and service providers around them. Chapter 28 now follows one transaction through the real-time authorization path. Chapter 29 will take over after authorization and explain clearing, interchange, settlement and merchant funding. Chapter 30 will separate credit, debit, prepaid, EBT and closed-loop product behavior. This chapter therefore goes deeply into authorization, while keeping later lifecycle stages in their proper chapters.
The most important learning principle is this:
Authorization is a real-time risk and availability decision. It is not the same thing as clearing, settlement, posting or final merchant funding.
A transaction can be authorized and later reversed. It can be authorized for one amount and cleared for another within applicable rules. A merchant can fail to receive an issuer response even though the issuer processed the request. A network may make a stand-in decision when an issuer is unavailable. An authorization hold can affect a cardholder’s available funds or credit before any final clearing record arrives. Those realities make authorization one of the most operationally sensitive parts of card processing.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–6 and Sections 9–15. For the next 10 minutes, use the chapter’s three diagrams to follow the authorization decision, hold and uncertain-response states. Use 10 minutes to work through the merchant-timeout situation in Section 13, then spend the final 5 minutes explaining: What evidence should control a retry when the merchant timed out after an issuer approval? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- What authorization really means
- The end-to-end authorization chain
- Credential capture and point-of-interaction data
- Merchant, gateway and acquiring-side processing
- Network routing and message transport
- Issuer host, account and card-state checks
- EMV, cryptograms and card-present authorization
- Card-not-present authorization and digital commerce
- PIN, CVV/CVC/CID, AVS and authentication signals
- Fraud scoring, limits, velocity and decision orchestration
- Approval, decline, referral and response semantics
- Partial approval, estimated and incremental authorization
- Reversals, timeouts, duplicates and uncertain outcomes
- Authorization holds, clearing handoff and financial truth
- Reconciliation, reporting and real-bank operations
- Architecture, testing, controls and authoritative references
1. What authorization really means
Authorization is a permission decision made before the merchant treats the transaction as accepted for payment processing. In the common card model, the merchant or acceptance device creates an authorization request, the acquiring side transports it to the relevant network, the network routes it to the issuer or issuer processor, and the issuer returns a decision. Visa describes this flow explicitly: merchant to acquirer, acquirer to VisaNet, VisaNet to issuer, then the response returns through the same chain. Mastercard rules similarly distinguish acquirer and issuer authorization responsibilities.
Authorization is not a guarantee that every later event will complete perfectly. It indicates that, based on the data available and the applicable rules at that moment, the transaction has been approved, declined or otherwise responded to. The issuer may place a hold against available credit or deposit funds. Later clearing data confirms the financial transaction that is presented for settlement. If the transaction is cancelled or the amount changes, authorization reversals or adjustments may be required.
The decision combines several categories of truth. Credential truth asks whether the card or token is valid. Account truth asks whether the underlying account is open, sufficiently funded or within credit availability. Risk truth asks whether the transaction looks fraudulent or violates controls. Channel truth asks how the credential was captured: chip, contactless, magnetic stripe fallback, keyed, e-commerce, stored credential or wallet token. Merchant truth includes MCC, location, terminal and acceptance attributes. Network truth includes routing, product and transaction-type rules. A robust issuer does not decide using only one of these dimensions.
Authorization also has a customer-experience role. Approval must return quickly enough for a checkout to feel immediate. A slow but technically correct issuer can still create abandoned purchases and merchant complaints. Decline quality matters as well. A generic decline may be valid from a network perspective but difficult for customer service to explain. Banks therefore need a controlled mapping between internal decision reasons, network response codes, merchant-visible responses and customer-facing explanations.
The most dangerous conceptual mistake is to treat an authorization response as the final financial state. Approved does not mean settled. Declined does not necessarily mean the issuer never saw the request. Timeout does not mean declined. Reversed does not mean the clearing record has disappeared. Chapter 28 teaches those distinctions because they drive duplicate prevention, customer support and reconciliation.
2. The end-to-end authorization chain
A simple retail purchase typically begins when the customer presents a card or card credential. At a physical merchant this can be chip, contactless, magnetic stripe fallback or another supported interaction. In e-commerce it may be a PAN or network token, expiry date, security code and other checkout data. In a stored-credential transaction the merchant may use a previously stored payment credential under applicable rules and indicators.
The merchant’s payment application or terminal packages transaction data and sends it to the merchant’s gateway, payment facilitator, processor or acquirer according to the merchant setup. The acquiring side validates that the merchant is configured, the transaction type is permitted, required fields are present, and routing data is available. It then creates or forwards the network authorization message.
The card network identifies the destination issuer using network reference data associated with the credential, product and routing configuration. It performs network-level validation and routing and may add network services or risk information. Under defined circumstances, some networks can provide stand-in processing when the issuer is unavailable or does not respond within applicable conditions.
The issuer or issuing processor receives the request and performs a sequence of checks. Typical checks include card status, expiry, account status, available funds or credit, transaction amount, product rules, country or merchant restrictions, fraud score, velocity, PIN or other verification results where applicable, EMV or token data, merchant and MCC controls and customer-specific settings. The sequence may be implemented as a single authorization platform or as calls to multiple services.
The issuer then returns a response. The response travels network → acquirer/processor → gateway/merchant → terminal or checkout application. The merchant completes or rejects the sale based on that response and applicable rules. At the same time, the issuer records the authorization event and may create an authorization hold.
In production, every hop can fail independently. A merchant can submit the request twice. The gateway can time out after forwarding it. The acquirer can receive a network response but fail to deliver it to the merchant. The issuer can approve but the network response can be lost downstream. For this reason, a real authorization architecture needs end-to-end correlation identifiers, duplicate detection and reversal logic, not just request/response APIs.
3. Credential capture and point-of-interaction data
Authorization quality begins before the request reaches the issuer. The way the credential is captured influences both security and liability. A chip transaction carries EMV data generated by the card or tokenized device. A contactless transaction carries similar cryptographic evidence through the contactless interface. Magnetic-stripe fallback has a different risk profile. Manually keyed transactions and e-commerce transactions lack the same physical-card evidence and therefore depend more heavily on additional data and risk controls.
The terminal or checkout environment captures the purchase amount, transaction currency, card or token data, merchant and terminal identifiers, entry mode, condition codes, merchant category, POS capability and other data required by the network and transaction type. Poor data quality at this stage can cause unnecessary declines or weaken fraud detection.
Entry-mode accuracy is essential. An issuer may apply different risk thresholds to chip, contactless, magstripe fallback, keyed and e-commerce transactions. A terminal that incorrectly labels fallback traffic as chip traffic can corrupt fraud models and liability analysis. Conversely, a legitimate contactless transaction misclassified as card-not-present may receive inappropriate issuer treatment.
Tokenized wallet transactions add additional attributes, such as token-related identifiers and assurance information. The issuer still authorizes against the underlying account, but the credential presented to the merchant can be a network token rather than the underlying PAN. The authorization engine must therefore understand token-to-account relationships and token lifecycle state.
For card-present PIN transactions, PIN data must be handled in protected cryptographic form. PCI PIN Security focuses on secure management, processing and transmission of PINs and associated cryptographic keys. PIN blocks are not ordinary application data and should not be copied into generic logs, data lakes or observability platforms.
For e-commerce, security codes such as CVV2, CVC2, CID or CAV2 may be captured for the specific authorization. PCI DSS treats these as sensitive authentication data and prohibits storage after authorization. This is a critical architecture constraint: a system may legitimately transmit the value for the authorization request, but it must not turn it into a reusable stored customer field.
4. Merchant, gateway and acquiring-side processing
The acquiring side does more than relay bytes. It normally validates merchant entitlement, transaction type, currency, amount ranges, terminal or channel configuration, message completeness and network routing. A payment facilitator or gateway may perform some of these steps, but the acquirer remains responsible under the applicable network model for the acquiring relationship and transaction submission.
A merchant terminal may first create a local transaction identifier. The gateway can add its own request ID, and the acquiring processor can add network-facing trace and reference values. Good architecture preserves all of them. When a merchant asks why a customer was charged twice, operations may need to correlate merchant order ID → gateway transaction ID → acquirer trace → network reference → issuer authorization record.
Acquiring-side duplicate controls are important because retries are common. A POS may resend after a communications interruption. An e-commerce merchant may retry an API call after a timeout. A gateway must distinguish a safe technical retry of the same transaction from a genuine second purchase. Idempotency is therefore both an API design problem and a financial-control problem.
The acquirer may also perform merchant-side risk controls. These can include merchant status, velocity, fraud rules, terminal validation, prohibited transaction types, unusual amount patterns and transaction-laundering controls. These checks do not replace issuer fraud decisioning; they protect a different side of the ecosystem.
If the acquirer cannot reach the network, the transaction may fail before issuer submission. That is a very different state from a transaction that reached the issuer but whose response was lost. Operational systems should preserve the submission boundary explicitly, for example NOT_SUBMITTED, NETWORK_SUBMITTED, ISSUER_RESPONSE_RECEIVED, RESPONSE_DELIVERY_FAILED. Without that distinction, recovery teams may issue unsafe retries.
5. Network routing and message transport
The network’s authorization role is to validate, route and transport the authorization request and response between the acquiring and issuing sides, while applying network-level rules and services. Network routing is based on credential and participant reference data, product configuration and transaction context.
The network can perform message validation before forwarding. Invalid messages may be rejected at the network layer without reaching the issuer. This distinction matters when interpreting declines and technical errors: not every negative outcome is an issuer decline.
Networks also support additional decisioning services. Visa may authorize on behalf of an issuer under defined conditions, and Mastercard provides Stand-In Processing Service as part of its authorization framework. Stand-in exists because commerce cannot simply stop every time an issuer host becomes temporarily unreachable. But stand-in is controlled, not arbitrary. The network uses issuer-configured or network-defined parameters, limits and risk criteria.
A bank must know which decisioning layer responded. “Approved” should be accompanied internally by an authorizing_entity or equivalent attribute indicating issuer, network stand-in or another permitted decision source. Mastercard gateway documentation explicitly distinguishes the entity that authorized the transaction. This matters for fraud review, incident analysis and customer servicing.
Routing latency also matters. Authorization platforms are usually designed for very low end-to-end response times. Banks should measure internal issuer-processing latency separately from network latency and merchant/acquirer latency. A single overall “average response time” can hide the actual bottleneck.
Network identifiers must be preserved into clearing and dispute processes. Authorization cannot be treated as an isolated ephemeral event because later clearing and reversal messages need to correlate back to it.
6. Issuer host, account and card-state checks
When the issuer receives the request, the authorization engine begins by establishing whether the credential and account are eligible to transact. A typical sequence checks card or token status, expiry, activation status, lost/stolen block, account status, available funds or credit, product constraints, geographic restrictions, merchant category restrictions, cash or quasi-cash rules, velocity and fraud.
Available balance logic depends on product. For debit, the bank may consider ledger balance, available balance, existing holds, overdraft rules and account restrictions. For credit, the issuer considers credit limit, available credit, cash limits where relevant, temporary overrides and outstanding authorizations. Prepaid and EBT have their own product logic, which Chapter 30 will cover separately.
Card status is rarely just ACTIVE/BLOCKED. Real systems may distinguish activation pending, temporary customer lock, fraud block, lost, stolen, compromised, expired, replaced, closed or restricted. The authorization engine needs a controlled mapping from these states to permitted transaction types and network responses.
The issuer may also check card-control preferences such as international usage, online usage, contactless, ATM, merchant category or amount controls. Customer-facing “card controls” in mobile banking are only useful if they feed the authorization decision in near real time.
The authorization system must protect against stale account truth. If balances are replicated asynchronously from the core banking system, an issuer can accidentally authorize against an outdated available balance. Banks therefore need a clearly defined source of truth, reservation model and consistency design between card authorization and account posting.
Issuer processing should produce an internal decision record richer than the network response. A useful record contains request timestamp, credential/token reference, account, merchant, amount, entry mode, risk score, rule hits, available balance before decision, hold amount, internal decision code, network response mapping, authorizing entity and correlation IDs. Sensitive authentication data must be excluded from persistent logging where prohibited.
7. EMV, cryptograms and card-present authorization
EMV chip and contactless transactions add cryptographic evidence that helps the issuer determine whether the transaction was generated by a legitimate chip or tokenized device under expected conditions. In an online EMV transaction, the card or device can generate an authorization request cryptogram, commonly referred to as an ARQC, using transaction-specific data. The issuer or issuer processor validates relevant EMV data as part of the online authorization process.
The terminal also performs EMV processing before the request reaches the issuer. It evaluates card and terminal capabilities, cardholder verification methods, risk parameters and application rules. Depending on configuration and transaction context, the transaction may require online authorization. The issuer response can contain issuer authentication information and scripts or related data for the card/terminal to process.
EMV should not be reduced to “chip = secure.” The authorization request still needs issuer risk controls. A genuine chip can be used by a fraudster holding a stolen card. A tokenized contactless credential can be abused if the customer device or account has been compromised. EMV cryptography improves credential authenticity and transaction integrity; it does not answer every fraud question.
Fallback is operationally important. If a chip transaction falls back to magnetic stripe or another less-secure method, the issuer should receive accurate fallback indicators and may apply different controls. Excessive fallback rates can signal terminal problems, merchant configuration issues or fraud attempts.
Offline capability also needs careful terminology. Some EMV environments can support offline decisions, but the modern U.S. authorization model for many transactions is heavily online. Chapter 28 focuses on online authorization because that is where issuer risk, account availability and network response logic are exercised in real time.
For production support, EMV data should be decoded in specialist tools rather than dumped indiscriminately into support logs. Operations teams need enough visibility to identify cryptogram-validation failures, terminal capability mismatches and entry-mode anomalies without violating data-security obligations.
8. Card-not-present authorization and digital commerce
Card-not-present transactions remove the physical interaction between card and merchant terminal. The issuer therefore relies on a different evidence set: credential/token information, merchant data, IP/device attributes when provided, billing and shipping context, authentication results, historical behavior, security-code result, address verification and network risk signals.
American Express Enhanced Authorization is a good example of richer CNP decisioning. It allows merchants to send additional data such as email, IP address, shipping information and phone number so that the network/issuer decision can better distinguish legitimate customers from fraudsters. Discover Enhanced Decisioning similarly routes enhanced data to issuers so issuer models can make better real-time decisions.
3-D Secure can add customer-authentication evidence before or around authorization. It should not be confused with authorization itself. Authentication asks whether the customer interaction can be trusted; authorization asks whether the issuer will approve the financial transaction. The two processes can influence one another but are not the same state machine.
Stored credentials and recurring payments require correct transaction indicators. The issuer needs to distinguish customer-initiated and merchant-initiated contexts where applicable. A merchant that sends the wrong credential-on-file indicators can cause false declines, poor risk scoring and downstream dispute problems.
Network tokens change the credential but not the need for account-level authorization. The issuer may receive token assurance and device-related information that improves decisioning. Token lifecycle state—active, suspended, deleted or replaced—can also affect eligibility.
CNP fraud controls should avoid overreliance on one field. CVV match is useful but not sufficient. AVS match is useful but not definitive. Device reputation, behavioral history, merchant trust, transaction amount, geography, account tenure and prior fraud patterns all contribute to a better decision.
9. PIN, CVV/CVC/CID, AVS and authentication signals
Authorization carries several verification signals, but each proves something different. A PIN is used in applicable debit and other card transactions as a cardholder-verification mechanism. PIN processing requires secure cryptographic handling. PCI PIN Security applies to entities involved in PIN processing and associated key management.
A card verification value such as CVV2, CVC2, CID or CAV2 is commonly used in card-not-present transactions to provide evidence that the customer has access to information printed on or associated with the card. PCI SSC explicitly classifies these values as sensitive authentication data and prohibits their storage after authorization.
Address Verification Service (AVS) compares submitted address information against issuer-held data where supported. A mismatch is a risk signal, not necessarily an automatic decline. Merchants and issuers may use the result differently depending on transaction type and risk appetite.
EMV cryptogram validation provides transaction-specific card/device authenticity evidence for applicable chip/contactless flows. 3-D Secure authentication provides e-commerce authentication and risk information. Token assurance provides information about token provisioning and confidence. None of these is identical to “authorization approved.”
A well-designed issuer decision engine treats these as signals in context. For example, a CVV mismatch on a high-risk first-time e-commerce purchase may materially increase fraud risk, while an AVS mismatch on a legitimate customer travelling or using a different shipping address may be less decisive.
Operations should preserve verification-result codes without storing prohibited raw secrets. The system needs to know that CVV result = mismatch, not retain the CVV itself. It needs PIN-validation outcome, not a reusable clear PIN or unprotected PIN block.
10. Fraud scoring, limits, velocity and decision orchestration
Authorization is where card fraud controls become financially real. Fraud models and rules may score account behavior, merchant risk, device, geography, transaction amount, time of day, entry mode, prior declines, transaction velocity, token history, customer profile and known compromise signals.
Limits are layered. Product limits define what a card type normally permits. Customer or account limits may be lower. Cash withdrawal or cash-equivalent limits can be separate. Velocity limits can constrain number or value of transactions over rolling windows. Merchant-category restrictions can prohibit certain uses entirely. Temporary customer overrides may expand or restrict specific controls.
The authorization engine must orchestrate these controls deterministically. A poorly designed system can produce contradictory outcomes—for example, fraud engine says decline, balance engine says approve, product engine says refer. The issuer needs a precedence model that defines which decision wins and how the final reason is mapped.
The fraud engine should also distinguish hard blocks from risk scores. A lost/stolen card block is usually deterministic. A fraud score is probabilistic. Combining the two without clear precedence makes support and testing difficult.
Real-time customer interventions can occur when the issuer wants additional confirmation, but the transaction itself may still need an immediate network response. Banks should not build authorization flows that keep network sessions open indefinitely while waiting for a customer to answer a push notification.
Decisioning must also support explainability for operations. A machine-learning score can be useful, but investigators need decision reason codes, model version, major contributing factors or rule hits where appropriate, and the ability to reconstruct what the model saw at authorization time.
11. Approval, decline, referral and response semantics
An approval means the transaction may proceed under the authorization decision and applicable network rules. The issuer typically returns an authorization code or equivalent approval information. That approval becomes an important reference in later clearing and customer support.
A decline means the issuer, network or another permitted decisioning entity did not approve the transaction. Declines can arise from insufficient funds, account restrictions, suspected fraud, invalid data, expired credentials, prohibited transaction type or technical/network conditions. Internal reason codes should be richer than the external response.
A referral or similar special response may instruct additional handling in certain environments, though modern merchant flows often favor clear approve/decline outcomes. The exact network semantics should be implemented from current scheme specifications rather than assumed generically.
Stand-in approvals and declines must be identifiable. During an issuer outage, the network may respond according to configured stand-in rules. When issuer service returns, the bank needs to ingest and reconcile stand-in decisions so available funds, fraud systems and customer servicing reflect what occurred while the issuer was offline.
Response-code mapping is a governance problem. Issuer internal decision codes, processor codes, ISO message fields and merchant-facing codes may differ. A bank should maintain a controlled mapping table with ownership and versioning. Ad-hoc mappings buried in application code create inconsistent customer outcomes.
The customer-facing message also needs care. “Insufficient funds” may be appropriate in some cases, while fraud-sensitive declines should not expose control logic. Customer service should receive a reason category and permitted explanation that does not reveal security rules.
12. Partial approval, estimated and incremental authorization
Authorization amount is not always simple. Some transaction types require flexibility because the final amount is unknown when the customer first presents the credential.
A partial approval occurs where supported when the issuer approves less than the amount requested. This is common in certain debit/prepaid or merchant scenarios where the remaining amount can be paid using another method. The merchant must understand the partial approval and complete the transaction according to the network and product rules rather than treating it as a full approval.
An estimated authorization is used when the merchant cannot know the final amount at the start of the transaction. Visa’s current public guidance allows estimated authorization for applicable purchase transactions and requires the estimate to be genuine rather than an arbitrary buffer. Hotels, vehicle rental, fuel and other environments can have legitimate estimated-amount needs, depending on network rules and merchant category.
An incremental authorization increases the authorized amount when the original estimate is no longer sufficient. Visa rules require linkage to the original transaction identifier for incremental authorization. This is operationally critical because the issuer must understand that the incremental request belongs to the same commercial transaction rather than a separate purchase.
If the final amount becomes lower than the amount held, a partial authorization reversal may be required to release unused funds. Visa guidance emphasizes releasing excess authorized amount rather than leaving customers with unnecessary holds. Mastercard rules similarly define full and partial reversals and require them to reference the original authorization.
This area creates frequent customer complaints. A hotel may initially authorize an estimated amount, later increase it, and finally clear a different final amount. If the issuer UI shows every event as if it were a separate charge, the customer can believe they were charged multiple times. The bank should distinguish pending authorization holds from posted transactions.
13. Reversals, timeouts, duplicates and uncertain outcomes
Authorization reversals are essential because the real-time path is not perfectly reliable. If a merchant cancels a transaction, if a final amount is lower, or if an authorization response cannot be delivered, the original hold may need to be reversed or reduced.
Mastercard’s public Transaction Processing Rules state that full and partial reversal messages reference the original authorization request and that an acquirer must support reversals when it cannot communicate an authorization response to the POS terminal. This captures an important principle: if the merchant does not know the result, the system must not simply leave the issuer hold unmanaged.
A timeout is not automatically a decline. Consider this sequence: issuer approves → network receives approval → acquiring processor receives approval → gateway times out before the merchant receives it. The customer may retry. If the retry is treated as a new purchase, two valid authorizations can exist. The original should therefore be correlated and, where appropriate, reversed rather than ignored.
Duplicate detection must work across retries. Useful keys can include merchant transaction identifier, network transaction identifier, amount, merchant, credential/token, timestamp window and other scheme-specific references. The exact algorithm should avoid both false duplicates and double authorization.
The system should preserve an uncertain outcome state when submission occurred but final response delivery is unknown. Operations can then reconcile using network/acquirer/issuer records rather than forcing the transaction into FAILED prematurely.
Reversal processing must be idempotent as well. Multiple technical reversal attempts should not create multiple financial effects. The issuer should match reversals to the original authorization and adjust the hold safely.
14. Authorization holds, clearing handoff and financial truth
When an issuer approves, it commonly reserves funds or credit. This reservation is an authorization hold. The hold reduces what the customer can spend but is not the same as a final posted transaction.
The hold should be linked to the future clearing transaction. When clearing arrives, the issuer matches the clearing record to the authorization using network and transaction references. The final posting consumes or replaces the hold according to product and processor logic. Chapter 29 will explain clearing and settlement in depth.
If clearing never arrives, the hold eventually needs to expire or be released according to issuer and network rules. If clearing arrives for an amount different from the authorized amount, the issuer must determine whether the difference is permitted and how much of the hold is consumed or released.
This is where customer-facing pending transactions come from. A mobile banking app may show an authorized purchase as “pending.” That status should mean pending final posting, not that the issuer is unsure whether it approved. Customer-facing design should separate authorization approved/pending clearing from authorization outcome unknown.
A useful internal financial-state model is:
REQUEST_RECEIVED → DECISIONED → APPROVED → HOLD_CREATED → CLEARING_EXPECTED → CLEARED/POSTED
Alternative states include DECLINED, REVERSED, PARTIALLY_REVERSED, EXPIRED_UNCLEARED, STAND_IN_APPROVED, STAND_IN_DECLINED, OUTCOME_UNKNOWN and CLEARING_MISMATCH.
The issuer’s ledger and authorization platform must agree on hold release. A common defect occurs when an authorization is reversed in the card platform but the core account hold remains, or vice versa. Reconciliation must therefore compare not only network messages but also the account reservation state.
15. Reconciliation, reporting and real-bank operations
Authorization reconciliation begins with transaction counts and values but should go deeper. The bank needs to know that every authorization request received has a controlled terminal state, every approval has a corresponding hold or approved-exposure record, every reversal has adjusted the original authorization correctly, stand-in decisions have been ingested, and clearing records can be matched to their authorization history.
Operational dashboards should track approval rate, decline rate, issuer response time, network response time, stand-in volume, timeout volume, reversals, partial approvals, duplicate attempts, EMV fallback, CVV/AVS results where appropriate, fraud-score distributions and clearing-match rates.
Approval rate must be segmented. A falling approval rate might indicate genuine fraud, a bad rule deployment, stale balances, a network problem, a merchant configuration change, a token issue or an issuer host slowdown. Overall approval rate alone does not identify the cause.
Issuer operations should maintain queues for unmatched reversals, stand-in reconciliation, excessive pending holds, duplicate authorizations, clearing-without-authorization, authorization-without-clearing and technical errors. These queues need ageing and ownership rather than remaining as ad-hoc support cases.
Customer service should be able to search by customer/card, merchant, amount, authorization code, network reference and timestamp. It should see whether the transaction was approved, declined, reversed, still pending, cleared or expired without exposing prohibited sensitive authentication data.
Fraud teams need the exact authorization-time evidence. Finance needs hold and clearing reconciliation. Technology operations need latency, error and availability metrics. Product needs approval/decline trends. Merchant/acquiring support needs network-response evidence. A single operational record should therefore support multiple role-specific views.
16. Architecture, testing, controls and authoritative references
A bank-grade authorization architecture usually contains a network interface, message parser/validator, duplicate-control layer, card/token lookup, account and available-balance service, card-control service, fraud decision engine, PIN/cryptography interfaces where applicable, EMV validation capability, limit/velocity controls, authorization decision orchestrator, hold/reservation service, response mapper, reversal processor, event/audit stream and operational observability.
The most important architecture property is deterministic state ownership. Every request should have one authoritative authorization state and one controlled financial-reservation effect. Retries should not create duplicate holds. Reversals should reference original authorizations. Stand-in transactions should be reconciled back into issuer truth. Clearing should link to authorization rather than creating an unrelated posting.
Testing must include more than happy-path approve and decline. A serious Chapter 28 test pack should include valid approval, insufficient funds, fraud decline, lost/stolen card, expired card, invalid CVV, PIN failure, AVS mismatch, EMV cryptogram issue, contactless, fallback, tokenized wallet, stored credential, merchant-initiated transaction, partial approval, estimated authorization, incremental authorization, partial reversal, full reversal, merchant timeout after issuer approval, acquirer timeout, duplicate retry, issuer outage with stand-in, reversal retry, hold release, clearing mismatch and authorization expiry.
Performance testing should measure both throughput and tail latency. Authorization platforms can look healthy at average latency while p99 latency creates checkout failures. Resilience testing should simulate issuer-host loss, fraud-engine slowness, network connectivity failure, balance-service degradation and recovery after stand-in.
Security controls must enforce PCI requirements. Sensitive authentication data such as CVV/CVC/CID values and PIN-related data must not be retained in prohibited ways after authorization. Logging, tracing and analytics designs must be reviewed specifically for card data rather than assuming generic application logging is safe.
The learning boundary is now complete: Chapter 27 taught who participates; Chapter 28 taught how the real-time authorization decision happens. Chapter 29 can now begin with the approved transaction and explain clearing, interchange, settlement and merchant funding without repeating authorization.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.