For: Anyone sending or managing payment requests via Prommt.
What is 3D Secure 2?
3D Secure 2 (3DS2) is the security standard that protects online card payments. When a customer pays by card via a Prommt payment request, their bank runs an authentication check in the background to confirm the cardholder is the one making the payment — before the transaction is approved.
Depending on the bank and the transaction, authentication might be:
Frictionless — the bank verifies the customer silently in the background with no action required from them. The payment goes through without the customer noticing anything extra.
Challenge — the bank requires the customer to actively verify their identity. This usually means entering a one-time code sent to their phone, approving the payment in their banking app, or completing a biometric check.
Prommt applies 3DS2 to every card payment request. It's not optional — it's a regulatory requirement under Strong Customer Authentication (SCA) rules across the UK and Europe.
Why does this matter for your business?
3DS2 isn't just a compliance checkbox. When authentication completes successfully, fraud liability shifts from your business to the card issuer. If a customer later disputes a fully authenticated payment as fraudulent, your business is protected — the issuing bank carries the liability, not you.
This is why Prommt's card payment requests are low-risk for chargebacks. Every payment goes through 3DS2, and a successful authentication is the strongest protection available under current card scheme rules.
For more on chargeback protection, see Chargebacks and fraud protection.
What the customer experiences
Most customers won't notice 3DS2 at all — the majority of transactions pass frictionlessly. When a challenge is required, here's what typically happens:
The customer taps the payment link and arrives at the Prommt checkout page
They enter their card details and click Pay
They're redirected to their bank's authentication screen
They receive a one-time code by SMS or a push notification in their banking app
They enter the code or approve the prompt
They're returned to the checkout and the payment completes
The whole process takes under a minute when everything works smoothly. The step at point 4 is entirely controlled by the customer's bank — Prommt has no visibility into or control over how each bank delivers its authentication challenge.
When authentication fails
Authentication failures are the most common cause of individual card payment failures on Prommt. Here's what typically goes wrong and how to resolve it.
The customer didn't receive an authentication code
Most likely cause: The mobile number registered with their bank is out of date — the code is going to an old phone number the customer no longer uses.
What to do: Ask the customer to log into their online or mobile banking and check the phone number on file. Once updated with their bank, they should be able to retry the payment.
The customer received the code but the payment still failed
Most likely cause: The code expired before the customer entered it. Authentication codes typically expire within 60–90 seconds.
What to do: Resend the payment request and ask the customer to have their phone ready before they start the checkout process. Once they receive the code, they should enter it immediately.
The customer is paying with a corporate or company card
Most likely cause: The authentication challenge goes to the registered cardholder — not necessarily the person completing the payment. If a PA, booker, or travel manager is paying on behalf of someone else, the challenge arrives on the cardholder's phone, not theirs.
What to do: The registered cardholder needs to be available and expecting an authentication prompt when the payment is being made. Alternatively, if the customer has a personal card available, that will usually authenticate without this complication.
The customer's banking app isn't set up
Most likely cause: Some banks now route authentication through their mobile app rather than SMS. If the app isn't installed or connected to the account, the customer may not receive the authentication prompt at all.
What to do: Ask the customer to download and set up their bank's mobile app, then retry the payment. If they'd rather not do that, ask them to call their bank and request that authentication codes are sent by SMS instead.
The customer completed authentication but the payment still didn't go through
Most likely cause: Either the authentication timed out between the customer completing it and the payment being submitted, or the bank declined the transaction after authentication for a separate reason (e.g. insufficient funds, card restrictions).
What to do: Check the Payment Gateway Response on the failed payment request for the specific reason. See Troubleshooting: individual card declines and payment failures for a breakdown of common response codes.
The customer can't complete authentication on any card
If a customer is unable to authenticate with multiple different cards, the issue is unlikely to be card-specific. Consider whether:
The customer's device or browser is blocking the authentication redirect — ask them to try a different browser or disable any ad-blocking or security extensions
The payment link has expired — check the expiry on the request and resend if needed
There's a connectivity issue on the customer's end
What Prommt can and can't do
Prommt applies 3DS2 to every card payment and ensures the authentication flow is correctly initiated. Beyond that, the authentication process is entirely between the customer and their bank.
Prommt cannot:
Bypass or disable 3DS2 authentication
Resend an authentication code on behalf of a customer's bank
See what happened during the authentication challenge
Override a bank's decision to decline a transaction after authentication
If a customer's bank consistently fails to authenticate them and the steps above don't resolve it, the customer needs to contact their bank directly. The bank is the right party to investigate and fix authentication issues on their side.