Loading
Related Articles
Related Articles
TrustFinance Research Team
10월 22, 2026
8 min read
1
3D Secure (3DS) supplies cardholder-authentication evidence. A successful authentication does not, by itself, establish that the issuer approved the payment, that capture succeeded or that the merchant has received cash. It also does not protect a merchant against every dispute. Read the actual authentication result and financial payment result separately, then check whether a particular fraud dispute meets the relevant conditions.
This TrustFinance™ guide is for merchants deciding what an order record establishes and what still needs clarification. The cover separates three questions: authentication, the issuer payment decision and conditional fraud-liability scope. These are an editorial reading framework, not the three domains named by the 3DS protocol. The examples are fictional, and provider documentation is used within its stated scope.
EMVCo describes data exchange between merchants and issuers using transaction, payment-method and device information to help authenticate the consumer. Some transactions can be assessed without an additional visible challenge; others require further authentication. A frictionless experience therefore does not automatically mean that no authentication happened. Conversely, seeing an OTP or bank challenge does not prove its final outcome.
Read the completed result reported for the actual transaction, including its reference and time. A customer returning to the shop page, a screenshot or an employee remembering that a challenge appeared is weaker evidence than a result linked to that payment. An attempted, pending, unsuccessful or unavailable authentication should not be relabelled successful merely because the checkout continued.
Authentication is a relevant control, not a certificate that every aspect of an order is legitimate. It does not establish that the delivery address is correct, that the goods arrived or that a customer will never raise a complaint. EMVCo also states that participants remain responsible for applicable privacy requirements. Keep necessary references with appropriate access controls rather than placing card secrets, passwords or OTPs in a shared worksheet.
Visa distinguishes authentication, which concerns identity, from authorisation, which concerns whether the transaction can proceed based on matters such as funds and account status. The issuer can approve or decline the payment independently of the authentication result. A message labelled authenticated must not silently become an order status labelled paid.
For each order, identify the provider record that confirms the issuer decision, and then check the capture result if capture is part of the arrangement. Capture and merchant payout are separate questions again. A financial authorisation is not the same as money available in the merchant bank account, while a recorded capture is not a promise that no later dispute or adjustment can occur.
If the authentication and payment screens appear inconsistent, compare the transaction references and ask the provider which financial state is current. Do not combine the successful authentication of one attempt with the payment result of a different attempt. This guide does not prescribe retry rules or integration steps; the linked authorisation and capture guide covers that separate operational task.
Stripe explains liability shift in connection with eligible fraud disputes, while distinguishing other dispute reasons such as a product not received. Its documentation does not make successful 3DS a guarantee of liability shift. A non-receipt dispute still calls for the ordinary evidence and response process applicable to that dispute; authentication does not prove delivery.
Trust Payments likewise warns that successful authentication guarantees neither a shift of liability nor successful authorisation. It says acquirer criteria can change and exceptions depend on the parties facilitating the payment. Treat that page as provider guidance, not a universal worldwide contract. Ask the actual acquirer which scheme, merchant account, transaction type, region and effective rule date govern the order.
Authentication indicators, including an ECI when supplied, are pieces of evidence to interpret in context. A code alone is not a general protection certificate. Ask how the provider interprets the actual authentication outcome, any attempt or exemption, required accompanying information and exceptions. Do not copy one provider table into a worldwide code chart or assume that an exemption has the same liability effect in every arrangement.
Language does not determine the contracting entity or legal rights. This English edition does not establish a US rule, just as another edition does not establish local mandatory authentication law. If a provider reports an eligibility indicator, retain its context and clarify its current status when a dispute arrives. Stripe describes exceptions and later changes; an earlier indicator is not a permanent promise.
Assume an invented online order has a completed successful authentication record and a separate issuer decline. The merchant has evidence about authentication, but no successful financial approval for that attempt. The order must not be described as paid solely because the customer passed a challenge. A staff member should resolve the order state through the provider record and the merchant policy before making a fulfilment decision.
This scenario supplies no real decline rate, processing time or claim about any particular provider. If a later payment attempt exists, it needs its own linked results. The first authentication screenshot cannot replace those results. The useful question is which exact attempt and financial decision the order team is relying on.
Assume instead that the provider confirms capture for a fictional order. Later, one possible allegation is that the cardholder did not authorise the purchase. A different possible allegation is that the goods never arrived. These are alternative cases, not two deductions from a balance. The merchant needs the actual dispute reason before assessing the relevant liability conditions.
In the fraud branch, ask the acquirer whether that transaction qualifies and what authentication evidence supports the assessment. In the non-receipt branch, keep the order, delivery and customer-contact evidence required for that process. Neither branch promises a successful defence or recovery. Stripe also says inquiries still require a response, so do not ignore a notice just because a record shows 3DS.
Record the linked transaction reference, outcome, time and provider description. Distinguish a completed result from a challenge that was merely displayed or started. If the result is absent or unclear, mark it unknown and ask for clarification instead of inventing a success status.
Record the separate financial decision and, where relevant, capture confirmation. Keep payout or bank reconciliation separate. Check that these records refer to the same order and attempt; a successful identity check cannot fill a missing financial result.
Ask which current rule and acquiring arrangement apply, whether the exact transaction is eligible, and which exceptions or missing information affect that answer. Retain the explanation and its date. A generic marketing statement about secure checkout is not an eligibility decision for an individual dispute.
Read the actual notice and provider deadline. Preserve the relevant authentication, payment, order and delivery references and submit what that process requires. Do not infer a deadline from this guide, another country or an unrelated case. Record who will check the notice and respond through the authorised channel.
No. It is authentication evidence. Payment approval and applicable fraud-liability conditions need separate verification, and non-fraud disputes remain different questions. Even a captured payment does not establish guaranteed payout or a successful dispute defence.
No. EMVCo describes data-based assessment that may not require an extra challenge. Read the actual outcome from the provider. Equally, an OTP screen or a customer saying they completed it is not a substitute for the recorded result.
Primary sources read on 22 October 2026. EMVCo provides technical context; Visa, Stripe and Trust Payments provide network or provider guidance. Their documentation does not replace the merchant acquiring agreement or applicable rules.
Use TrustFinance™ to read the related evidence guides and compare the questions you need to ask a provider. A review or a brand name does not establish the liability treatment of a particular transaction.
TrustFinance Research Team
Official TrustFinance research and editorial team, sharing insights, analysis, and best practices to help financial companies and traders build transparency, credibility, and growth.
