The Revised Payment Services Directive (PSD2) in Europe requires that electronic payments and access to payment accounts be protected by Strong Customer Authentication (SCA). In practice, that usually means two-factor authentication: something the user knows (e.g. PIN), something they have (e.g. phone or token), or something they are (e.g. biometric). If you’re building an open banking or payment product—in the EU, UK, or in jurisdictions that follow similar rules—your flows need to work with SCA, not around it.
When is SCA required?
SCA is required when the user (1) accesses payment account information online, (2) initiates an electronic payment, or (3) carries out any action that might imply a risk of fraud. So when your app asks the bank for account data or initiates a payment, the bank will typically require SCA before releasing data or executing the payment. The user is redirected to the bank (or the bank’s embedded flow), completes SCA there, and is sent back to your app with an auth code. Your backend then exchanges that code for an access token. That’s the flow we implement when we build open banking auth for clients.
Исключения
PSD2 допускает исключения в отдельных случаях: операции на малые суммы (например, до €30), доверенные получатели, регулярные платежи и др. Банки и регуляторы могут применять их по‑разному. Если ваш продукт опирается на исключение, важно понимать местные правила и политику конкретного банка. Даже при наличии исключений тренд — к более единообразной SCA, поэтому безопаснее проектировать флоу согласий и редиректа с учётом SCA в долгую.
Что это значит для вашего продукта
Ваш продукт не выполняет SCA сам — это делает банк. Ваша задача: (1) отправить пользователя на страницу auth банка с правильными параметрами (например, consent ID и redirect URI), (2) принять callback с auth‑кодом и (3) обменять код на токен и безопасно его хранить. Пользовательский путь: «Подключить банк» → редирект → логин/OTP/биометрия в банке → возврат в приложение. Мы строим этот флоу редиректа и обмена токенов так, чтобы ваша интеграция оставалась комплаенс‑готовой, а UX — плавным и безопасным. Мы делали это для Meras и Infinipi и можем сделать для вашего продукта в Пакистане или где угодно.
За пределами Европы
Многие страны внедряют схожие концепции: сильная аутентификация перед передачей данных счета или инициированием платежей. У Пакистана и других рынков могут быть свои правила и банковские практики. Когда мы строим для вас системы open banking или TPP, мы проектируем SCA‑подобные флоу и учитываем локальные требования — чтобы вы были готовы и к текущему, и к будущему регулированию.
Нужно построить auth‑флоу и интеграцию SCA для вашего продукта? Мы можем сделать это для вас.
← Назад в блог