E-Commerce, Card-Not-Present, Tokenisation and Device Wallet Acceptance. Remote card acceptance across order control, EMV 3DS, token and wallet lifecycle, authorization, payment-page security, callbacks, capture, fulfilment and financial reconciliation.
A customer buys a $240 jacket on a phone. She selects a wallet, confirms with a biometric and returns to a page saying that her order is being processed. The merchant's payment service has an approval, but the order system has not received the result. The warehouse is waiting. The customer presses the button again because nothing appears to have happened.
The biometric, payment approval and order confirmation are three different events. Chapter 32 explains how a bank and merchant keep them connected across remote acceptance, token services, authentication, authorization, capture and recovery. Chapter 31 covered the physical terminal. Chapters 28–29 remain the foundation for authorization and financial processing. Chapter 33 takes over when the merchant retains credentials for later collections.
A secure checkout must establish what the customer agreed to buy, how the credential was used and whether the payment actually progressed. A wallet button alone answers none of those questions completely.
For a roughly 60-minute core session, spend about 35 minutes on Sections 4–5, Sections 7–8 and Sections 12–13. For the next 10 minutes, use the chapter’s three diagrams to separate order state, authentication, authorization and supported captures. Use 10 minutes to work through one case in Section 15, then spend the final 5 minutes explaining: How should a merchant recover when the payment is approved but its order confirmation is missing? 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.
All businesses and incidents are fictional. Suggested internal data fields and controls illustrate implementation choices. They are not universal card-network message definitions.
Chapter navigator
- Remote acceptance and the commercial order
- Participants and trust boundaries
- Checkout integration and payment data
- The remote payment lifecycle
- Authentication through EMV 3-D Secure
- Authorization evidence and risk decisions
- Network tokens and gateway tokens
- Provisioning and device-wallet acceptance
- Token lifecycle and account continuity
- Debit routing and channel classification
- Payment-page security and fraud controls
- Capture fulfilment settlement and funding
- Failures callbacks and recovery
- Reconciliation reporting and bank architecture
- Worked cases and implementation testing
- Role checklist and learning closure
1. Remote acceptance and the commercial order
Card-not-present acceptance means that the transaction is not processed through the physical card-present interaction relevant to the transaction. An online purchase, an in-app purchase and a telephone order can all involve remote card use, but they do not necessarily carry identical authentication evidence or processing indicators. The merchant should preserve how the payment was actually initiated.
The order is the commercial anchor. It identifies the goods or service, customer, price, delivery arrangements and cancellation conditions. The payment attempt concerns collecting a specified amount for that order. A customer may abandon the order after authentication. A merchant may reject an order after an issuer approval because stock is unavailable. A shipment may occur in parts. These are ordinary business events, not exceptional reasons to merge order and payment state.
For the jacket purchase, the merchant should create a stable order reference and an identifiable payment attempt. The customer-visible total should be calculated and validated server-side before release. A manipulated browser request should not be able to change a $240 order into a $24 authorization while the warehouse still receives the original order.
The merchant also needs a clear completion policy. Does it confirm the order after authorization, capture or another controlled acceptance event? The policy may differ for physical goods, advance bookings and immediate digital delivery. It should be explicit in the product design, with the payment consequences of cancellation and delayed fulfilment understood.
This chapter concentrates on collection at remote checkout. It does not turn every wallet into a new settlement network. A card-funded wallet purchase can continue through card authorization and financial processing. The wallet changes credential presentation and user interaction; the underlying product and rail still need to be identified.
Separating the shopping session from the payment obligation
A remote merchant can have several customer interactions around one order. The shopper may compare products on a phone, sign in on a laptop, select delivery, open a wallet and return later after abandoning a challenge. The payment system needs a stable commercial record across those interactions. It should not assume that a browser session, a customer account and an order are the same entity or that they have the same lifetime.
Consider an online retailer selling a $420 appliance. The order includes the product, tax, delivery charge and delivery address. The payment attempt should refer to the exact payable version of that order. If the shopper changes to a more expensive delivery option after authentication begins, the merchant needs to determine whether the existing payment context remains valid under its supported flow. Silently changing the order while retaining evidence for another amount undermines both acceptance and later investigation.
Inventory reservation creates another timing boundary. The merchant may reserve the appliance before seeking payment, but that reservation does not establish a cardholder debit. Conversely, an authorization can succeed while the inventory service fails. The order system needs a controlled disposition for both situations. It can release inventory for an abandoned order and resolve any payment effect, or retain the reservation while a legitimate review completes under a defined policy.
An account login should not be treated as proof that every subsequent action is authorized. A customer account can be taken over, a saved address can be changed, or a checkout link can be opened by someone else. The merchant's order controls therefore remain relevant even when the payment provider supplies strong credential and authentication services. The bank should understand what identity evidence the merchant actually collected rather than inferring it from the existence of a registered account.
The business analyst can express the acceptance goal as a relationship: the customer-facing order, the agreed amount, the credential context, the authentication evidence and the payment decision must describe the same intended purchase. The relationship must survive browser closure and later fulfilment. This is more useful than a requirement saying simply that the website must accept cards, because it identifies the records that must agree when the normal journey breaks.
Support should also distinguish an order confirmation from a payment receipt. A merchant may confirm receipt of an order before completing payment or accepting it commercially. The wording should describe the actual stage. Otherwise the customer may believe a purchase is complete while the merchant is still deciding whether it can be supplied.
2. Participants and trust boundaries
The customer interacts with a browser, app or supported wallet interface. The merchant operates the order system and chooses the acceptance arrangement. A payment service provider or gateway may host payment fields, tokenize credentials, orchestrate authentication and connect to the acquirer. The network connects the acquiring and issuing sides under its rules. The issuer owns the underlying card-account decision.
Token services and authentication services add distinct responsibilities. A token service provider manages the relevant payment-token relationship. In EMV 3-D Secure, the merchant-side 3DS service, directory service and issuer-side access control server participate in authentication. Their results inform subsequent processing; they do not replace the commercial order or the issuer's payment decision.
A bank may outsource several components to one processor, but functional ownership still matters. If a checkout vendor reports authentication success, the bank must know whether an authorization was subsequently sent. If a token service rejects a credential, the merchant should not display a generic insufficient-funds message. If an order expires, the payment service needs to know whether an authorization remains outstanding.
Trust boundaries should be explicit. A browser redirect is customer-controlled traffic and should not be the sole authority for marking a payment paid. Server-to-server results also need authentication, validation and correlation. An apparently valid callback for another merchant or another amount should not complete the current order.
The acquiring bank needs merchant-level visibility across these boundaries. A gateway may be healthy while one merchant has a broken checkout deployment. Conversely, several merchants can fail because of one authentication provider. Monitoring by merchant, integration type and dependency helps operations distinguish those incidents.
Assigning ownership across the remote checkout chain
The merchant's front end collects customer choices and presents the checkout. Its order service records the commercial instruction. A payment service provider may host credential capture and supply transaction processing. A 3DS service supports authentication where used. The acquirer connects merchant acceptance to the network relationship, while the issuer decides and books against the card account. These roles may be packaged together commercially, but their responsibilities remain distinguishable.
For a bank onboarding an e-commerce merchant, the integration inventory should identify where each function operates and which organization supports it. A single branded checkout page can contain merchant code, a hosted payment component, a wallet integration, analytics scripts and a fraud service. The acquiring team needs to know which component can change the payment amount, which sees sensitive data and which produces the result relied on for fulfilment.
Trust boundaries are especially important for messages returning through the customer's browser. The browser is an interaction channel, not an authoritative ledger. A return URL can help the merchant resume the shopping experience, but a parameter saying success should not by itself mark an order paid. The merchant should obtain or verify the payment outcome through the supported provider mechanism and match it to the intended operation.
Responsibility also matters during incidents. If the challenge page does not appear, the issuer may not yet have received an authorization. If the payment is approved but the order remains pending, the merchant's result-handling path may be at fault. If a credit is accepted by the processor but absent from the customer account, acquiring and issuing operations may need to trace a financial event. A useful incident classification locates the broken boundary before assigning a generic card-payment failure.
The service agreement should identify who communicates with whom. The merchant normally supports the shopper's order, while the issuer supports the card account. The customer should not be asked to transport raw technical messages between those organizations. Protected references and structured case information should support the trace. The merchant can explain fulfilment decisions without claiming to know the issuer's confidential risk reasoning.
An ownership map should extend to change management. A payment provider may update its hosted component independently of the merchant's deployment schedule. The merchant should understand how compatibility changes, security notices and integration requirements are communicated. Outsourcing credential capture reduces some direct handling responsibilities but does not remove the need to operate the surrounding checkout correctly.
3. Checkout integration and payment data
A merchant can use a hosted checkout, embedded hosted fields or a more direct integration. The choice determines which systems handle card data and which components can influence the payment page. Outsourcing capture can reduce exposure, but the merchant still has responsibilities for its own website and the integration it operates.
A practical design binds the payment session to the order, merchant account, amount, currency and intended operation. The session should have an expiry and a controlled lifecycle. If the order changes materially, the system should re-evaluate whether the existing session and customer approval still apply. A payment session for a $240 jacket should not silently become authority for a $600 order.
The card-data path should be documented separately from the order-data path. A hosted field may send credentials directly to the provider, while the merchant receives a limited token or reference. Delivery address, basket details and customer contact information may remain in the merchant's systems. Avoid assuming that tokenization of card data protects every other piece of customer information.
Fields should retain their meaning across interfaces. The merchant's payment identifier, gateway identifier, network transaction reference and authentication identifiers serve different purposes. A useful integration contract explains which identifier is used for inquiry, capture, reversal, refund and dispute evidence. It should also distinguish a technical request acknowledgement from an approved financial operation.
The API contract must define duplicate handling and asynchronous behavior. For example, repeated submission with the same idempotency key may return the original result, reject the repeat or behave differently if the payload changes. The merchant should implement the provider's actual contract. It should not assume that adding a field named idempotency_key creates protection if the receiving service does not enforce it.
Binding a payment session to trusted order data
A robust checkout starts the payment session from authoritative server-side order data. The amount, currency and merchant context should come from the merchant's controlled order service, not solely from values submitted by the browser. The browser can request a purchase, but the server should determine the amount actually payable for the selected goods and terms before creating the payment operation.
For the $420 appliance, suppose an attacker modifies a browser field to request $4.20. A payment provider might process the submitted amount correctly while the merchant's fulfilment service still sees the original appliance order. The defect lies in binding the payment to the order, not necessarily in the provider's authorization decision. The acceptance requirement should verify that the confirmed payment amount and currency match the version of the order being released.
Hosted fields, embedded components and redirect checkouts create different data paths. The bank should ask which system receives the raw credential and which receives only a protected reference. The answer should be supported by the actual integration, including error handling and logging. A design diagram saying tokenized checkout is insufficient if a debug path also sends the credential into a merchant support log.
Session expiration should have a business consequence. An expired payment session may require a new session for the same order, but it should not automatically create another order or invalidate a payment already accepted. The system should distinguish a session that expired before submission from one whose result became uncertain after submission. Recreating a session is not a substitute for resolving the original financial operation.
Payment configuration should be isolated from ordinary content management. An editor who changes product descriptions should not necessarily be able to replace a payment destination, alter merchant credentials or add an unreviewed checkout script. The merchant can use separate permissions and deployment controls to protect those functions. These are implementation recommendations grounded in the payment risk, rather than a claim that every merchant uses the same hosting architecture.
The provider's integration contract should also specify the handling of partial failures. A session-creation response can succeed while the browser fails to display it. The customer can close a redirect page after completing a payment. The merchant can receive a callback before the browser returns. Each event should update the same commercial record through its supported identifiers, so the acceptance journey remains recoverable without depending on one uninterrupted screen sequence.
4. The remote payment lifecycle
The diagram shows a typical authenticated remote card purchase. Authentication is included when the selected flow uses it. Wallet-specific interactions can provide other supported evidence. The later financial stage is deliberately separate from both authentication and authorization.
The merchant first establishes the order and a payment session. The supported credential is captured or selected. If EMV 3DS is used, the authentication process produces a result. The payment service then creates an authorization request with the appropriate transaction context. The acquiring path routes the request, and the issuer or permitted decision service responds.
After approval, the merchant applies its order-acceptance and capture policy. A fraud review may still prevent fulfilment. If the merchant decides not to proceed, it should use the appropriate authorization cancellation or financial-credit process for the current lifecycle stage. It should not assume that cancelling the order database entry also cancels the payment.
Capture and clearing carry the financial transaction forward. Settlement occurs through the relevant participant arrangements, and the acquirer funds the merchant under its contract. The warehouse's shipment event is separate evidence. A successful shipment callback does not prove card clearing, just as a card approval does not prove that goods shipped.
The bank's operational model should connect these events without assigning one system ownership of all of them. The issuer sees the card account and network evidence. The acquirer sees merchant financial activity. The merchant sees the order and delivery. Investigations often require combining these views, using references that survived each handoff.
Following the order after the shopper disappears
Remote acceptance must continue correctly when the customer closes the tab. Suppose the shopper completes a supported authentication challenge and the payment provider receives an authorization approval, but the browser never reaches the merchant's confirmation page. The merchant still needs to learn the authoritative payment outcome. Its order should not remain indefinitely unpaid merely because the customer did not return through a particular URL.
The reverse is equally important. The browser can reach a confirmation-looking page while the underlying payment failed or remains uncertain. The page should retrieve the order's controlled state and display the appropriate result. It should not trust navigation alone. This protects the customer from misleading success messages and the merchant from releasing goods against a fabricated or stale browser event.
The order service should coordinate acceptance with fulfilment through an explicit decision. A payment approval may satisfy the payment part of the decision, while inventory, delivery restrictions or manual review remain outstanding. The order can therefore be payment-approved but not yet released to the warehouse. That state is legitimate if it has an owner and a timely next action; it should not become a place where orders disappear from both payment and fulfilment monitoring.
For a delayed review, the merchant must consider the continued validity of its payment position under the actual processing arrangement. The approved amount, permitted capture timing and any necessary new interaction should be handled through the supported lifecycle. The warehouse should not interpret an old order flag as permanent authority to collect a card payment whenever stock eventually returns.
Operational reporting should connect the two timelines. One report can show orders awaiting payment resolution; another can show approved payments whose orders have not been accepted or fulfilled. These are different queues. The first protects against release without payment, while the second protects customers from unresolved payment effects and helps the merchant prevent abandoned authorizations or incorrect capture.
The bank's acquiring support team benefits from this model because it can ask the merchant a precise question: is the problem that the payment result is missing, or that the order did not act on a known result? Those cases lead to different technical owners. A complete remote-payment lifecycle is therefore a coordination model around the payment network, not a claim that the card network controls the merchant's entire order process.
5. Authentication through EMV 3-D Secure
EMV 3DS supports exchange of transaction and device information to help authenticate the person making a remote purchase. A risk assessment can produce a frictionless outcome or require a challenge through a supported method. The absence of a visible challenge does not, by itself, mean that no authentication process occurred.
The merchant-side 3DS server, network directory service and issuer-side access control server have different roles. A browser or app challenge is part of that authentication journey. The resulting status and identifiers should be retained and passed into payment processing where the applicable specification requires them. Do not invent one authentication field layout for all gateways.
Most importantly, authentication success is not authorization approval. The issuer may still decline the payment because of account status, available funds, credit exposure or other decision factors. The merchant must wait for the payment result required by its processing flow before treating the payment as approved.
Likewise, an authentication attempt, an unavailable authentication service and a completed authentication are different outcomes. The merchant's policy for each should be documented with the acquirer. A challenge abandoned by the customer should not automatically be relabelled frictionless and submitted with fabricated success indicators.
Liability allocation follows the applicable network program and transaction conditions. It is not guaranteed merely because a merchant says it uses 3DS. The bank should verify eligibility and retained evidence for the actual dispute type. Authentication evidence can be highly relevant to fraud assessment, but it does not establish delivery of goods or resolve every commercial complaint.
Do not import European SCA rules as a universal domestic US checkout requirement. EMVCo provides technology specifications used across markets; local law and network requirements determine the obligations for a particular transaction. Cross-border scope needs its own assessment.
Carrying authentication evidence into the payment decision
EMVCo's challenge-flow material distinguishes the authentication request and response from challenge and result exchanges. AReq and ARes support the initial authentication exchange. Where an interactive challenge is used, CReq and CRes support that interaction, and RReq and RRes support the result exchange in the described flow. These are 3DS messages, not authorization or settlement messages. The exact sequence and data depend on the supported channel and specification version.
For the bank implementation, the important relationship is between the authentication transaction and the later payment attempt. The merchant should preserve the supported transaction identifiers and result data returned by its provider. The payment adapter should map the evidence according to the acquiring specification. It should not create a generic authenticated flag and discard the distinctions needed for downstream processing or a later investigation.
Consider a challenge that the shopper starts but does not complete. The merchant's order can remain open for a valid next action, but the system must not record completed authentication. A retry may require a new supported interaction. Reusing the previous challenge's partial state as if it were a success changes the meaning of the evidence. This is an application defect even if the eventual authorization receives approval.
An issuer-side implementation also needs to distinguish authentication availability from account authorization availability. A service can authenticate the customer while the card account subsequently fails a funds, status or risk check. Conversely, the merchant's supported policy may permit a payment attempt in some cases where authentication could not be completed. The institution should apply the actual program conditions rather than assume a universal dependency between the two services.
The customer experience should explain the current step without revealing sensitive decision logic. A challenge can ask the customer to complete an issuer interaction, while the merchant waits for the corresponding result. If the customer returns after a long delay, the merchant should establish whether the order and payment session remain usable. It should not send the customer through repeated challenges simply because its own callback handler lost the first result.
Testing should join authentication and payment evidence across failure points: challenge success followed by authorization decline, challenge abandonment, duplicate result delivery, delayed browser return and an approved payment with an interrupted confirmation page. These cases verify the distinction taught by the diagram. Authentication supports the decision process, but the actual payment outcome and later financial completion still need their own evidence.
6. Authorization evidence and risk decisions
Remote authorization can include information about the credential, channel, authentication outcome, merchant, transaction and customer context. The exact supported fields and validation behavior come from the processor and network. The bank should retain useful decision evidence while respecting data-minimization and security requirements.
Address verification and card verification-code results are signals, not complete identity proof. An address match does not prove that the purchaser is the legitimate cardholder. A mismatch can arise for reasons that need contextual interpretation. The merchant's risk policy should distinguish unavailable data from a confirmed mismatch rather than treating both as the same event.
An issuer approval also does not require the merchant to ship every order regardless of its own evidence. A merchant may detect account takeover, an unusual delivery change or inventory problems after authorization. Its decision to cancel should trigger the correct payment action and customer communication. Otherwise, a legitimate customer can be left with a hold for an order the merchant already rejected.
Fraud controls should consider the entire order journey. A returning customer account with a newly changed email address, delivery address and device may carry different risk from the same account's established behavior. Repeated tiny authorization attempts can indicate credential testing. A sudden burst from one checkout integration can indicate either an attack or a software loop; investigation needs both business and technical evidence.
Manual review should have an owner and expiry. Holding an order indefinitely while an authorization ages can create fulfilment and capture problems. The system should know whether to release, cancel or obtain a new customer interaction under the applicable rules. Reusing stale authentication data or treating an old approval as unlimited authority is not a sound recovery design.
Combining merchant and issuer decisions coherently
The merchant and issuer assess different information. The merchant knows the order, delivery address, customer-account changes and fulfilment constraints. The issuer knows the card-account relationship and its own transaction history and controls. A remote purchase can be acceptable to one and unacceptable to the other. The acceptance process should coordinate those decisions without presenting either party as having complete knowledge of the entire transaction.
Suppose the issuer approves the $420 appliance purchase, but the merchant detects that the customer account's email and delivery address changed immediately before checkout. The merchant may hold or cancel the order under its policy. It should then handle the authorization effect through the supported process. Leaving the payment approved indefinitely while customer support says the order never existed creates an avoidable complaint and complicates the issuer's investigation.
Risk review should have a defined release authority. An analyst may approve fulfilment after reviewing evidence, but the system should verify that the payment state remains appropriate at release time. A decision made against yesterday's order version may no longer be valid if the amount or destination changed. The review record should show the facts assessed, the policy used and the resulting action, without pretending that an illustrative internal risk score is a regulatory threshold.
False positives have operational cost as well as conversion cost. A legitimate shopper can be repeatedly challenged or declined because several systems independently react to the same unusual fact. The merchant should measure where friction originates and whether it improves outcomes. That analysis should distinguish issuer declines, merchant cancellations, authentication failures and technical errors. Combining them into one rejection rate hides which control or integration needs attention.
Risk controls also need feedback from fulfilment and disputes. A cluster of orders shipped to newly changed addresses may reveal a merchant-account takeover pattern. A cluster of identical failed payment attempts can reveal a checkout loop rather than criminal activity. The response should follow the evidence. Disabling an effective fraud rule to compensate for a software defect would expose the merchant without fixing the underlying integration.
Customer communication should remain accurate at the boundary. The merchant can say it could not complete or accept the order, or that the card issuer declined the payment when that is the confirmed source. It should not attribute its own cancellation to the bank. Clear source attribution reduces unnecessary issuer calls and helps legitimate customers choose a valid next step.
7. Network tokens and gateway tokens
EMV payment tokenization replaces a primary account number with a payment token that can be constrained to an intended use context. EMVCo distinguishes these payment tokens from tokenization inside a merchant or acquirer environment. A gateway vault token may simply be a reference used to retrieve a credential within that provider's service; it is not necessarily a token that traverses the card network.
The distinction matters during routing and migration. A merchant-specific vault reference may be meaningless to another provider. A network token can have restrictions associated with its token requestor or use domain. Neither should be assumed portable merely because both are called tokens.
A token is also not an authorization. It can identify a usable credential while the underlying account is blocked, insufficiently funded or otherwise ineligible for the requested transaction. A tokenization success response should therefore not be counted as a payment approval in merchant dashboards.
Where supported, Payment Account Reference can help associate tokenized activity with the underlying account relationship. Availability depends on the participating systems. It is a linking reference, not a replacement payment credential. Internal identifiers should still support tracing a specific transaction through its actual credential and processing path.
For the bank's architecture, separate the token reference, token state, underlying account reference where legitimately available, and transaction-level evidence. Do not overwrite the original token when a credential changes. Historical purchases, refunds and disputes need the credential context that existed at the time.
Tokenization reduces particular data-compromise risks but does not eliminate fraud. A criminal who persuades an issuer to provision a legitimate token can still use that token within its permitted environment. This is why provisioning controls and transaction monitoring are separate controls rather than alternative descriptions of the same protection.
Choosing the token relationship the merchant actually needs
A gateway token and a network payment token can both hide a PAN from part of the merchant environment, but their operational relationships differ. A gateway reference may identify a record within one provider's vault. A network token can represent a credential in a supported payment domain. The merchant should identify which relationship it has before designing portability, recurring use, routing or refunds around the word token.
Imagine a retailer moving from provider A to provider B. Its customer database contains a protected reference from A. Sending that reference to B may be meaningless unless an approved migration or interoperability arrangement exists. The business should not promise seamless saved-card continuity solely because the original credentials were tokenized. The migration plan must establish how permitted payment relationships and historical traces remain usable.
Network token use introduces lifecycle dependencies. The token requestor, token status and supported domain can affect whether a transaction is eligible. The merchant's internal record should preserve those relationships where the service makes them available. A token that works in one channel should not be assumed valid in another. Nor should a suspended token be bypassed automatically by selecting an alternative stored credential without a legitimate basis.
The bank should distinguish token provisioning success from transaction success in operational metrics. A high provisioning rate can coexist with poor authorization outcomes. A decline can arise from the underlying account even when the token is valid. Conversely, a token-specific validation issue can prevent a transaction before the issuer reaches its ordinary account decision. These distinctions help support teams locate the correct service owner.
Historical continuity matters after replacement or deletion. The merchant needs enough protected evidence to trace a prior purchase and any refund even if the credential is no longer eligible for new purchases. Removing a token from a shopping account should not delete the financial history associated with its use. The exact retained data and retention period should follow applicable requirements and the service arrangement.
For architecture, model the commercial customer relationship separately from the payment credential relationship. A customer can have several credentials, and a credential can have a changing lifecycle. This avoids treating a token replacement as a new customer or assuming that deletion of one device credential ends every payment relationship. Chapter 33 examines authority for later collections; here the core acceptance question is whether the presented credential is valid for this specific remote purchase and correctly linked to its evidence.
8. Provisioning and device-wallet acceptance
Provisioning is the process that establishes a credential in a wallet or another token-using environment. The issuer and relevant services assess the request under the program's rules. The customer may need additional identity verification. A secure purchase cryptogram later proves something about use of that provisioned credential; it does not retroactively prove that provisioning was legitimate.
Consider a stolen account being added to a new device. If verification relies on contact information recently changed by the attacker, the provisioning journey can be compromised before the first purchase occurs. A useful issuer control joins provisioning events with account changes, device history and subsequent spending. Exact decision thresholds are bank-specific and should not be invented in a training chapter.
At physical checkout, a supported wallet tap can use contactless card acceptance. In a browser or app, a wallet checkout uses a remote integration. Those channels should not be assigned the same entry-mode classification simply because the customer used the same phone. Preserve the actual acceptance method and relevant wallet evidence.
The merchant must validate the wallet integration according to the provider's instructions, including the intended merchant context, transaction data and response handling. A screenshot of a wallet confirmation is not the merchant's financial evidence. The back-end payment result must match the order and amount.
Supported recurring-payment wallet arrangements require a separate design. A one-time device-wallet purchase is not automatically permission to replay the same payload every month. Chapter 33 covers the consent and transaction-classification model. The merchant should verify which credential type and recurring capability the selected wallet and processor actually support.
Accepting a wallet without trusting the phone screen
A wallet can improve the customer interaction, but the merchant still needs a verified payment result. The customer may approve an interaction on the device while the merchant's back end later encounters an authorization decline or communication failure. The wallet's local confirmation should therefore be understood as evidence of the wallet step, with the financial meaning determined by the supported integration.
The merchant should bind the wallet request to its own identity and the intended transaction data. If a payment payload is returned, the provider's validation and processing requirements determine how it is used. The application should not accept arbitrary payloads copied from another order or merchant context. The purpose of this binding is to prevent a legitimate-looking wallet interaction from being attached to the wrong commercial instruction.
An issuer's provisioning controls operate earlier in the lifecycle. A new wallet credential may be requested after changes to a customer's contact details or access credentials. The issuer should assess the available evidence under its program and risk model. Successful later use of the token does not erase weaknesses in that earlier decision. Fraud investigations should therefore retain the relationship between provisioning, account changes and subsequent purchases where lawfully available.
For merchant support, physical wallet acceptance and remote wallet acceptance should remain distinguishable. A tap at a store terminal follows the terminal's supported contactless flow. A wallet button on an e-commerce page follows the remote integration. The same customer and phone do not make the transactions operationally identical. Entry-method and channel data should describe what happened, because routing, risk and evidence can depend on those facts.
The merchant should also test wallet cancellation and return paths. The customer can dismiss the wallet sheet, fail to complete a required step or return to an order whose inventory reservation has expired. A cancelled wallet interaction should not automatically cancel a separate payment that already succeeded through another attempt. The order needs to identify which operation each callback belongs to.
The integration should give the customer a useful recovery path without encouraging repeated payment attempts. Where the financial result is uncertain, the page can show that the order is being checked and provide a stable order reference. Where a definitive failure is confirmed, it can offer another supported payment method. The difference protects both the customer experience and the merchant's financial records.
9. Token lifecycle and account continuity
Tokens can be activated, suspended, replaced or deleted according to their program. The underlying account can also change independently. A customer may remove a wallet from one device while continuing to use another. An issuer may replace a PAN while maintaining permitted token relationships. The integration should respond to actual lifecycle information rather than assuming every card replacement ends every token.
A useful internal model separates customer relationship, underlying account, credential and token instance. One account can have several credentials or token instances. Blocking an individual device token is therefore different from closing the account. Support staff need to understand the scope of the action they are taking.
Refund continuity is a practical consequence. The customer may have purchased with a wallet token and later present a physical card with different visible digits. The merchant should use the supported original-transaction refund path and network references. Asking the customer to find an identical last-four display can create unnecessary friction if the credential representation differs legitimately.
Token-service outages require explicit behavior. The merchant should not silently fall back to a stored PAN unless that alternative is available, permitted, secure and correctly classified. A decline caused by a suspended token should not trigger an uncontrolled search for another credential that defeats the issuer's restriction.
Migration is another lifecycle event. Moving gateways can break token references, original-transaction links or callback routing. A migration plan should inventory which credentials can move, how consent evidence remains linked, and how old refunds and disputes will be serviced. A successful new checkout test does not prove that six-month-old purchases remain recoverable.
Processing lifecycle events without rewriting history
A token or underlying credential can change while an order remains open. The customer may remove a wallet credential after placing the order, or an issuer may replace an account credential before a refund is processed. The merchant should not infer the financial outcome from the current credential status alone. Eligibility for a new purchase and the processing of a historical financial event are different questions.
Lifecycle notifications should be linked to the relevant credential record and processed with their source and sequence information where supported. A delayed event should not overwrite a newer authoritative status merely because it arrived last at the merchant. The actual provider's event contract determines the ordering and inquiry mechanisms available. The bank's integration should preserve enough evidence to resolve conflicts instead of relying on the arrival time of a message as universal truth.
Consider an order authorized using a network token and shipped later under the permitted capture arrangement. If the token status changes in between, the merchant must follow the supported rules for the existing operation. It should not silently create a new purchase on a different credential to make capture succeed. That would change the customer's payment relationship and could create an unauthorized or duplicate collection.
Refund handling should retain the original purchase relationship. A support user may see a different masked number on the customer's current card or wallet, but that does not establish that the original transaction is untraceable. The acquiring and issuing services should use the references supported by the actual processing path. If the credit cannot post, the exception should remain financially owned rather than disappearing when the token is no longer displayed in the customer's shopping account.
Lifecycle monitoring should also distinguish customer intent from technical maintenance. Removing a wallet from one device is not necessarily a request to cancel an order or subscription. Replacing an expired credential is not necessarily new consent for a purchase. The merchant should process each instruction in the system that owns its meaning and preserve the relationship to related payment records where appropriate.
This separation becomes valuable during investigation. The team can reconstruct which credential was used, what its relevant status was at the time, what changed afterward and which financial events followed. A database that simply overwrites the old token with the latest one loses that chronology and can make a legitimate refund or fraud inquiry much harder to complete.
10. Debit routing and channel classification
Regulation II's network-exclusivity provisions also address card-not-present debit transactions. The Federal Reserve's 2022 final rule clarified issuer enablement responsibilities for this transaction type. Remote checkout should therefore not be designed on the assumption that debit routing choice exists only when a customer enters a PIN at a physical terminal.
The acquiring integration needs accurate capability information for the eligible routes. Token support, transaction type and processor connectivity can affect the technical implementation. These must be resolved with the actual providers while preserving applicable routing requirements. A gateway's default route is a configuration outcome, not the legal definition of the only permissible network.
Transaction classification needs to distinguish browser checkout, in-app use, telephone order, stored-credential use and supported wallet methods. A merchant should not describe an unattended recurring collection as a customer-present e-commerce transaction merely to obtain a different risk treatment. Chapter 33 explains that boundary in detail.
The bank's canonical data can normalize these channels for reporting, but it should retain the native indicators sent and received. Otherwise, operations cannot explain why one network treated an otherwise similar transaction differently. The same principle applies to authentication evidence and token type.
Testing should include route changes without losing the order reference or duplicate protection. If one route fails before release, the merchant may have a permitted alternative. If the first route's result is unknown, changing route is a financial decision with duplicate risk. Status resolution must come before an automatic second payment.
Testing remote debit routing with the actual transaction context
Remote debit routing should be tested as part of the checkout integration, not deferred until the merchant compares its first statement. The acquirer should establish the eligible networks for the supported card and transaction context and verify how merchant routing instructions are applied. The legal framework described earlier remains separate from the technical capability of a particular provider connection.
Tokenized activity deserves explicit testing. A routing decision can depend on the information available to the processor and the capabilities supported by the relevant participants. The merchant should not assume that every tokenized transaction exposes the same routing choices as every PAN-based transaction. Equally, tokenization should not be treated as a blanket explanation that makes merchant routing obligations disappear. The acquiring team should obtain a concrete explanation of the supported path.
The test evidence should include the actual route returned or reported by the provider, the acceptance channel and any relevant transaction characteristics. A displayed card brand alone is not sufficient. If reports aggregate all debit transactions under a broad brand label, the merchant may need a more detailed reconciliation or routing report to assess the processing behavior accurately.
Failure recovery requires the same distinction as physical acceptance. Selecting another eligible route before a request is released can be a valid routing decision. Sending a second transaction after the first timed out can create duplicate exposure. The checkout service should preserve the first operation and follow the provider's inquiry or recovery process before deciding that another submission is safe.
Cost analysis should compare comparable transactions. A change in card mix, token use, merchant category, transaction features or processing path can change observed costs. The merchant should not attribute every movement to routing policy without examining those factors. The bank's role is to provide evidence that connects the commercial statement to the actual routed activity, while protecting confidential information and applying the relevant agreements.
Channel classification should also survive reporting. A device wallet used remotely should not be marked card-present simply because the customer interacted with a physical device. A saved credential entered through a website should not be classified as a merchant-initiated collection merely because the merchant already held it. Accurate classification supports the correct network treatment and provides the foundation for the stored-credential distinctions developed in Chapter 33.
11. Payment-page security and fraud controls
Remote acceptance exposes the payment page to risks that a secure back-end alone cannot address. A compromised script can alter the page delivered to the browser or capture information before it reaches a legitimate payment provider. PCI SSC's guidance on payment-page security addresses script authorization, integrity and detection of unauthorized changes. Applicability and assessment scope depend on the integration.
The merchant should know which scripts execute on checkout, why they are needed and who can change them. Marketing and analytics changes can affect a payment page even when the payment engineering team deploys no code. A useful change process treats checkout dependencies as part of the acceptance environment.
Card verification codes may be collected when needed for authorization, but merchants must not retain them after authorization, even encrypted. PCI SSC specifically addresses this prohibition. It applies to logs, analytics payloads, screenshots, support tools and database fields, not just the primary payment table.
Fraud monitoring should distinguish stolen credentials, merchant-account takeover, customer-account takeover, credential testing and commercial abuse. These patterns call for different evidence and actions. A successful token validation or authentication result should be considered alongside the case facts, not used to close every fraud allegation automatically.
Security incidents also need financial reconciliation. If a checkout script generated duplicate requests, the bank must identify the resulting financial transactions. If a merchant account was taken over and refund destinations or permissions were abused, restoring access does not recover money already paid. The incident response should include both containment and affected-payment analysis.
Treating the payment page as a controlled production surface
An e-commerce payment page can change without a payment-team release. Marketing may add a tag, an analytics service may update a script or a content tool may insert a new component. The merchant should understand which of those changes can affect payment data or the integrity of the checkout. A secure payment provider cannot protect every part of a page it does not control.
The practical control starts with an inventory of payment-page components and their owners. The merchant should know why a script is present, who approves it and how unauthorized change is detected. PCI SSC's e-skimming guidance provides relevant security context; the actual assessment and control obligations depend on the merchant's environment. The bank should avoid declaring that a hosted component automatically removes every surrounding web-security responsibility.
An incident can begin as a customer-service signal. Several shoppers may report unusual redirects or requests to re-enter card details. The payment provider may see normal transaction processing because the compromise happened before the legitimate submission. The merchant's incident process should preserve the affected page version and relevant change history through its approved security procedures, while containing exposure and coordinating with responsible parties.
Credential testing is a different pattern. A burst of low-value or repeated checkout attempts can create load, issuer friction and merchant costs even when most attempts fail. The merchant should correlate attempts by meaningful risk signals and distinguish automated abuse from a software retry loop. Controls should address the source and avoid turning the payment endpoint into an unrestricted test service.
Administrative compromise can be as damaging as script compromise. Changing a payment configuration, disabling a control or redirecting a customer to another checkout can alter the acceptance path. Access reviews should therefore include the systems that manage checkout behavior, not only the processor dashboard. A business user who needs to edit product images does not automatically need authority over payment settings.
Recovery should include validation of the restored page and transaction path. Removing a suspicious script is not enough if the deployment mechanism remains compromised or the merchant cannot identify the affected period. The bank should ask what changed, which customers or transactions may be affected and what evidence supports the restoration. These are operational questions that connect security work to customer protection and acquiring risk without inventing a universal incident sequence for every merchant.
12. Capture fulfilment settlement and funding
Capture policy should match the merchant's business model and applicable network rules. A retailer may need to align financial capture with shipment. A digital service may fulfil immediately. A travel merchant can have more complex timing. This chapter does not prescribe one US-wide capture deadline because network, transaction type and processing arrangement matter.
Split fulfilment needs explicit amount control. If a $240 order ships as a $160 item and an $80 item, the payment integration should use the processor's supported partial-capture or related lifecycle behavior. It must track captured amounts and the remaining authorized or otherwise permitted amount. Sending two captures each for $240 is not prevented merely because there was one order.
An authorization can expire or require additional handling before delayed fulfilment. The merchant should not assume that retaining an approval reference guarantees later financial acceptance. The appropriate new authorization, adjustment or customer interaction depends on the current rules and transaction context.
Clearing and settlement follow the card model explained in Chapter 29. The financial records establish participant obligations; actual money movement follows the designated settlement arrangements. The acquirer then calculates merchant proceeds. The browser, wallet and 3DS server do not settle those obligations simply by returning successful responses.
Merchant funding is a separate commitment with its own schedule and adjustments. Refunds, disputes and reserves can change the net amount. A merchant receiving $9,000 after $10,000 of captured orders needs a statement explaining the difference, not a dashboard that labels all $10,000 as cash received. Where funding occurs before related cash is available to the acquirer, treasury needs to understand the exposure.
Coordinating split shipment with financial completion
An online order can produce several fulfilment events. Suppose a customer buys two items for a total of $420, with one available immediately and the other dispatched later. The merchant should determine its supported authorization and capture approach with the acquirer. It should not assume that one approval permits any number of later captures or that the entire order must always be charged at the first shipment.
The order needs an allocation model linking each financial operation to the goods or services it covers. If the first item accounts for $260 and the second for $160, operations should be able to trace the corresponding capture or other supported financial records. Tax, delivery charges and discounts may complicate that allocation, so the merchant should use its controlled order calculation rather than divide the total casually after payment processing.
Cancellation of the second item should update the remaining collectible amount and any relevant payment effects. It should not erase the first item's legitimate financial history. A support user needs to know whether the cancelled amount was only authorized, already captured or already credited. That determines the appropriate processing action and what the customer can accurately be told.
The warehouse should not initiate an unrestricted payment action merely because an item moves to shipped. The order service should validate the shipment against the approved commercial and payment state. A duplicate shipment event should not create another capture. A late event for a cancelled item should enter an exception path. These controls connect inventory events to financial correctness without making the warehouse the authoritative payment system.
Settlement and merchant funding then follow the actual processed financial population. A merchant report may show two financial records for the one order, while the bank account receives a consolidated net credit. The order-level reconciliation should explain that relationship. Matching only the original $420 total against individual records would incorrectly flag both legitimate partial amounts as unmatched.
The customer should receive a coherent explanation of what was charged and what remains outstanding. A message saying the order is complete should not conceal an unresolved payment or cancelled item. Conversely, a split shipment should not make the customer believe that two unrelated purchases were created. Good acceptance design preserves the commercial story through capture, settlement evidence and the merchant's eventual proceeds.
13. Failures callbacks and recovery
The jacket checkout should not depend solely on the customer returning from the wallet page. A customer can close the browser after payment approval. A mobile operating system can interrupt the app. The merchant should use its supported server-side result or status inquiry to establish the outcome and update the order reliably.
Callbacks can arrive late, out of order or more than once. A capture result can appear after an earlier authorization callback is replayed. The order service should not downgrade a captured payment to merely authorized because an old event arrived last. It needs event identity, permitted state transitions and a way to query authoritative status when evidence conflicts.
An HTTP timeout means the caller did not receive a timely response. It does not prove the processor rejected the operation. Retrying with a new payment identifier can create a duplicate. Use the provider's supported inquiry and duplicate-protection behavior, preserving the original request relationship.
Authentication failure requires different recovery from payment decline. A customer who abandoned a challenge may need to restart the checkout. A payment declined for account reasons may require another payment method. A merchant validation error may need technical repair. Customer communication should reflect the known cause without exposing sensitive fraud logic.
Cancellation also needs lifecycle awareness. If an order is cancelled before authorization, no payment cancellation may be required. After authorization, the supported reversal or void path may apply. After financial processing, a refund may be required. The order system should request the business outcome; the payment service should choose the valid operation based on actual payment state.
Handling callbacks as evidence rather than commands
A callback can notify the merchant that an operation changed state, but the merchant still needs to validate its source and meaning through the provider's documented mechanism. The message should be matched to the intended merchant, operation and order. A callback carrying a real provider reference is not useful if the application attaches it to the wrong customer order.
Duplicate delivery should be expected where the provider's contract permits retries. The merchant's handler should record that it has already applied the relevant event or operation outcome. It should not repeat a financial or fulfilment action merely because the notification arrived again. The precise idempotency mechanism is an implementation choice, but the business result must remain one intended capture, refund or order release.
Ordering requires similar care. An application may receive a delayed processing notification after a later outcome has already been established. It should not move the transaction backward simply because the older message was delivered last. The provider's status model and inquiry contract should define how conflicts are resolved. Where ordering cannot be established from the event alone, a supported authoritative inquiry may be necessary.
The merchant should also protect the interval between receiving a callback and acting on it. Recording the event without releasing the order can be recovered. Releasing the order without recording the event can cause duplicate action after a restart. A durable processing design should make that relationship recoverable, using appropriate transactional or messaging controls. This is a common bank-integration problem applied to remote commerce.
Manual support actions should use the same operation records. If an operator resolves an uncertain payment while a callback is still queued, the later handler should recognize the established outcome. Separate manual and automated databases with no shared financial control can produce a second capture or an unnecessary refund. The support interface should expose known facts and permitted next actions, not a free-text instruction that bypasses the lifecycle.
Finally, technical acknowledgement is not business completion. The merchant may acknowledge receipt of a callback before completing all downstream work. Its monitoring should distinguish delivery success from successful application to the order and ledger. A provider dashboard showing delivered notifications cannot prove that the merchant shipped correctly or reconciled the financial event. The bank should preserve those boundaries when investigating a payment that appears successful in one system and missing in another.
14. Reconciliation reporting and bank architecture
Remote reconciliation begins with orders and payment attempts. It then links authentication where used, authorization, capture, clearing and merchant funding. Fulfilment evidence is another linked stream. The goal is to identify orders that were paid but not fulfilled, fulfilled without the expected payment, captured twice or cancelled without financial correction.
Useful fields include order_id, payment_attempt_id, provider_reference, authentication_reference, credential_type, token_reference, authorization_reference, capture_id and refund_id. These are illustrative internal names. Store money amounts by lifecycle stage and currency rather than overwriting one amount as the transaction progresses.
A merchant may have a healthy approval rate but poor order completion because customers never return from a redirect. Another may have healthy completed orders but missing capture because a fulfilment integration failed. Reporting should separate authentication completion, authorization approval, order acceptance, capture acceptance and funding. Each metric answers a different operational question.
The acquiring platform should reconcile provider reports to its own merchant ledger. The issuer reconciles network financial records to account postings. A token reference can assist correlation, but it does not replace financial-event identifiers. A provider migration should preserve access to historical reports and references needed for later refunds or disputes.
The architecture should expose a stable payment service to the order system, with network-specific details contained in appropriate adapters. That abstraction must preserve evidence rather than hide it. Operations should still be able to identify the actual processor, network, authentication provider and credential path involved in an incident.
Designing reconciliation around commercial and financial identities
Remote acceptance reconciliation should begin with stable relationships rather than a daily total alone. The order service supplies the commercial identity and agreed amount. The payment service supplies attempts and outcomes. Capture and credit records supply financial events. Acquiring reports supply processing and settlement evidence. Merchant bank-account entries supply the final funding evidence relevant to the merchant. Each relationship can be one-to-many.
A $420 order with two captures and one partial refund illustrates the need for that model. The customer did not place three independent orders. The merchant should retain the original order and allocate the financial events to its components. If the refund relates to the second item, the allocation should be explicit. Otherwise customer support may see a net total that appears correct while the wrong item remains marked paid or refundable.
Reconciliation should identify both missing money and missing meaning. A financial record with no order reference can be financially valid but difficult to allocate. An order marked paid with no accepted financial evidence can represent a more serious collection gap. A difference caused by processing-cycle timing may be expected temporarily. Each should enter a different queue with an appropriate owner and escalation basis.
Customer-facing reporting should avoid collapsing these states. Pending authorization, completed charge and submitted refund have different meanings. The merchant does not control every detail of the issuer's presentation, but it can accurately describe its own action and provide a supported trace reference. The issuer can then investigate the card-account view without relying on a screenshot of the merchant's order status.
Operational dashboards should measure the points where customers and money can become separated: approved payments with rejected orders, accepted orders with uncertain payments, shipped orders without expected financial completion, and refunds not reconciled to their original purchases. These measures are more actionable than a single checkout-success percentage. They identify who needs to act and what evidence is missing.
The bank's implementation should retain native provider references alongside its internal identifiers. Replacing one payment provider does not eliminate old refunds, disputes or reconciliation work. Historical operations should remain traceable through the original provider relationship for as long as required. A successful migration is therefore measured not only by new checkout approvals but also by the ability to resolve the old population without recreating payment credentials or inventing financial history.
15. Worked cases and implementation testing
The following cases apply the chapter to realistic acceptance decisions. For each, identify the current payment state, the evidence needed and the action that could accidentally create a second financial event.
Case A — biometric success, issuer decline. The customer completes wallet verification, but the payment authorization declines. The merchant's app reports payment successful because the wallet callback was positive. What is wrong?
The app used evidence from one stage as proof of another. It needs the actual payment result associated with the correct order. No shipment should be released solely because verification succeeded. The customer message should explain that the payment was not approved and offer an appropriate next step. Testing must cover successful authentication followed by payment decline, not only success throughout.
Case B — closed browser, approved payment. The issuer approves $240. The customer closes the page before the merchant redirect completes. The merchant creates a second payment when the customer returns. Two approvals result. What should the returning session do?
It should recover the existing order and payment attempt, establish the processor's authoritative status and continue from that state. A new browser session does not necessarily mean a new commercial order. If two financial purchases ultimately occur, the duplicate needs the appropriate correction. The incident record should retain both attempts and show which one belongs to the delivered order.
Case C — two shipments. An order totals $300. The first shipment is $180 and the second $120. The merchant's capture worker is replayed after a timeout. Design the amount and duplicate controls.
Each intended capture needs its own identity linked to the order and supported authorization lifecycle. A replay of the $180 capture should resolve that capture's outcome, not create another $180 event. The remaining amount should not be calculated from an unconfirmed local submission alone. Reconcile accepted captures and permitted remaining value before releasing the next financial request. The shipment system should also identify which items each capture represents.
Case D — new phone, old refund. A customer removes a wallet token after purchasing a $70 item. The merchant's refund screen asks for the original visible card digits, which the customer cannot find. What is the stronger design?
Use the original purchase record and the provider's supported refund mechanism. Retain token and network references from the sale. The merchant should not ask the customer to provide unrelated bank details as an improvised shortcut. The issuer and network handle the supported account relationship; if the refund cannot be processed, the exception should follow a documented process with evidence of the failed credit.
Case E — valid callback, wrong amount. A signed callback is received for the merchant, but its amount is $25 and the order is $250. Should signature verification complete the order?
No. Authenticity of the sender does not prove that the event matches the intended commercial transaction. Validate order or payment reference, amount, currency, operation and status as well. Investigate whether the callback belongs to another attempt, whether the order changed or whether the integration mapped amounts incorrectly. This case illustrates why transport security and business validation are separate controls.
Production testing should additionally cover suspended tokens, unavailable authentication, debit-route selection, duplicate callbacks, expired sessions, cancelled orders, failed capture and partial refunds. Evidence should demonstrate correct customer messaging, one intended financial effect and traceable accounting. Page appearance alone cannot establish acceptance reliability.
A complete remote-checkout failure and recovery
An appliance retailer releases a new checkout that supports device wallets. During the first afternoon, some customers see an order confirmation while the merchant's payment dashboard shows unresolved attempts. Others receive successful payments but no order email. The incident team initially suspects the wallet integration, yet the common factor is the merchant's handling of asynchronous results.
The team reconstructs one $420 purchase. The order service created a valid payment session. The customer completed the wallet interaction. The payment provider approved the authorization and sent a callback. The callback reached the merchant before the order worker had finished creating its local payment record, so the handler rejected the notification as unknown. The browser return then displayed success without verifying the controlled order state. Two design defects produced contradictory views of the same purchase.
The repair begins with the affected population. The merchant correlates provider operations to order sessions and determines which attempts are approved, declined or still uncertain. It does not ask every customer to pay again. Approved operations are linked to the correct orders, and fulfilment follows the merchant's acceptance policy. Uncertain operations remain in inquiry. Orders that cannot be accepted commercially receive the appropriate payment correction rather than being silently deleted.
The technical change makes session and operation correlation durable before external submission and permits unmatched callbacks to enter a controlled retry or investigation path. The browser confirmation page reads the authoritative order state. Repeated notifications do not trigger repeated fulfilment. The team tests delayed callbacks, early callbacks, browser closure, duplicate notifications and a provider inquiry arriving during manual resolution.
Financial operations then checks the first captures and merchant reports for the repaired population. Customer support receives order-specific explanations and references. The incident closes only after the commercial orders and payment outcomes agree. The practical lesson is that a secure wallet and a valid issuer approval do not compensate for an unreliable order-to-payment relationship inside the merchant. That relationship is the core implementation responsibility of remote acceptance.
16. Role checklist and learning closure
The Business Analyst defines order-to-payment relationships, channel classification, authentication outcomes and fulfilment policy. The Architect separates browser trust, token services, authentication, payment processing and financial reporting. The Developer validates signed events and business context, preserves identifiers and handles asynchronous results safely.
The Tester deliberately breaks redirects, callbacks and capture responses. Fraud and security teams join provisioning, checkout and account evidence. Operations distinguishes authentication outages from payment failures. Finance reconciles captures, credits, merchant liabilities and cash. Customer support explains the known payment state without treating a biometric confirmation as settlement.
Before moving to recurring collections, explain how a payment token differs from a gateway vault reference and why neither one grants a merchant unlimited authority to charge. That distinction leads directly into Chapter 33.
Remote acceptance works when the order, credential, authentication result and financial lifecycle remain linked even after the customer leaves the screen.
Authoritative references
Public sources checked on 6 September 2026. Network-specific authentication indicators, token permissions, liability treatment and capture deadlines require the applicable program and processor specifications. The architecture and exercises are original illustrative designs.
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.