When a card payment is made in a shop, the card and payment terminal provide physical elements that help establish who is paying. An online transaction is different. The merchant usually receives card details, but cannot see the cardholder or the device being used. If stolen card details are entered on a website, the transaction may initially look legitimate.
That is why a bank or card issuer may ask for an additional confirmation before authorising an online purchase. This process is commonly associated with 3-D Secure. Depending on the bank, the confirmation may involve a code sent by text message, approval in a banking application, biometric verification, or another security step.
The additional check is not a request for a new payment, a transfer, or a change to the bank account. It is intended to confirm that the person attempting the purchase is the legitimate cardholder or account user. The exact screen, wording and method depend on the issuer, the payment card, the merchant and the transaction risk assessment.
3-D Secure is a security protocol used to authenticate card payments made online. The name refers to three domains involved in the transaction: the merchant or acquirer domain, the card issuer domain and the interoperability domain that connects the participants. For the consumer, the important point is that the payment can involve a separate authentication step controlled by the card issuer.
Earlier versions of the protocol often redirected the customer to a page requesting a static password or a one-time code. Modern implementations, generally known as EMV 3-D Secure, allow more information about the transaction to be assessed in the background. This can include the merchant, amount, device and transaction context. A payment may then be approved without interrupting the customer, or the issuer may request an active challenge.
3-D Secure does not replace the card authorisation process. It is an authentication layer that can take place before the issuer decides whether to authorise the payment. A successfully authenticated transaction can still be declined because of an insufficient balance, a spending limit, a blocked card, suspected fraud or a technical problem.
In the European Economic Area, the main legal framework is the Payment Services Directive (EU) 2015/2366, commonly called PSD2. Its requirements for strong customer authentication are supplemented by the Commission Delegated Regulation (EU) 2018/389, which sets regulatory technical standards for authentication and communication.
Strong customer authentication, or SCA, normally requires the use of at least two independent elements from different categories:
The elements must be independent. In practical terms, compromising one should not automatically compromise the other. A code displayed inside the same compromised environment as the login credentials may therefore not provide the intended level of protection.
For certain remote electronic payment transactions, the rules also require authentication to be linked to the specific amount and payee. This is known as dynamic linking. The confirmation should make it possible for the customer to identify what is being approved, including the amount and the recipient or merchant. If the amount or payee shown in the banking application does not match the purchase, the transaction should not be approved.
A bank does not necessarily challenge every online payment. The issuer and payment service providers may use transaction data to assess the risk. A low-risk payment may be authenticated in the background, while a higher-risk payment produces a visible request for confirmation.
Regulatory exemptions can also apply. Under the PSD2 technical standards, examples include certain low-value transactions, recurring transactions after the first payment, transactions to a trusted beneficiary and low-risk transactions evaluated under a transaction risk analysis. An exemption is not an unconditional right for the customer. The payment service provider decides whether it can apply the exemption, and the card issuer may still require authentication.
There are also situations that are not treated in the same way as a customer actively initiating a standard card payment. For example, some merchant-initiated transactions occur after a prior agreement and customer authentication. The treatment depends on how the payment was set up and recorded. A subscription payment may therefore be processed differently from the first payment that created the recurring arrangement.
For these reasons, two purchases with the same amount can produce different experiences. The merchant, device, location, previous payment history, card settings and fraud indicators may differ. The absence of a code does not mean that a payment has no security controls, and receiving a code does not by itself prove that a transaction is fraudulent.
A one-time code is generally intended to confirm a particular authentication event. It is not a general password for the bank account. When a customer enters the code, the bank may link the confirmation to the merchant and amount displayed during the process.
An approval in a banking application works in a similar way, although it may use possession of the registered device and a local PIN or biometric factor. The customer should read the transaction details before approving. Important points include:
A legitimate bank employee should not need a customer to disclose a one-time authentication code by telephone, email or message. The code is entered only in the official authentication screen associated with the payment or banking application. A request to read the code aloud so that someone can “cancel” a payment is a warning sign.
A failed authentication does not always mean that the card is blocked. The cause may be a wrong code, an expired code, a disconnected mobile device, an outdated banking application, a time limit, a card setting or a temporary technical issue. The merchant may also have submitted incomplete or inconsistent transaction data.
The following sequence can help:
If the payment was declined but money appears to have been reserved, the entry may be a temporary authorisation hold rather than a completed debit. The time required for a hold to disappear depends on the issuer, the merchant and the card scheme. The bank can explain the status shown on the account and whether the merchant has captured the payment.
Fraudsters sometimes exploit the security process itself. They may claim that a payment is suspicious and ask the customer to approve a request in order to cancel it. In reality, approving the request may confirm a new payment or another operation.
Several precautions reduce this risk:
If an unauthorised payment has been approved or card details may have been exposed, contact the card issuer promptly. The card may need to be frozen or replaced, and the disputed transaction may need to be reported through the issuer’s formal process. Preserve relevant messages and transaction information, but do not continue communicating with a suspected fraudster.
Strong customer authentication helps verify the person approving a payment, but it does not guarantee that the merchant is trustworthy or that the goods will be delivered. A customer can be deceived into approving a payment to a fraudulent seller, a fake investment service or a criminal posing as a supplier.
Authentication also does not eliminate all forms of card fraud. It may not cover every transaction type, and some payments may be processed under an exemption or outside the relevant regulatory scope. The customer should therefore continue to check the website, invoice, recipient, amount and purpose of a payment before approving it.
Where an investment, loan, insurance or other financial service is involved, authentication confirms an operation, not the quality or legality of the underlying offer. It should never be treated as evidence that a promised profit, return or financial product is genuine. Financial products can involve fees and, where capital is invested, a risk of loss.
The legal treatment of an unauthorised payment depends on the facts, the applicable law, the payment method and whether the customer acted fraudulently or with gross negligence. PSD2 contains rules on reporting unauthorised or incorrectly executed payment transactions, but national implementation and the circumstances of the case matter.
A customer who notices an unfamiliar transaction should notify the payment service provider without undue delay and follow its dispute procedure. Waiting can make investigation more difficult. The customer should also ask whether the transaction is pending or completed, whether it was authenticated, and which payment instrument was used.
Authentication records can be relevant, but a successful authentication does not automatically settle every question about authorisation. The issuer may examine device information, transaction data, customer reports and other evidence. The customer should describe precisely what happened, including whether a code was entered, whether an application approval was made and whether contact with a suspected fraudster occurred.
The method requested by the bank can vary according to the account setup and the available security technology. Each method has advantages and limitations:
| Method | What it uses | Practical point |
|---|---|---|
| One-time SMS code | Possession of a registered phone number | Useful when the phone is available, but customers must watch for number takeover and never disclose the code. |
| Banking application approval | Registered device, often combined with a PIN or biometric | Read the amount and payee shown in the application before confirming. |
| Hardware authentication device | A separate physical security device | Keep the device secure and follow the issuer’s instructions for generating or confirming a transaction code. |
| Biometric confirmation | Fingerprint or facial recognition on a compatible device | Biometrics unlock the approved device or application; they do not make an unfamiliar payment safe. |
No method removes the need for careful review. Security depends on the bank’s systems, the device, the merchant information and the customer’s decision to approve the exact transaction.
If the authentication process is unclear or repeatedly fails, the card issuer can clarify the account-specific situation. Useful questions include:
Keeping contact details and the banking application up to date can reduce avoidable failures. However, a request for authentication should always be judged by the transaction details, not merely by the fact that it appears inside a familiar application.
Is 3-D Secure the same as strong customer authentication?
Not exactly. 3-D Secure is a protocol used mainly for online card payments. Strong customer authentication is a regulatory security requirement based on independent authentication factors. A 3-D Secure transaction may be used to meet SCA requirements, but the concepts are not identical.
Why did my bank ask for a code for a small purchase?
The issuer may decide not to apply an exemption, or the transaction may have generated a risk signal. Exemptions are subject to conditions and are not guaranteed for every low-value payment.
Can I approve a code request to cancel a fraudulent payment?
No. An approval normally confirms the transaction displayed. If the request is unexpected, refuse it and contact the issuer through an official channel.
Does a successful 3-D Secure check guarantee reimbursement if something goes wrong?
No. Authentication and reimbursement are separate issues. The outcome depends on the transaction, applicable rules, the evidence and the customer’s conduct.
What should I do if the amount shown in the app is different?
Do not approve the request. Close the process if appropriate and contact the card issuer or merchant using verified contact details.
