PSD2 quick guide

PSD2 (the revised Payment Services Directive) is the EU regulation that governs how payment service providersPSP Payment Service Provider - a regulated financial institution (such as a bank or e-money institution) that provides payment services like holding accounts, issuing cards, or executing transfers. PSPs are referenced as the holders of external accounts in features such as Linked Accounts, Confirmation of Payee, and Verification of Payee. protect their customers from fraud. As a regulated EMI (Electronic Money Institution), we operate under PSD2 - and so does any programmeProgramme A programme represents your application within Weavr. Everything you create - Identities, Instruments, Transactions - sits beneath a Programme. When you register as an Embedder, you receive a Programme in the Sandbox and, once approved, one in Production. built on our platform.

This page summarizes what PSD2 requires, what we handle on your behalf, and what you need to plan for. For implementation detail, follow the links into the API and SDK docs.

Why PSD2 applies

PSD2 is the legal framework that sits behind our authentication and transaction-confirmation requirements. Two parts of it shape day-to-day integration work:

• 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).) - end-users must complete a two-factor authentication before performing sensitive operations.
• Transaction confirmation - certain outgoing payments must be authenticated by the user before they settle.

Both are enforced by the API. You can't switch them off, but you can shape when and how they happen in your UI.

What SCA requires

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). means the end-user proves their identity using two of three factor categories:

• Knowledge - something the user knows, such as a password.
• Possession - something the user has, such as a registered mobile device.
• Inherence - something the user is, such as a Face ID or Touch ID biometric.

The first factor is always the user's login credential (password). The second factor is delivered through one of the channels we support: an SMS OTP, or an embedded biometric prompt via our mobile SDKs.

What we handle for you

We run the 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). machinery end-to-end. You don't need to build factor management, challenge orchestration, or the cryptography that proves a token has been stepped up. Specifically, we:

• Issue and track stepped-up Auth Tokens that unlock 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).-gated endpoints.
• Generate and verify OTP challenges for both step-up and transaction confirmation.
• Provide biometric enrolment through our mobile SDKs as an alternative second factor.
• Apply PSD2 exemptions to qualifying transactions automatically.
• Expose secure UI components that let your app display or capture sensitive card data without ever touching the raw values - keeping you aligned with PSD2 and out of PCI scope.

What you must do

Even though we run the 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). flow, you still own the integration:

• Enrol the user's device. Before an end-user can complete an 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, their mobile device must be enrolled. See Enrol the new user's device.
• Step up before sensitive operations. Calls that view sensitive card details, manage authorised usersAuthorised Users Individuals that have been invited by the root user to manage an identity's instruments and transactions. They are not the legal owners of the identity but can be granted access to perform operations on behalf of the identity. For corporates, card assignees are created as Authorised Users., or read older statements need a stepped-up tokenStepped-up token An access token that has been elevated to a higher authentication level by successfully completing a step-up challenge (typically an OTP via SMS or a biometric prompt). A stepped-up token is required to perform sensitive operations such as creating a user, managing authentication factors, or confirming high-value transactions. See the [step-up authentication guide](/apis/authentication/stepup/) for how to issue and complete a challenge.. See Step-up authentication for the full list of gated endpoints and UI components.
• Confirm transactions. 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). and sends must be authenticated by the user (unless exempted). See Transaction confirmation.
• Use our secure components for sensitive data. Showing or capturing a full PANPAN Primary Account Number - the long card number (typically 16 digits) printed or embossed on a payment card and used to identify the card on the payment network. Weavr never returns the raw PAN to your client; `GET /managed_cards/{id}` returns the PAN in tokenized form as `cardNumber`, and the value is only detokenized inside a Secure UI card-number component (a sandboxed iframe on the web, a secure native view on mobile)., CVVCVV Card Verification Value - the 3-digit security code printed on a payment card, used to authenticate card-not-present transactions. Weavr returns CVV in tokenized form on `GET /managed_cards/{id}` (with a stepped-up token); the value is only detokenized inside the SDK's secure CVV display component., 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. must go through our secure components - your app code never sees the cleartext value.

PSD2 exemptions

PSD2 allows certain transactions to skip 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).. We apply these automatically where the rules and your configuration allow it:

• Low-value transactions - sends and 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). below €30 (or equivalent) skip 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)., until the user crosses a cumulative limit of €100 or 5 successful transactions, or the transaction is flagged as high-risk. Contact our support team to turn on the low-value exemption.
• Trusted beneficiaries - sends to a 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. on the identity's trusted beneficiary list skip 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)..

Exempted transactions move straight to EXECUTED - no challenge, no further action from your app.

Where to go next

• Step-up authentication - how to step up a user's token and the full list of 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).-gated endpoints and components.
• Transaction confirmation - how to challenge and verify outgoing transactions.
• Secure components model - how our SDKs keep your app aligned with PSD2 and PCI requirements when handling sensitive card data.
• Trusted beneficiaries - reduce the number of 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). challenges on recurring payouts.

If you're unsure which PSD2 obligations apply to your programmeProgramme A programme represents your application within Weavr. Everything you create - Identities, Instruments, Transactions - sits beneath a Programme. When you register as an Embedder, you receive a Programme in the Sandbox and, once approved, one in Production., contact our support team.