Card-Present Acceptance and POS Operations. Physical card acceptance across terminal readiness, chip and contactless interaction, US debit routing, uncertain outcomes, store controls, capture, settlement and merchant reconciliation.
At a busy grocery checkout, a customer taps a debit card, hears a sound and begins packing. The cashier sees a different message: the till is still waiting. Somewhere between the reader, the store network and the acquiring processor, the response has been delayed. The customer believes the payment worked. The merchant needs to know whether to release the goods. The issuer may already have reserved funds. The acquiring bank needs evidence before anyone tries again.
That moment is where Chapter 31 begins. Chapters 27–30 established the participants, authorization, financial processing and underlying card products. This chapter brings those foundations into a physical acceptance environment: the terminal, point-of-sale application, merchant configuration, debit routing, device security, capture and store operations. Chapter 32 follows remote checkout and wallet provisioning; Chapter 34 owns the full dispute process.
A working reader is only one part of acceptance. The sale, payment attempt, terminal decision and financial record must remain connected when something fails.
For a roughly 60-minute core session, spend about 35 minutes on Section 1, Sections 4–5, Section 8 and Sections 12–13. For the next 10 minutes, use the chapter’s three diagrams to trace a terminal timeout through inquiry and financial reconciliation. Use 10 minutes to work through one case in Section 15, then spend the final 5 minutes explaining: What should the store establish before asking a customer to tap again? 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.
The merchants, amounts and incidents below are fictional learning examples. Internal field and state names illustrate implementation choices, not prescribed network formats. Technical specifications and network requirements should be applied using the versions approved by the acquiring processor for the actual deployment.
Chapter navigator
- What physical acceptance must achieve
- The store and acquiring responsibilities
- Preparing a terminal for production
- The purchase from basket to financial handoff
- Chip contactless and verification
- US debit application selection and routing
- Terminal and host data
- Timeouts reversals and uncertain outcomes
- Offline processing and fallback
- Split tender tips fuel and unattended acceptance
- Protecting the terminal estate
- Batch close settlement and merchant funding
- Reconciliation accounting and store reporting
- Bank implementation and operational ownership
- Worked cases and acceptance testing
- Role checklist and learning closure
1. What physical acceptance must achieve
Physical acceptance connects a commercial sale to an approved method of paying for it. The basket establishes what the merchant is selling. The payment request establishes what the customer is being asked to pay. The terminal captures the credential and performs the supported interaction. The acquiring path carries the transaction toward the relevant network and issuer. The store needs a reliable outcome before closing the tender.
Those responsibilities should not be represented by one database row with a single success flag. A basket can contain two tenders. One tender can have several technical attempts. One successful authorization can later produce a financial presentment. An abandoned sale can require a reversal. A return visit can produce a refund linked to the earlier purchase. Chapter 29 explained those financial events; the acceptance platform must preserve their origin.
Consider a $90 purchase funded by a $30 gift card and a $60 debit card. The gift-card redemption succeeds but the debit request fails. The basket is not paid simply because one payment succeeded. Staff need either to collect the remaining $60 or follow the approved cancellation process for the completed gift-card tender. Treating the basket as the unit of payment retry could redeem the gift card twice.
The customer-facing promise should therefore be precise. A reader sound can indicate that the device read a credential; it is not necessarily the final payment decision. A till should show whether payment is approved, declined, awaiting confirmation or cancelled. Staff instructions must distinguish these states without requiring cashiers to interpret network codes.
Physical presence also does not guarantee chip processing. A card keyed manually at a counter has different acceptance evidence from an EMV transaction. The classification must describe the actual capture method and applicable network treatment, rather than relying solely on the customer's location.
Designing around the moment goods leave the store
The acceptance requirement becomes clearer when the retailer defines the irreversible commercial action. At a grocery store, it is normally handing over the basket. At a car park, it may be opening the exit barrier. At a restaurant, the meal has already been consumed, so the payment process is collecting an existing obligation. These businesses cannot all recover from an uncertain payment in the same way. The acquiring bank should understand the merchant's actual handover point before recommending a terminal workflow.
Consider a home-improvement retailer selling a $640 power tool. The store application knows the inventory item and warranty details. The terminal knows the payment interaction. Neither automatically knows whether the customer walked away with the tool. If the terminal approves but the register crashes before recording the tender, staff need a way to retrieve the payment without inventing another sale. If the register records approval but the terminal never submitted the request, the retailer instead faces an unpaid sale. The same customer complaint can therefore originate on either side of the interface.
A useful acceptance requirement describes the evidence needed for release: the tender belongs to the current basket, its amount and currency match, the response comes from the configured payment service, and the outcome is final enough for the merchant's approved acceptance policy. This is a business rule implemented across systems, not merely a green button. The register should retain the evidence even if the customer does not request a receipt.
Cancellation before release also deserves a precise meaning. Removing an item from an unpaid basket is an inventory operation. Cancelling a tender after submission is a payment operation. Cancelling a completed sale can involve stock, tax, refund and receipt effects. If all three are labelled void, a cashier can take an apparently sensible action that updates only one system. The bank's merchant-support training should distinguish the commercial intention from the processing action the terminal actually performs.
The retailer can translate this into a small number of observable outcomes: goods released with payment evidence, goods retained while payment is uncertain, goods released under an explicitly approved exception, or sale abandoned with payment effects resolved. Exceptions need an owner and a record. This gives operations a way to measure acceptance quality beyond the percentage of transactions that received an approval response.
2. The store and acquiring responsibilities
The POS application usually owns the basket, prices, tax, discounts and sale reference. A payment application or terminal integration receives the amount and transaction type. The terminal handles the supported card interface and verification interaction. A gateway or processor connects the merchant environment to acquiring services. The acquiring bank remains responsible for its merchant relationship and the obligations it has accepted under the network arrangement.
A semi-integrated design can keep sensitive card handling inside the payment device and approved processing path while returning a limited transaction result to the till. That can reduce exposure, but its security scope depends on the actual solution. An architecture diagram saying “encrypted terminal” does not establish that the whole store environment is outside PCI DSS scope.
Operations needs an ownership map that survives vendor boundaries. If a replacement terminal reads cards but cannot communicate with the host, the store cannot be left between a terminal supplier saying hardware works and a processor saying no transactions arrived. Each transaction should identify the merchant, location, terminal, processor route and relevant software configuration so the incident can be assigned.
The merchant identifier is especially important. Two stores can share a brand while having different legal owners, acquiring contracts or funding arrangements. A terminal configured under the wrong merchant can produce technically valid payments credited to the wrong merchant ledger. An authorization approval will not detect that commercial configuration error.
Refund permissions, settlement-bank maintenance and terminal administration should also have distinct entitlements. A cashier who can accept a sale does not automatically need permission to issue an unlinked refund or change the account receiving merchant proceeds. The bank and merchant should agree which actions require supervisory approval and which evidence is retained.
Following responsibility through a multi-store merchant
Imagine a retailer with a head office, forty stores and two franchise owners. Head office negotiates the POS software. Each legal merchant has its own acquiring agreement. A support company replaces terminals, while a processor manages the host connection. The customer sees one brand, but five different organizations may be involved in resolving a failed sale. The acquirer should establish which party can authorize configuration changes, view transaction evidence and instruct financial corrections for each merchant relationship.
Store and terminal identifiers should be mapped to those legal relationships through effective dates. A franchise transfer is a particularly revealing case. The physical shop, staff and equipment can remain the same while the merchant entitled to proceeds changes. If the acquiring profile changes at the wrong time, transactions can be allocated to the previous owner. Repair then involves financial reallocation and contractual evidence; it is not solved by changing the name printed on tomorrow's receipts.
Operational access should follow the same boundaries. A regional manager may need to inspect sales across several stores but should not necessarily issue refunds across all franchise entities. A processor help desk may diagnose a communication fault without authority to change the funding account. A field technician may install a replacement device without being allowed to choose a new merchant identifier. These distinctions prevent a service action from becoming an unauthorized financial instruction.
The bank should agree an escalation package that the store can assemble quickly. It can include the store reference, terminal serial number, masked receipt information, local time with time zone, amount, observed message and whether the goods were released. The package should also say whether another tender was accepted. This last fact is often more useful than a long screenshot of an application error because it tells the investigator whether duplicate collection is a possibility.
Head office needs a different view: the number of affected locations, common software version, concentration by processor route and total uncertain exposure. The bank can then distinguish an isolated damaged reader from a rollout incident. Customer communication should remain local and specific, while technical recovery can be coordinated centrally. The responsibility model is successful when the store does not have to decide which organization is at fault before someone accepts ownership of the incident.
3. Preparing a terminal for production
Production readiness includes the device, its payment software and its connection to the acquiring host. EMVCo distinguishes component testing from Level 3 integration testing. Its Level 3 framework supports testing that the deployed terminal integrates correctly with the acceptance infrastructure; payment-system participants define applicable test requirements. A hardware approval alone is not proof that every merchant configuration works end to end.
A practical rollout record should identify the terminal model, approved kernel and application versions, supported interfaces, acquiring configuration, key-management arrangements and deployment owner. The record should also capture the merchant and terminal identifiers assigned to the device. This is recommended change-control evidence, not a universal network file layout.
Testing needs to include the business features actually sold to the merchant. A basic purchase approval does not prove support for partial approval, gratuity adjustments, cashback, unattended operation or the debit routes the merchant expects. A configuration certified for one processor or use case should not be assumed valid after a routing or software change without checking the applicable requirements.
The rollout should have a controlled financial test. Operations checks that the test sale appears under the correct store and terminal, enters the intended capture process, reaches the right merchant ledger and can be reconciled. A low-value refund should be checked where permitted. Testing must use approved test credentials or a controlled production verification arrangement, rather than exposing genuine card data in development tools.
Estate management continues after installation. Replacement devices, expired certificates, application updates, changed network parameters and merchant ownership changes all create configuration risk. A bank supporting thousands of stores needs a way to identify exactly which terminals received a release and to halt or reverse that release if failures concentrate in that group.
A rollout that proves financial readiness
A terminal acceptance test should follow the configuration that will actually reach the shop floor. The relevant unit is the combination of hardware, payment application, kernel configuration, merchant profile, connection and host adapter. A laboratory result for a component supports only part of that chain. A bank can ask for a deployment inventory linking the approved combination to each store, while leaving the formal test authority and approval process with the applicable participants.
In an illustrative rollout, a retailer first enables three stores with different trading patterns: a normal staffed checkout, a high-volume self-checkout location and a store that supports partial tender. Operations observes a controlled set of purchases and reversals through the merchant reports. The aim is to catch functional differences that a single successful purchase would miss. A cashier prompt can be technically valid yet unsuitable for the way a self-checkout customer moves through the basket.
The bank should define what stops the rollout. Examples of internal stop conditions include transactions attributed to the wrong merchant, unexplained duplicate tenders, missing capture records or an increase in unresolved responses. These are proposed operational gates, not industry thresholds. A merchant may tolerate a cosmetic receipt defect briefly; it should not continue distributing a configuration that cannot establish whether sales were paid.
Rollback also needs a financial plan. Reinstalling the previous application version does not erase requests already transmitted by the new one. The release team should preserve pending records and confirm that the restored software can identify them. If a new version changed reference generation, operations may need a translation or lookup mechanism for the transition period. Otherwise the apparent technical recovery can make the outstanding financial cases harder to investigate.
Device replacement introduces similar issues. A replacement reader can inherit the store role but should have its own device identity in the estate register. Before retiring the original device, establish whether it holds any eligible unsubmitted transactions or unresolved local records. Secure retirement and financial closure are separate tasks. The acquiring bank should require evidence appropriate to both, rather than considering the change complete as soon as the replacement accepts a test tap.
Finally, the merchant needs a support handover containing the deployed versions, known restrictions and recovery contacts. This allows the first weekend support team to act on the production configuration instead of rediscovering decisions made during certification.
4. The purchase from basket to financial handoff
The following diagram uses a dual-message purchase as its main path. In a single-message financial flow, the initial transaction also carries financial processing intent; later interbank settlement and merchant funding remain distinct. The diagram does not claim that every card transaction uses a separate capture batch.
For the normal dual-message path, the POS creates a tender for the exact basket amount. The terminal performs the supported card interaction and sends the request through the acquiring path. The issuer or an authorized stand-in service makes the applicable decision. The response returns to the terminal and POS. Only when the store has a reliable outcome should it mark the tender approved and complete the sale under its procedures.
The acceptance record then feeds capture. Depending on the merchant solution, capture may occur automatically, after a separate merchant instruction or through batch close. The store must know who owns that trigger. If both the gateway and a local store service believe the other will capture, approved sales can remain unsubmitted.
The financial stage follows the model in Chapter 29. Clearing communicates financial transaction details and establishes obligations under network rules. Settlement discharges the relevant participant obligations through the designated settlement arrangements. The acquiring side calculates merchant proceeds and funds the merchant according to its contract. The terminal does not move money between Federal Reserve accounts when it displays an approval.
This sequence creates several independently recoverable records: the commercial sale, tender, authorization attempt, capture record and financial event. They should be linked without being collapsed. That is what lets the bank investigate a merchant who says, “The receipt printed, but the money never reached my account.”
Walking one sale through the interfaces
Follow an illustrative $86.40 grocery sale with one card tender. The register freezes the payable amount for that tender and sends the terminal a payment instruction. If the shopper adds an item while payment is underway, the register should not silently mutate the amount associated with the in-flight attempt. It must finish or cancel the existing operation through the supported process and create the correct next commercial state.
The terminal captures the credential and performs its configured interaction. The payment service creates a processor request that retains the merchant and device context. When the response returns, the adapter must match it to the original operation rather than whichever basket happens to be visible. This matters at a busy lane where the cashier may already have started dealing with another customer after a timeout.
After a confirmed approval, the register closes the tender and issues the appropriate receipt. In a host-capture arrangement, the processor may already hold the record that will enter financial processing. In a merchant-controlled capture arrangement, another instruction or batch event remains necessary. The acceptance specification should name the system responsible for that event and the evidence proving that it occurred. This is where a functional analyst connects a till requirement to acquiring operations.
Suppose the merchant subsequently removes one item worth $12. The commercial amount changes to $74.40, but the allowed payment action depends on the transaction state and processing arrangement. A supported adjustment before capture may differ from a partial refund after financial processing. The interface should retrieve the original transaction and expose the permitted action. It should not choose between adjustment and refund solely from the store's calendar date.
At close, the sale should be traceable through its $86.40 authorization and the later permitted financial amount or credit. The merchant report may contain several records for one customer visit. The correct reconciliation explains their relationship; it does not demand that every record have an identical amount. Where the merchant's integration lacks the original-operation reference, operations should treat that as a design gap rather than resort to unrestricted amount matching.
This walkthrough also explains why the diagram ends with reconciliation. A technically successful response is a milestone. Financial closure requires the linked records to agree with the actual sale outcome and the merchant's eventual proceeds.
5. Chip contactless and verification
EMV contact and contactless specifications define interactions between payment credentials and acceptance devices. Transaction-specific cryptographic data can support validation of the credential. Cardholder verification is a related but separate question: how the transaction establishes that the person using the credential satisfies the applicable verification method. Neither function replaces the issuer's authorization decision.
The terminal and card or device select supported behavior under the applicable configuration. Verification can involve an appropriate PIN method, a consumer-device verification method or another permitted outcome, including no cardholder verification for eligible transactions. There is no single US contactless amount threshold or PIN rule that can safely be applied to every product and network.
A phone tap can present a payment token and indicate that verification occurred on the consumer device. The cashier should not demand that the customer reveal a biometric or device passcode. The acceptance system should preserve the verification result provided by the supported interface. Device-wallet provisioning and token lifecycle are explained in Chapter 32; this chapter concerns accepting the resulting credential at the terminal.
Online PIN and offline PIN must not be confused. They differ in where verification occurs. Offline PIN does not mean the entire purchase was approved offline, and an online authorization does not necessarily mean an online PIN was entered. Store staff need a simple approved interaction sequence; the technical evidence belongs in controlled processing records.
Signature collection, where used, is also not proof that funds settled or that a dispute cannot succeed. Staff training should avoid promises such as “chip means the merchant can never lose.” Network liability rules depend on the transaction and evidence. Fraud can involve genuine credentials, stolen devices, merchant abuse or other circumstances that chip counterfeit protection does not eliminate.
Reading credential evidence without overinterpreting it
The terminal interaction produces several kinds of evidence. Entry method describes how the credential was presented. Cardholder-verification information describes the supported verification outcome. Cryptographic data supports validation under the card application. The authorization response records the payment decision. A support analyst should be able to explain these categories without assuming that any one field proves the whole transaction legitimate.
For example, a customer can use a genuine physical card that has been stolen. Successful chip processing addresses a different risk from whether the person possessed legitimate authority. A phone can perform device verification after a token was fraudulently provisioned. A payment may receive approval without a PIN because the applicable configuration supports that outcome. These examples explain why acceptance data must remain available to fraud and disputes teams, who interpret it with the wider case evidence.
The cashier's instructions should come from the certified acceptance experience. If the device asks the customer to insert the card after an unsuccessful tap, the register should present a clear next step. If it displays a decline, staff should not improvise a sequence of alternative entry methods intended to obtain any approval. The acquiring relationship should define the supported recovery path, while the retailer trains staff to recognize the difference between a read problem and a payment decision.
Accessibility is part of functional acceptance. A customer may need more time to complete a verification interaction, may have difficulty seeing a prompt or may use a device in an unexpected orientation. An integration that times out aggressively at the register while the terminal is still completing its supported interaction can create avoidable uncertainty. The application and terminal timers should therefore be understood together. Exact values belong to the approved implementation, but their relationship is a bank-operational requirement.
Receipt evidence should be consistent with the actual method used. A report that categorizes every phone payment as an online purchase or every debit purchase as PIN verified will distort both operational analysis and investigation. The bank should test the semantic mapping from the native terminal result to merchant reports. Translating detailed outcomes into a short human label is useful only when the translation preserves the important distinctions.
The goal is neither to expose sensitive technical data to store staff nor to hide all detail behind approved or declined. It is to retain precise evidence in the appropriate system and present each user with the explanation needed for their role.
6. US debit application selection and routing
US debit acceptance needs to preserve merchant routing choice among eligible enabled networks. Regulation II addresses network exclusivity and routing restrictions. Its routing provisions should not be confused with its separate interchange-fee provisions. A bank cannot assume that a small issuer's fee exemption eliminates routing obligations.
At the terminal, application selection and acquiring routing work together. Supported debit applications, including a US common debit application where applicable, can enable the acquiring path to select an eligible network. The exact terminal prompts and routing behavior depend on the card, terminal, network connectivity and merchant configuration. Selecting “credit” on a terminal does not turn a deposit-funded debit card into a revolving credit product.
The acquiring processor should retain the actual network selected, not just the international brand displayed on the card. Otherwise, a merchant can request one routing policy while financial reporting silently attributes all transactions to the printed brand. The bank then cannot explain network costs, failures or settlement-report differences.
Routing optimization must respect capability. A route that is inexpensive but cannot support the transaction's verification method, cashback feature or other required characteristic is not a valid choice. Routing decisions should be reproducible from the capability data and configuration that existed at the time, rather than reconstructed using today's tables.
An outage adds another boundary. Selecting an alternative eligible route before release is different from resubmitting a transaction whose first outcome is unknown. The second action can create two authorizations or financial transactions. The merchant's desire to complete the queue quickly does not remove the need to determine whether the first attempt already succeeded.
Proving that routing policy survives implementation
A merchant routing policy is not implemented merely because a preferences screen lists several networks. The transaction must have eligible choices, and the terminal and acquiring path must preserve the information needed to exercise the choice. A bank can test this by starting with a defined card and acceptance method, identifying the supported routes, and checking which route was actually selected for the resulting transaction.
The decision can involve merchant preferences, network capability, connectivity and transaction characteristics. A useful internal routing record retains the eligible set, selected route and relevant policy version. It need not expose proprietary optimization logic to every support user. It should, however, allow the acquirer to explain why an apparently preferred route was unavailable. Without that evidence, every difference between expected and actual cost can become an unresolved accusation that routing choice was ignored.
Consider two purchases made with the same debit card. One is a normal sale; the other includes a supported cashback request. The available routes may differ because of the transaction features. Comparing their costs without accounting for the feature can produce a misleading conclusion. A meaningful routing review groups transactions by relevant capability and acceptance context before evaluating whether merchant instructions were followed.
Operational routing changes need effective dates and rollback behavior. If an acquirer disables a failing connection at noon, it should not rewrite the route recorded for transactions submitted in the morning. A later investigation must use the historical route to locate financial records and identify the correct exception process. Reporting that simply joins old transactions to today's network configuration can make the historical processing path disappear.
The same principle applies to merchant migrations. A new processor may support a different set of interfaces or provide route information through a different report. The migration team should establish how the merchant will compare like-for-like results across the transition. It should not infer a routing failure from a change in descriptive labels alone, nor accept improved approval rates as evidence that every routing obligation is satisfied.
Regulation II supplies the legal routing framework described earlier. The acquiring contract supplies service commitments, and the network supplies technical and operating conditions. A well-written requirement identifies which of these establishes the obligation being tested. That prevents an internal cost preference from being presented as law, while ensuring that an implementation preference cannot override an applicable legal requirement.
7. Terminal and host data
The acceptance layer should preserve the sale reference, tender reference, attempt identifier, merchant and terminal identifiers, transaction amount and currency, capture method, verification outcome, processing route, response and relevant network references. Where permitted and required, EMV data accompanies the processing message. Sensitive values should remain within the approved card-data environment.
Many acquiring interfaces use network-specific ISO 8583-based messages, processor protocols or APIs. That does not make every field number or response code universal. A REST interface at the POS boundary can be translated into another protocol downstream. Conversely, a JSON response does not prove that the underlying financial transaction used an account-to-account rail or ISO 20022.
Requirements should define the business meaning first. For example, sale_id groups the basket, tender_id identifies one payment component, and attempt_id identifies a submission attempt. These are illustrative internal names. The host adapter maps them to the processor's supported fields and retains the returned identifiers needed for inquiry, reversal, capture and refund.
A response should retain its origin. A gateway validation reject means something different from an issuer decline, even if both produce a red checkout screen. A device-read error may mean no request left the terminal. A host timeout may mean a request was accepted but the response was lost. Losing these distinctions creates unsafe retry logic.
Receipts and support screens should use masked information and useful references. Full track data, card verification codes and PIN data must not be copied into application logs or incident tickets. A well-designed investigation record gives operations enough information to locate the transaction without recreating a repository of sensitive authentication data.
Building a payment record that operations can use
At the POS boundary, the data contract should answer four questions: what sale is being paid, what operation is requested, what evidence identifies its outcome, and which later operations may refer to it. A bank can document this in business terms before mapping the fields to a specific host. This keeps the requirements useful even when one merchant uses a local terminal protocol and another uses a cloud payment API.
For the $86.40 example, the sale reference identifies the customer basket. The tender reference identifies the portion assigned to a card. The attempt reference identifies one submission. The processor's transaction reference identifies its record. A network reference, where provided, supports the downstream trace. These identifiers are related, but their cardinality differs: one sale can have several tenders, and one tender can have several carefully controlled attempts.
Amount data also needs explicit meaning. Requested amount, approved amount, captured amount and credited amount should not share an unlabeled numeric field. Partial approval makes this particularly important. The adapter must return the approved amount to the register, and the register must calculate the remaining basket balance. A data-mapping test should verify the amounts and currency together, including the host's representation of decimal places. A formatting defect can become a financial defect if a parser treats minor units as whole units.
Timestamp handling deserves equal care. The store may record local time, while the gateway records UTC and the processor groups records by a processing cycle. Store time should include enough context to resolve daylight-saving ambiguity. Sequence and native identifiers are usually stronger evidence than a timestamp alone when several requests are close together. The bank should not rely on perfectly synchronized clocks as its only duplicate-control mechanism.
Error records should retain both the native outcome and a controlled business interpretation. A translated label such as service unavailable can be helpful, but the original source and operation must remain retrievable. If a processor changes its response vocabulary, the adapter can then be corrected without losing the historical evidence. Unknown native values should enter a controlled exception path rather than defaulting to approval.
Data retention should support legitimate inquiry while respecting security and retention requirements. Keeping a protected transaction reference can be useful for years of financial traceability; keeping prohibited authentication data is not justified by the desire to make support easier. The requirements should specify both what survives and what must never enter ordinary logs.
8. Timeouts reversals and uncertain outcomes
Return to the grocery checkout. The issuer approved the $86.40 transaction, but the acquiring response did not reach the POS. The store should classify the result as uncertain until its supported inquiry or recovery process establishes what happened. It should not turn a local timeout into an issuer decline.
The processor may provide a transaction-status inquiry, automatic reversal behavior or other specified recovery procedures. Implementation must follow that contract. There is no universal API endpoint or timeout interval that applies to every terminal estate. A bank should verify which component sends a reversal, when it sends it and how it confirms the outcome.
An authorization reversal is a message intended to cancel or adjust the authorization effect under the applicable process. It does not refund an already settled sale. A local void button may trigger different host actions depending on the lifecycle stage. The interface should make that distinction explicit to staff, especially when a batch has already been submitted.
If the customer pays by another tender while the first attempt remains uncertain, the merchant has created a potential double-payment incident. The two tenders must be linked to the same sale and assigned for follow-up. Staff should not issue cash compensation based only on a pending entry in the customer's mobile banking app; the underlying transaction needs to be established.
Recovery should be idempotent. Repeating the same inquiry or ingesting a duplicate response should not create a new sale. Replaying a capture after a connection failure should not create a second financial record. The processor's duplicate-detection contract and the merchant's own tender controls should work together, because neither side necessarily sees all identifiers used by the other.
Recovering a timeout without charging twice
A useful timeout investigation begins with the last authoritative event at each boundary. Did the register send the instruction? Did the terminal create an operation? Did the gateway accept it? Is there an issuer or network outcome? Did a response reach the register? The investigator should distinguish observed facts from assumptions. A missing local response does not establish that the request failed at every downstream component.
Suppose the original $86.40 attempt is uncertain and the cashier accepts cash. The retailer now has a completed commercial sale funded by cash and an unresolved card attempt. The immediate objective is not another card approval. It is to establish the first attempt and remove any unintended card effect through the permitted process. The sale record should show why cash was accepted, and the card exception should remain open until its disposition is known.
If the processor confirms an approval that has not entered financial processing, the supported recovery might involve an authorization reversal or another documented cancellation operation. If financial processing has already occurred, a credit path may be necessary. The merchant should not guess from the wording of the mobile-banking pending entry. It should use the transaction lifecycle established by the acquiring service.
Recovery workers need protection against races. An automatic reversal can be queued while an operator investigates. A late approval response can arrive while the register is closing the cash tender. A capture process can run before the exception is resolved. The implementation should define which state changes prevent later capture and which actions require coordination. Otherwise, each component may behave correctly in isolation while their combined behavior produces an unwanted charge.
The recovery record should retain the original operation, the inquiry outcome, any corrective operation and its confirmation. Repeated delivery of the same result should update the same record. A user pressing the support button twice should not create two refunds. Idempotency is therefore a financial requirement spanning both automated and manual actions, with the processor's supported behavior used at the external boundary.
Closure should be based on the customer's final payment burden and the merchant's actual collection. If the card effect was only a hold, the case may close differently from a settled purchase followed by a refund. Staff should communicate that distinction plainly. They can say the original payment was cancelled or a refund was submitted when supported by evidence, rather than promising a statement appearance that the merchant cannot directly control.
9. Offline processing and fallback
Three different conditions are often called offline. An EMV transaction may support an offline card decision under its configured rules. A merchant solution may store transaction data for later submission under a permitted store-and-forward arrangement. A network stand-in service may respond when an issuer is unavailable, even though the terminal is online. These are not interchangeable operating models.
Store-and-forward can expose a merchant or acquiring participant to loss if a later submission fails. It must be enabled deliberately, with approved transaction types, limits, record protection and reconciliation. A merchant should not assume that every approved-looking local sale will later be paid by the issuer. The allocation of that risk belongs in the actual processing arrangement.
Fallback refers to using another permitted capture method when the intended one cannot be completed. A failed chip read is not permission to force a magnetic-stripe or keyed transaction whenever a cashier chooses. The supported fallback sequence and evidence requirements must come from the network and acquirer. A decline after successful chip reading should not be bypassed by repeatedly changing entry method.
Operations should monitor fallback by terminal, store, device model and software release. A sudden concentration can indicate damaged readers, configuration defects or suspicious behavior. The right response depends on the evidence. Replacing the card will not solve a broken terminal; replacing the terminal will not resolve a merchant deliberately avoiding required controls.
During an outage, the store's business-continuity plan should state which tenders remain usable, how queued transactions are protected, and how staff explain uncertainty. Restoration needs its own procedure: identify already transmitted records, submit eligible queued activity once, resolve rejects and reconcile the outage period before treating normal service as financial closure.
Managing the outage as a finite financial population
An outage should have a defined transaction population. The retailer needs to know which stores and devices were affected, when their connectivity changed, which records were transmitted, which were retained locally and which customer sales were completed. The population cannot be reconstructed reliably from complaints alone. Some customers will not notice a pending entry, while others will contact the issuer before the merchant knows a problem exists.
For a permitted store-and-forward arrangement, the release conditions should be enforced by the payment solution. Staff should not be able to turn an ordinary declined transaction into a queued transaction simply by disconnecting the terminal. The merchant's approved arrangement determines the supported use cases and allocation of loss. The bank should test that the technical controls implement those restrictions, including what happens when the queue reaches its permitted capacity.
Restoration creates a second workload. Queued transactions need to be submitted through the documented process, and each needs an outcome. A successful network reconnection does not mean the queue emptied, and an empty queue does not mean every payment succeeded. Operations should reconcile the number and value of retained records against accepted submissions, rejects and unresolved items. This is an outage-specific financial control, separate from measuring network uptime.
The store can encounter a customer who returned goods during the outage. If the original payment is still queued, a later submission without reference to that return can collect money for a sale already undone commercially. The restoration process therefore needs access to relevant sale changes. It should not release old records solely because their original creation time is within an allowed window. The permitted financial action depends on what happened to the sale as well as the processing rules.
Another case involves a device replaced before its queue is recovered. The estate team should preserve the original device's status and identify whether financial records remain accessible through the approved service. Reusing its terminal identifier on a replacement must not make old and new records indistinguishable. Where records cannot be recovered, the loss or unresolved exposure should be recorded explicitly and escalated to the responsible merchant and acquiring teams.
The final outage review should compare the business decision to continue accepting payment with the resulting losses, customer incidents and support effort. This helps the merchant choose a better continuity policy for the next incident. It should not retroactively describe locally accepted sales as issuer-approved transactions merely because most were eventually paid.
10. Split tender tips fuel and unattended acceptance
Partial approval requires the POS to understand the approved amount. For a $75 basket with an eligible prepaid balance of $50, the response may approve $50 if the product and acceptance path support it. The remaining $25 still needs another tender. A terminal integration that returns only a Boolean approval can cause the cashier to release goods after collecting too little.
If the remaining tender fails, the merchant needs a controlled way to unwind or retain the completed portion according to the sale outcome. The $50 approval should not be casually retried as part of a new $75 request. Each tender has its own lifecycle, and the basket should close only when the approved commercial payment arrangement is complete.
Restaurants introduce gratuity. Fuel dispensers introduce an amount that may be unknown before delivery. Lodging can introduce estimated and incremental authorization. The detailed authorization rules belong to Chapter 28. Here, the acceptance requirement is to preserve the original amount, permitted changes, final amount and relevant approvals so capture reflects the actual sale.
There is no universal tip tolerance or fuel preauthorization amount for the entire US market. A POS should use the acquirer's approved configuration for the merchant category and product. Staff should not learn a percentage from an unrelated processor's help page and apply it to all cards.
Unattended devices need special attention because no cashier can interpret an unusual result. A vending machine should know whether to dispense after its supported payment outcome, and it should record whether goods were actually delivered. If a motor fails after payment, the financial transaction and device-service incident need a link. Otherwise, customer support sees a valid payment while the merchant's machine log shows a failed delivery with no payment reference.
Managing more than one amount at the lane
Split tender is a small accounting model inside the register. For a $125 basket, a customer might use a $40 gift balance and seek a $85 card payment. The register should know which part is already collected, which part is merely authorized and which part remains due. It cannot use a single paid flag after the first successful tender. The commercial sale closes only when the merchant's accepted combination is complete.
Suppose the second tender fails and the customer abandons the purchase. The gift-balance restoration and the card's payment effects require their own supported operations. The register should not delete the basket until it has retained the references needed to finish those actions. A supervisor can then explain the case without asking the customer to reconstruct which card or gift credential was used from memory.
Cashback adds a physical delivery event to a debit transaction. Where the product and acceptance path support it, the retailer must distinguish the purchase component from the cash component and record the total requested operation correctly. The register also needs evidence that cash was handed over. If the payment succeeds but the cash drawer or automated dispenser fails, the remedy must address the undelivered cash through the applicable merchant and processor procedure. A purchase receipt alone does not prove physical delivery.
At a fuel dispenser, the unknown final amount creates a different relationship. The equipment should link the allowed payment operation to the actual quantity delivered and final sale amount. A communication failure after dispensing is materially different from a failure before the pump was enabled. Maintenance and payment logs should share a correlation reference so operations can determine whether there was a sale, an authorization effect or both.
Unattended parking provides another useful distinction. A barrier can fail after payment, leaving the customer charged and unable to leave. Retrying payment would not repair the mechanical fault. The system should retain the successful payment and permit an authorized service action to resolve access. If the merchant decides a refund is appropriate, it should be linked to that same visit and financial operation. The payment and equipment teams need different actions against a shared incident.
These cases show why the acquirer should review the merchant's full acceptance journey. A terminal integration can process valid messages while the surrounding business application mishandles what the customer actually receives. Testing must follow the goods, service or cash as well as the payment result.
11. Protecting the terminal estate
Physical security begins with knowing which device belongs at each location. A practical estate register includes serial number, model, location, owner and approved software configuration. Staff should be trained to recognize substitution or tampering and to report unexpected technician visits. Remote support should use controlled access, with records of who changed what and when.
PCI SSC maintains device and solution listings. A PCI-listed point-to-point encryption solution is a specific validated arrangement; it is not synonymous with any product advertised as encrypted. PCI SSC's terminal guidance explains that scope depends on the device's function and implementation, and that appropriate listed P2PE solutions can support scope reduction.
The bank should ask where card data is decrypted, who manages keys and which applications can access sensitive data. Encryption between the terminal and gateway does not answer what happens after the gateway receives it. Likewise, masking a receipt does not prove that an unmasked value was not written into an error log.
Fraud controls should use the acceptance context. Examples include unusual fallback concentration, repeated small test purchases, improbable terminal relocation, excessive unlinked refunds or refund activity outside normal trading patterns. These are suggested monitoring scenarios, not published network thresholds. Alert design should identify the owner and evidence needed to investigate each pattern.
Sanctions and financial-crime controls belong to the bank's risk-based merchant and transaction framework. A terminal receipt normally does not contain the complete party information found in a cross-border wire. The acquiring bank should not claim that every tap passes through an identical name-screening sequence. It should document how merchant due diligence, relevant transaction information and escalation processes meet its applicable obligations.
Protecting administration as carefully as the card read
A secure reader can still be attached to an insecure administrative process. A fraudulent support caller might ask a cashier to install an update, change a terminal setting or run a refund test. The bank and merchant should agree how staff authenticate support requests and verify replacement equipment. An unexpected instruction involving a payment operation should not be trusted merely because the caller knows the store's address or device model.
Remote administration should separate diagnosis from change. A support user may need to see connectivity and version information without permission to modify merchant routing or financial settings. Elevated changes should have a reason, an authorized operator and an audit record. Temporary access should end when the support task ends. These are recommended control designs; the exact implementation depends on the merchant and service provider environment.
Configuration integrity matters because a small change can redirect money or weaken evidence. The merchant identifier, host destination, enabled entry methods and refund settings are operationally significant. A release process should identify which values are centrally controlled and which the local store may adjust. Unexpected differences should generate review rather than being accepted as harmless local customization.
Fraud monitoring can use estate information to distinguish patterns. If one terminal suddenly records much more fallback than comparable devices at the same store, hardware damage or misuse may be involved. If every terminal on one software release changes behavior at the same time, a configuration defect becomes more plausible. Neither observation proves the cause, but each narrows the evidence operations should collect. Monitoring becomes more useful when it joins payment behavior to the deployed estate.
Incident handling also needs a data boundary. A technician should not request a customer's full card details through an ordinary chat to reproduce a fault. Approved test facilities and protected transaction references should be used instead. Screenshots should be checked for sensitive values before entering support systems. The bank can investigate the presence and meaning of required fields without circulating their sensitive contents to every participant.
When a device is suspected of compromise, security containment and merchant continuity must be coordinated. Removing it from service should preserve relevant evidence and identify affected transaction periods. The retailer needs a supported alternative acceptance path, and the acquirer needs to assess its own obligations. Replacing the device is one recovery action; determining the exposure and completing incident reporting are separate parts of closure.
12. Batch close settlement and merchant funding
Batch close can be a local terminal action, a merchant system action or a host-managed process. The merchant must know which one applies. A screen saying “batch closed” proves only what that system has confirmed. It may not prove that every record was accepted into network clearing, that participant settlement occurred or that the merchant's bank account was credited.
Four dates can matter: the store's business date, transaction timestamp, processing cycle date and merchant funding date. A sale shortly after midnight may belong to the previous restaurant shift but the next processor cycle. Time zones and daylight-saving changes should be explicit. Reconciliation based solely on local calendar date can create false missing-payment reports.
Cutoffs should come from the merchant's actual service arrangement. Authorization availability, capture deadlines and merchant-funding schedules are separate. A store can accept cards over a weekend while its funding product follows another calendar. No single Federal Reserve operating window determines every POS merchant's payout schedule.
Money moves through the participant settlement mechanism designated for the network and program, including settlement-bank or correspondent arrangements where used. The acquirer then owes the merchant the calculated proceeds. If it pays the merchant through ACH, that is a separate funding leg. The POS sale did not become an ACH purchase merely because the merchant ultimately received an ACH credit.
Acquiring treasury needs forecasts based on accepted financial activity and funding promises. Accelerated merchant funding can create timing exposure before the corresponding cash is available to the acquirer. An acceptance outage followed by a large backlog release can alter those forecasts. Store recovery therefore has a treasury consequence as well as a technical one.
Explaining the merchant's morning funding question
The merchant often asks about acceptance through a cash question: yesterday's tills show $48,000 in card sales, so why did the bank account receive another amount? The first step is to define the compared populations. Till totals may include approved tenders that were not captured, a store business day may cross the processor's cycle boundary, and the funding account may receive a net amount covering several stores or adjustments.
The acquiring team should begin with the merchant's funding arrangement and identify the financial report that supports the bank-account credit. It can then work backward to included clearing activity and forward from the store's accepted sales. This avoids treating the bank-account amount as if it were supposed to equal every approval recorded by the POS. Chapter 29 explains the underlying financial mechanics; the acceptance-specific task is preserving the store and tender references needed to bridge the reports.
An illustrative merchant statement could start with $48,000 of included purchases, subtract $700 of refunds and $900 of contractual fees, and show $46,400 payable before any other stated adjustments. Those are fictional figures, not a fee quotation. If the bank account receives $45,400, the remaining $1,000 requires an identified explanation such as a documented reserve movement, prior adjustment or genuine discrepancy. It should not be absorbed into an unexplained reconciliation tolerance.
Cutoff changes can alter the relationship without changing individual transactions. A retailer that moves batch close later may shift some sales into another funding cycle. The bank should explain the operational effect before the change and test the transition day, including weekends and holidays under the actual contract. Cash-flow forecasting should use the effective funding schedule rather than a remembered promise made during merchant onboarding.
Negative or delayed funding should also be visible to merchant support. A successful day of acceptance does not prevent prior refunds or dispute adjustments from reducing proceeds. Support staff should have enough report context to explain the relevant deductions without disclosing unrelated confidential information. The merchant should receive a traceable statement of the financial events, not an instruction to ask every cardholder whether they were charged.
The acceptance platform contributes by retaining correct merchant, store, terminal and sale identifiers through capture. A missing store reference may not stop settlement, but it can make a consolidated merchant unable to allocate the cash internally. Operational usefulness is therefore part of the data-quality requirement, even for fields that do not decide authorization.
13. Reconciliation accounting and store reporting
The first control compares completed sales with completed tenders. The second compares card tenders with accepted processor activity. Subsequent controls link capture, clearing, merchant ledger and funding. Counts and amounts matter at each relevant boundary. A correct net total can hide one missing sale and one duplicate sale of the same amount.
Use a fictional daily close. A store has $10,000 of completed card sales and $300 of valid refunds. Its expected gross financial activity is $9,700 before fees and other adjustments. If the processor accepted only $9,600, the $100 difference belongs in the capture or intake investigation. It should not be described as a fee merely because the merchant's eventual payout is also net of charges.
Assume the accepted amount is corrected to $9,700, and the merchant statement separately shows an illustrative $190 fee and no other adjustments. The resulting $9,510 payable should reconcile to the funding instruction and eventual bank credit. These figures are exercise assumptions, not market pricing. Network member settlement may include other merchants and network-level economics, so it is not expected to equal this store's payout.
The acquiring ledger should preserve gross merchant activity, contractual deductions and the remaining payable. The issuer independently reconciles the cardholder posting and authorization effect. If a merchant payout fails, the acquiring liability remains to be resolved; the consumer's valid purchase is not automatically reversed.
Useful store reports show payment method, actual network where available, terminal, sale reference, accepted amount, unresolved tenders and refund activity. Sensitive data should be minimized. Central operations should be able to aggregate by estate release and store cohort to identify whether a financial break began with a particular device change.
Working a reconciliation break to a specific cause
A practical reconciliation can begin with three separate populations: completed store tenders, processor financial records and merchant funding entries. Each population has a source and a defined period. The matching rules should recognize legitimate one-to-many relationships, such as a sale split across tenders or a purchase followed by a partial credit. Matching everything by equal amount and nearby time will eventually join unrelated transactions.
Consider a store with a $210 tender marked approved but no corresponding capture record. The investigator first establishes whether the processor has an authorization and whether the merchant solution was expected to capture automatically. If the authorization exists and the capture trigger failed, the issue is an uncompleted financial handoff. If no processor operation exists, the local approved flag itself may be wrong. These cases require different technical fixes and potentially different customer actions.
Now reverse the direction: the processor reports a $210 financial record, but the store has no completed tender. Operations should look for a timeout, abandoned basket or a second payment method. An unmatched processor record can represent money collected without a recognized sale, not merely a missing reporting field. The merchant must determine the legitimate commercial obligation before deciding whether to retain or return the amount.
Accounting should preserve the source of any adjustment. If operations confirms that a genuine sale was omitted from a store report, the reporting correction should not create another payment. If it confirms duplicate collection, the financial correction should remain linked to both the duplicate and the intended purchase. Posting a miscellaneous balancing entry may make totals agree while leaving the customer's problem unresolved.
The reconciliation queue should distinguish data defects from financial differences. A missing terminal identifier may require enrichment from an authorized source. An amount difference may require inquiry or correction. An expected timing difference can be monitored until its due event occurs. Each classification should have evidence, an owner and an aging basis. A timing difference should not remain indefinitely exempt from investigation simply because it was initially expected.
Management reporting should show the residual exposure, not just the number of cases closed. Ten small identifier repairs and one unresolved high-value duplicate are not equivalent operational outcomes. The bank should track whether the merchant's proceeds and the customer's final burden are correct, then use recurring break causes to improve the POS and acquiring integration.
14. Bank implementation and operational ownership
A practical acquiring implementation separates merchant configuration, terminal administration, transaction intake, network adaptation, lifecycle correlation, capture, merchant ledger and case management. These can be supplied by several vendors. The bank still needs a coherent control model across them.
Configuration should be effective-dated. Merchant ownership, terminal assignment, routing rules and funding instructions can change. A payment from last month must remain explainable under last month's configuration. Updating the current merchant record must not rewrite the historical beneficiary of prior merchant proceeds.
The transaction service should distinguish an accepted technical request from a completed payment decision. The POS adapter should return sufficient status detail for safe staff action. The capture service should record both batch-level and record-level results. The reconciliation service should identify gaps instead of inferring completion from the absence of an error.
Operational alerts should be actionable. “Terminal down” is useful only with the affected store and impact. “Approvals continuing, captures absent for one host-managed merchant group” points to a different incident. “Funding file rejected after successful network settlement” belongs to disbursement operations rather than terminal support.
An incident should close only after both service recovery and financial reconciliation. Restarting a gateway may restore new purchases while leaving an hour of uncertain transactions unresolved. A named owner should reconcile the incident interval, determine customer or merchant corrections and record whether the defect can recur during another failover.
Turning the acceptance model into implementable requirements
The functional specification should describe each business operation with its preconditions, request, possible outcomes and subsequent actions. A purchase begins from a payable basket. A status inquiry refers to an existing operation. A reversal refers to an applicable authorization effect. A refund refers to a financial credit under the supported arrangement. Keeping these operations distinct prevents a generic payment endpoint from hiding incompatible recovery semantics.
For each boundary, the bank should name the authoritative system. The POS is authoritative for basket composition. The acquiring service supplies its processing outcome. The terminal estate service supplies deployed device configuration. The merchant ledger supplies contractual proceeds. This does not imply that every institution uses separate products for those functions. It means that the design must know which record wins when copies disagree.
Non-functional requirements should connect to financial behavior. A retry policy must specify how duplicate financial effects are prevented. A recovery-time objective must account for outstanding uncertain tenders. A log-retention design must preserve correlation while excluding prohibited data. A report-delivery requirement must state whether missing or delayed reports prevent merchant funding, delay reconciliation or merely affect customer visibility. This makes operational consequences explicit during design rather than after launch.
Testing should include interrupted sequences. Stop the register after the terminal approves. Delay the host response until the cashier changes screens. Deliver the same response twice. Restart the capture worker after it sends a request but before it records success. Replace a terminal with unresolved local records. In each case, the expected result should describe the sale, payment and financial records, not only whether the application remained available.
Operations also needs a supported manual path. An operator should be able to locate the original transaction, see known and unknown facts, and request a permitted corrective action with the appropriate authority. The manual path should use the same financial safeguards as automation. A support screen that bypasses duplicate controls can defeat the rest of an otherwise careful design.
At implementation sign-off, the bank and merchant should demonstrate a complete example from sale through merchant proceeds and a complete failed example through controlled recovery. The sign-off evidence should show who owns each unresolved outcome. This gives the acquiring relationship a practical basis for operating the service when the store is busy, the customer is waiting and the normal response does not arrive.
15. Worked cases and acceptance testing
The following exercises include suggested reasoning. For each case, identify the authoritative evidence, immediate store action, bank owner and financial condition required for closure.
Case A — two receipts, one basket. A $118 purchase times out. The cashier starts another card tender and receives approval. The first attempt later also returns approved. Two issuer holds appear. The store has delivered one basket. What should operations establish before refunding anything?
First, determine whether both approvals were captured or whether one remained an authorization only. A reversal may be appropriate for the unused authorization under the processor's process. If both became financial purchases, the duplicate needs a financial correction. Link the attempts to the one sale and reconcile both outcomes. Issuing a refund without establishing capture can leave an unnecessary credit or fail to release an unrelated hold. The preventive change is a POS workflow that recognizes uncertainty and uses the supported recovery path.
Case B — replacement terminal, wrong merchant. A newly installed device processes $2,400 successfully, but the store's report shows no sales. The processor locates all transactions under another outlet's merchant identifier. Is this a customer payment failure?
The transactions may be valid customer payments with an acquiring allocation defect. Suspend or correct the device configuration and investigate the affected interval. Finance must determine whether proceeds are pending, allocated or already paid to the wrong merchant. Any correction needs controlled ledger entries and reconciliation; do not re-charge customers to repair the merchant configuration. Test installation using the correct merchant, store and funding evidence, not merely a printed approval.
Case C — partial approval treated as full. A $96 basket receives a $40 partial approval, and the till closes the sale. No second tender exists. Calculate the shortfall and identify the root cause.
The merchant has an unresolved $56 collection gap. The payment response must convey the approved amount, and the POS must keep the remaining amount open. The bank should not fabricate an additional authorization for $56. Remediation includes the actual commercial recovery decision, a corrected integration and testing of both completion and cancellation after partial approval.
Case D — recovery batch replay. An outage creates a stored queue. At restoration, the merchant uploads the queue twice because the first acknowledgement was lost. The processor's report contains duplicate accepted records. What evidence distinguishes a technical replay from two genuine purchases?
Use tender and attempt identity, original transaction references, amounts, terminal sequence information and the incident timeline. Amount and time alone are insufficient. The resolution must identify which financial records actually entered clearing before corrections are issued. Test replay at the file and record level, including a mixed batch in which some records were accepted before the connection failed.
Beyond these cases, acceptance testing should cover a clean chip purchase, contactless verification outcomes, supported debit routes, invalid configuration, rejected capture, reversal response loss, refund access restrictions and day-boundary reporting. For every test, specify the expected store display and the expected financial evidence. A test that checks only the terminal screen cannot prove the merchant will be funded correctly.
A complete incident readout
During a Saturday promotion, eight stores report customers being asked to pay twice. The retailer's incident lead initially sees a fall in register success messages and assumes that the acquiring host is declining transactions. The acquiring operations analyst compares the affected attempts and finds approvals at the processor for several transactions the stores labelled failed. The issue is now an uncertain-response incident, with possible duplicate collection, rather than a simple decline-rate problem.
The team defines the affected population by terminal application version and deployment time. It preserves original attempt identifiers and links subsequent tenders to the same baskets. Some customers used cash after the timeout; others tapped again. The team does not apply one blanket refund instruction. It first establishes which card attempts entered financial processing and which only created authorization effects. The corrective operation follows that evidence and the processor's supported lifecycle.
For one basket, the customer paid $92 by cash after a card timeout. The processor confirms the card purchase reached financial processing. The merchant owes a linked correction for the unintended card collection. For another basket, the first card attempt was cancelled through the supported recovery process and the second purchase was the only completed collection. Refunding the second merely because two attempts exist would create a merchant loss. The cases look similar at the till but have different financial outcomes.
Technology identifies a response-matching defect introduced by the new register release. The terminal response was associated with the previous screen instance and discarded after navigation. The team corrects the integration and controls further rollout. Operations then reconciles the full affected population rather than waiting for additional complaints. Customer support receives case-specific information about the correction already made and the evidence available for tracing it.
The incident closes when known duplicate collections are corrected, uncertain items have an assigned resolution, merchant reports reconcile and the repaired release demonstrates correct response handling. The learning is operationally concrete: success must be associated with the payment attempt and sale, not with the continued existence of a particular screen. That requirement would have prevented both the customer inconvenience and the later manual investigation workload.
16. Role checklist and learning closure
The Business Analyst defines sale, tender and attempt semantics, supported acceptance features, uncertain-outcome handling and reconciliation evidence. The Architect establishes the security and ownership boundaries between POS, terminal, gateway and bank. The Developer preserves response origin and implements replay-safe processing without inventing network behavior.
The Tester verifies both staff-facing behavior and the downstream financial record. Merchant operations owns configuration and store communication. Fraud and security teams monitor device integrity and suspicious acceptance patterns. Finance and Treasury connect captured activity to merchant liabilities, settlement cash and funding commitments.
Before leaving the chapter, explain the grocery timeout without using the word “failed” until you have identified what actually failed. Then explain why a batch-close receipt is different from evidence of merchant funding. Those two distinctions are central to operating physical acceptance reliably.
The store should be able to complete one sale once, and the bank should be able to prove how that sale became a financial transaction.
Authoritative references
Public sources checked on 6 September 2026. The network rules govern the applicable transaction; the architecture, controls and exercises are original learning examples. Device-specific processing, timeouts, fallback permissions and merchant cutoffs require the actual acquirer-approved implementation documents.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.