SCA challenges

A challenge is a request from Weavr asking the end-user to prove who they are before a sensitive action is allowed to complete. Challenges are how Weavr enforces Strong Customer Authentication (SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).) - the PSD2 requirement that certain actions are protected by two independent authentication factors.

This page explains what SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics). is, when a challenge is raised, and how a challenge is delivered and answered. It is the conceptual reference behind the step-up, transaction confirmation, 3DS3DS 3-D Secure - an additional security layer for online credit and debit card transactions. It adds an authentication step where the cardholder verifies their identity with the card issuer during the purchase, reducing fraud and providing liability protection for merchants., and biometric SDK flows documented elsewhere.

What SCA is

The revised Payment Services Directive (PSD2) requires that, for certain actions, the end-user authenticates with at least two factors from different categories:

• Knowledge - something the user knows, such as a password, passcode, or PINPIN Personal Identification Number - the numeric code a cardholder enters to authorize chip-and-PIN purchases and ATM withdrawals. PIN is only present on physical managed cards. Weavr returns it tokenized on `GET /managed_cards/{id}` (with a stepped-up token), and the SDK detokenizes it inside a secure PIN display component..
• Possession - something the user has, such as their enrolled mobile device or the phone number that receives an SMS.
• Inherence - something the user is, such as a fingerprint or face (Face ID, Touch ID).

Requiring two factors from different categories makes it much harder for an attacker to act as the user, even if one factor is compromised.

One biometric verification, two factors

A single biometric verification on an enrolled device satisfies two factors at once - possession (the enrolled device) and inherence (the biometry). This is why biometrics is the smoothest way to clear a challenge. See biometric authentication in the mobile SDKs.

When a challenge is raised

A challenge is raised whenever the user attempts an action that PSD2 protects. There are four situations, each documented in its own guide:

Situation	What it is called	When it happens	Reference
Accessing account or sensitive card data	Step-up	The user views account information, reads older statements, sees full card details, or creates a user.	Step-up authentication
Sending money	Transaction confirmation	The user initiates an SendSend A transaction type that allows sending funds to another identity's instrument or to a beneficiary. Send transactions may require Strong Customer Authentication depending on the destination and whether it's a trusted beneficiary. or outgoing wire transferWire Transfer A transaction that moves funds between accounts. An incoming wire transfer moves funds from a third-party bank account to a Weavr managed account, while an outgoing wire transfer moves funds from a Weavr managed account to a third-party bank account. Wire transfers require the managed account to have an assigned IBAN (for EUR) or sort code and account number (for GBP). (single or bulk).	Transaction confirmation
Paying online with a card	3DS3DS 3-D Secure - an additional security layer for online credit and debit card transactions. It adds an authentication step where the cardholder verifies their identity with the card issuer during the purchase, reducing fraud and providing liability protection for merchants.	The user pays at an online checkout that requires 3-D Secure approval.	3DS authentication
Managing trusted payeesTrusted Payee A trusted recipient for payments, including the business or individual's details and their bank account or instrument details. Sending to a Trusted Payee may let customers skip Strong Customer Authentication (SCA) on Outgoing Wire Transfer or Send transactions, reducing the number of approval steps required. Previously referred to as a Beneficiary.	BeneficiaryBeneficiary A trusted recipient for payments that includes both information about the business or individual as well as their bank account or instrument details. When using trusted beneficiaries, customers may be allowed to skip Strong Customer Authentication (SCA) when executing Outgoing Wire Transfer or Send transactions, reducing the number of approval steps required. Now referred to as a Trusted Payee. management	The user adds payees to their trusted list so future payments to them are exempt.	Trusted payees

Some payments are exempt

Under PSD2, low-value payments and payments to trusted payeesTrusted Payee A trusted recipient for payments, including the business or individual's details and their bank account or instrument details. Sending to a Trusted Payee may let customers skip Strong Customer Authentication (SCA) on Outgoing Wire Transfer or Send transactions, reducing the number of approval steps required. Previously referred to as a Beneficiary. can be exempt from SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics)., so no challenge is raised. See PSD2 exemptions.

How a challenge is answered

When a challenge is raised, the user clears it with one of two factor channels. Which channels are available depends on what the user has enrolled and how you have configured your program in the Embedder Portal.

SMS one-time password (OTP)

Weavr sends a one-time password by SMS to the user's registered mobile number. You build a screen in your app where the user enters the code, then submit it to Weavr to clear the challenge. The SMS itself is the possession factor.

This channel is driven entirely from the API - see step-up and transaction confirmation for the endpoints.

Biometrics (mobile SDK)

On a device the user has enrolled for biometrics, Weavr delivers the challenge by push notification. Your app forwards the notification to our mobile SDK, which presents a branded approval screen, captures the user's biometrics, and clears the challenge. The enrolled device is the possession factor and the biometry is the inherence factor.

Push notifications exist primarily to deliver these challenges. Setting up push is therefore part of integrating biometric SCASCA Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics)., not a separate feature. See the mobile SDK guides for iOS, Android, and React Native.

Where a challenge comes from

Challenges are triggered from one of two places:

1. From inside your app. The user does something in your app - sends money, views card details, adds a trusted payeeTrusted Payee A trusted recipient for payments, including the business or individual's details and their bank account or instrument details. Sending to a Trusted Payee may let customers skip Strong Customer Authentication (SCA) on Outgoing Wire Transfer or Send transactions, reducing the number of approval steps required. Previously referred to as a Beneficiary.. Your backend asks Weavr to raise the challenge. For biometrics, use the push variants, such as the Confirmation Challenges and Trusted payees endpoints.

2. From outside your app. The user does something elsewhere that needs approval - most commonly a card purchase at an online checkout that triggers 3DS3DS 3-D Secure - an additional security layer for online credit and debit card transactions. It adds an authentication step where the cardholder verifies their identity with the card issuer during the purchase, reducing fraud and providing liability protection for merchants.. Weavr raises the challenge and pushes it to the user's device; the user taps the notification to open your app and approve.

Challenge lifecycle

Whichever channel and origin apply, a challenge follows the same shape:

1. Triggered - by an action in your app or an external event such as a 3DS3DS 3-D Secure - an additional security layer for online credit and debit card transactions. It adds an authentication step where the cardholder verifies their identity with the card issuer during the purchase, reducing fraud and providing liability protection for merchants. purchase.
2. Delivered - by push notification (biometrics) or SMS (OTP).
3. Answered - the user approves with biometrics, or enters the OTP.
4. Verified - Weavr checks the response and, on success, lets the original action proceed (the transaction executes, the session is stepped up, the purchase completes).

Challenges expire

Challenges expire after 5 minutes and limit the number of incorrect attempts. Once attempts are exhausted, the action is rejected and a new challenge must be raised. Exact behavior per channel is covered in step-up and transaction confirmation.

Prerequisite: device enrollment

Before a user can clear challenges by SMS or biometrics, their device must be enrolled as an authentication factor. Enrollment is initiated from the mobile SDK and, as part of the flow, also enrolls the user's phone number for SMS. See enrolling a device and onboarding a user's device.