Payment Confirmation
Under PSD2, payment confirmation involves verifying the identity of the customer and ensuring the security of the payments. It typically requires the use of two or more factors from the following categories:
- Knowledge factors: Something the end-customer knows, such as a password.
- Possession factors: Something the end-customer possesses, such as a mobile phone
- Inherence factors: Something inherent to the end-customer, such as biometric data (FingerId, FaceID etc.).
The purpose of using multiple factors is to provide an extra layer of security by requiring the end-customer to provide evidence from different categories. This helps to mitigate the risks of unauthorized access and fraud.
PSD2 Exemptions
In line with PSD2, certain outgoing wire transfersWire 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). & sends may be exempted from 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).).
- Low value transaction: payments below €30 or equivalent are not challenged, unless the user exceeds a cumulative transfer amount of €100 (or equivalent) or 5 successful payments or the payment is deemed as high risk.
Contact our support team to enable the Low Value exemption.
- Trusted suppliersSupplier A trusted business or individual that receives payments from Buyers through payment runs. Suppliers can be stored in a trusted supplier list, and when marked as trusted, may allow Buyers to skip Strong Customer Authentication when executing payment runs to those suppliers.: the destination instrumentInstrument A financial product owned by an Identity. There are two types: Managed Accounts (stored-value accounts that hold balances and can receive wire transfers) and Managed Cards (prepaid cards - virtual or physical - used for purchases). of the send payments is the identity's trusted supplierSupplier A trusted business or individual that receives payments from Buyers through payment runs. Suppliers can be stored in a trusted supplier list, and when marked as trusted, may allow Buyers to skip Strong Customer Authentication when executing payment runs to those suppliers. list [insert link].
The status of payments that do not require 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). automatically moves to EXECUTED and no further action is required.
Authentication factors
To verify a Payment RunPayment Run A list of payments created by Buyers to settle their outstanding financial obligations with their suppliers. Payment runs are typically managed by the accounts payable function within a business on a periodic basis and go through stages of creation, authorisation, funding, and execution., the logged-in user with Controller permissions must have enrolled their mobile device for strong customer authentication.
We currently support SMS and Biometrics.
Payment Run Confirmation
For the Payment RunPayment Run A list of payments created by Buyers to settle their outstanding financial obligations with their suppliers. Payment runs are typically managed by the accounts payable function within a business on a periodic basis and go through stages of creation, authorisation, funding, and execution. to be executed, the logged-in user with role Controller must authenticate the Payment RunPayment Run A list of payments created by Buyers to settle their outstanding financial obligations with their suppliers. Payment runs are typically managed by the accounts payable function within a business on a periodic basis and go through stages of creation, authorisation, funding, and execution.
Sending a Challenge
You can trigger the Payment RunPayment Run A list of payments created by Buyers to settle their outstanding financial obligations with their suppliers. Payment runs are typically managed by the accounts payable function within a business on a periodic basis and go through stages of creation, authorisation, funding, and execution. verification process by calling the challenge API. The Controller is requested to perform a two-factor authentication based on the channel.
By default SMS is used, and a text message is sent to the mobile number associated with the user's credentials. For admin users, this is the mobile number provided when onboarding the buyerBuyer A business entity in the Payment Run solution that can be provided with financial services to perform embedded payment runs. Buyers are onboarded through a KYB process and can create payment runs to pay their suppliers. They have roles such as Admin, Controller, and Creator., while for authorized users, this is the mobile number provided when onboarding the user.
If you would like to authenticate the second-factor via SMS, trigger the 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). 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). challenge API endpoint, which sends an OTP via text message.
[link endpoint]
Verifying the Challenge
By default SMS is the selected channel, so you must build a page in your application where the Controller can enter the verification code they received in the text message, then submit it via the challenge verify API.
[link endpoint]