TL;DR: Payment authentication under PSD2 requires Strong Customer Authentication (SCA) for most UK electronic payments. For card payments, platforms or their payment providers often manage authentication challenges, exemptions and soft declines. With Open Banking Pay by Bank, the customer’s bank performs the authentication inside its own app, removing platform-side SCA implementation for those payment flows.
Why Does Payment Authentication Become an Engineering Challenge?
Accepting online payments is relatively straightforward. Building a payment flow that complies with PSD2 is often far more complex.
For many platforms, the difficulty is not processing the payment itself but implementing Strong Customer Authentication (SCA) correctly. Card payment journeys can require authentication challenges, exemption handling and recovery from soft declines, all while maintaining a smooth checkout experience. Every additional authentication step introduces engineering effort and another opportunity for customer abandonment.
Open Banking Pay by Bank follows a different model. Instead of the platform managing authentication, the customer is redirected to their own banking app, where the bank performs SCA using its existing security methods before authorising the payment.
This guide explains how payment authentication works under PSD2, when SCA is required, how card and Open Banking payment flows differ, and why bank-managed authentication can simplify payment integration for UK platforms.
“Under current UK Payment Services Regulations, the SCA obligation sits with the party initiating or facilitating the payment. For card flows, that often means the platform. For Open Banking PIS, it means the bank, and that distinction matters more than most engineering teams realise until they are already mid-implementation.”
By Clare, Regulatory and Compliance Lead at Finexer
The Platform Engineering Problem With SCA
Constructing a card payment flow is quite distinct from adding SCA to the structure. Engineering teams that miss this initially, only to discover it when they are mid-implementation, discover significant additional complexity.
SCA under UK PSD2 mandates platforms that accept payment by card to deal with authentication challenges, wherein they decide the point of trigger, the recipients of exemption, the course of action to be followed upon a bank refusing exemption by softly declining it and the way to bring the user back on track in their journey after resolving an unforeseen challenge that presents midway through a transaction.
Each is a distinct engineering challenge. These are all the reasons why SCA integration runs behind schedule almost every time a card payment is implemented.
The user-facing consequence is significant. When a bank sends an unexpected SCA challenge mid-transaction, that is, after payment detail entry, users who encounter an unexpected authentication step start abandoning purchases. A significant share of users prefer not to complete the transaction.
What SCA Requires Under PSD2?
Strong Customer Authentication (SCA) requires verification using at least two of three factor types before a UK electronic payment is processed:
- Knowledge: Something known to the user – PIN, password or security question
- Possession: Something possessed by the user – registered mobile device or hardware token
- Inherence: Some unique user characteristics – fingerprint, face ID or voice recognition
Two of the above three are required, each being independent, in that, if one fails, it does not affect the results of the others. Also, each must be linked to a specific transaction amount and payee in an event-driven manner, such that the authentication does not lend itself to being replayed for another payment.
SCA Exemptions – Brief Overview
There are some transactions that do not require full SCA. The UK permits exemptions under particular circumstances:
- Low-value transactions – under £30, with all items purchased in a transaction accounting for a cumulative amount
- Merchant-initiated transactions – with the customer authorising a series of payments
- Transaction risk analysis (TRA) – with PSP fraud rate well under defined thresholds
- Trusted beneficiary – with the payee having previously whitelisted the payer
- Recurring transactions – SCA on the first payment only, not on subsequent payments
Applying exemptions accurately on card payments entails the platform or its PSP to manage logic, trigger exemption with precision in an authorisation request and handle soft declines by the issuing bank. Exemption management is ongoing and not a one-time activity. See PSD2 Open Banking compliance for the full regulatory context.
How Open Banking PIS Handles Authentication Differently?
Open Banking payment initiation decouples the platform from SCA entirely when it comes to Open Banking flows.
When a customer pays by way of Pay by Bank, the process is as follows:
- The customer selects Pay by Bank at the point of sale
- They are redirected to their banking app or online banking portal
- The bank throws up its own SCA challenge involving biometrics and PIN
- The customer validates directly with their bank
- The payment is effected by way of Faster Payments
The platform does not apply SCA challenges, manage exemptions or handle soft declines. The onus of authentication is entirely on the bank, which uses SCA in the same manner as that which the customer would have used many times previously in that banking app.
An Open Banking PIS flow is fundamentally different from card SCA in that, in the latter, the platform is situated in the authentication chain, whereas in the former, it isn’t.
Note: Pay by Bank eliminates platform-side SCA application solely for Open Banking flows. For card payments, the platform still retains its SCA onus. Pay by Bank doesn’t do away with all SCA requirements; instead, it removes platform-side SCA from the equation when it comes to Open Banking flows.Card SCA vs Open Banking PIS: Authentication Compared
| Factor | Card SCA Flow | Open Banking PIS Flow |
|---|---|---|
| SCA Challenge | Platform or PSP executes the challenge and user interface | Bank-native, inside the customer’s banking app |
| Exemption Management | Platform or PSP claims and manages exemptions | Not required for Open Banking flows |
| Soft Decline Handling | Platform manages the contingency and retry logic | Not applicable |
| Abandonment Risk | Higher — unexpected authentication challenge mid-checkout | Lower — authentication is expected at checkout |
| Platform Engineering Required | Considerable — challenges, exemptions and fallback flows | Minimal — redirection and webhook confirmation |
| Authentication Method | Varies by bank and card issuer | Bank-native biometrics and PIN |
Finexer PIS: FCA-Authorised Authentication at the Bank Layer
FCA-authorised payment infrastructure via Finexer’s PIS ensures that platforms integrating it do not build SCA for their Open Banking flows, as that is the bank’s onus. Finexer, which is authorised by FCA as a Payment Initiation Service Provider, sits between platform and bank, initiating payment initiation requests and returning event statuses by applying webhooks at each event during a transaction.
- FCA-authorised PISP – FRN925695
- 99% UK bank coverage (Barclays, HSBC, NatWest, Lloyds, Monzo, Starling, Revolut and more)
- Payment status webhooks – Authorised – Submitted – Received – no polling required
- White-label – customers authenticate inside their bank, not a Finexer-branded screen
- Usage-based pricing – platforms pay for what they use
- 3–5 weeks onboarding support
What is payment authentication under PSD2?
Payment authentication under PSD2 confirms the person initiating payment as the legitimate accountholder. UK regulations call for Strong Customer Authentication, with two of three factor types linked in a context-bound manner to a specific transaction.
Does Open Banking Pay by Bank require SCA?
Yes, but the bank manages it and not the platform. The customer authenticates within their banking app and uses their bank’s SCA, with the platform relieved of SCA challenge implementation and exemption management for those OB flows.
What is a soft decline in payment authentication?
A soft decline is one where an issuing bank rejects a request for authorisation for want of SCA application or because of rejection of a claim for exemption. The platform then retries, applying a full SCA challenge, which remains a core engineering bottleneck of card SCA.
What is the difference between SCA for card payments and Open Banking?
In a card payment transaction, the platform handles SCA challenges, exemptions, and soft declines. As for Open Banking PIS, the onus of authentication lies entirely with the bank, with the platform not featuring in authentication.
Finexer’s FCA-authorised PIS delivers SCA-compliant bank-to-bank payments without the platform having to implement challenges
About the Author
Clare Pearson
Clare Pearson is a senior payments professional with extensive experience across the global financial services and payments industry. She specialises in Open Banking, payment infrastructure, and financial technology transformation, with expertise spanning product delivery, operational strategy, regulatory compliance, and large-scale payments programmes. Clare currently serves as a Non-Executive Director at Finexer and a panel member for the Payment Systems Regulator (PSR), advising on the development of payment systems policy and innovation