• Fixes the capitalization of "Nein" in the enrollment flow for consistency with the rest of the UI.

Added (adoption is optional)​

• Added German localization to the SDK by adopting iOS v3.5.0 and Android v3.10.4.

Set a user’s mobile during the invite process​

We have introduced an alternative way to set a user’s mobile number when onboarding a user through the invite process.

At the point of creating an additional user for your embedded finance 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., a mobile number for that user may not be known. It is already possible to create a user without a mobile; but previously, for users being onboarded via the user-invitation flow, it was possible to update the user’s mobile number (via PATCH/users) after the login from the user invite. However, following the "Linked card user" change, it is mandatory for a user-session to be stepped-up in order to call PATCH/users. If a mobile number has not been set then this would not be possible.

To accommodate flows where the user provides their phone number as part of a user-onboarding flow, mobile can now be provided when consuming a user invite, which does not require a stepped up token.

Effected endpoints:

An optional mobile field has been added, which will set the user’s phone number, that can be enrolled for OTPs as part of your remaining user-onboarding flow.

Added​

• German (de) localization — all SDK UI strings are now available in German across every flow.

Added (adoption is optional)​

• Added German localization to the SDK.

Fixed​

• Build-time class collision - fixed a duplicate class error at dex-merge that occurred when the app also depended on a third-party library using aggressive code obfuscation.

Low balance webhook notification​

We can now send a webhook notification when the balance of an account drops below a configured threshold. This lets you react proactively-for example by automatically initiating a top-up-before transactions start failing due to insufficient funds.

A single webhook fires when the balance crosses the threshold; further transactions while still below the threshold do not trigger additional webhooks. The notification becomes eligible to fire again only after the balance has recovered to or beyond the threshold.

Thresholds are configured per currency, so you can set independent values for EUR, GBP, and any other currencies 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. supports. The feature is available on request-contact our support team with the currency and threshold amount you need.

For full details, see the low-balance webhook documentation and the webhook payload reference.

Fund movements dashboard on Data Insights​

A new Fund movements dashboard is available in Data Insights. It presents a clear view of 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.'s financial activity for a given period, broken down into:

• Inflows-funds received successfully into instrumentsInstrument 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).
• Outflows-funds successfully leaving instrumentsInstrument 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).
• End-of-month balance-to support period-end reporting

Data can be filtered by identity and time range, so you can focus on the view most relevant to your needs.

User roles visible in the Corporates dashboard​

Following the release of user roles in March, the Data Insights CorporatesCorporates Business entities that can be onboarded as identities on Weavr. Corporate identities represent companies and require Know Your Business (KYB) verification. They can have multiple authorised users and issue cards to card assignees. dashboard now surfaces role assignments. Roles appear as a comma-separated list per user in the Corporate Users table, giving you a consolidated view of access levels across your user base.

Enhanced card-level filtering in Data Insights​

To improve card-level visibility and simplify how activity is traced back to individual cards, we have added new filters and columns across several Data Insights dashboards:

• Card Friendly Name and Managed Card ID are now available as filters in the Authorisations, Settlements, Managed CardsManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User., and Physical CardsPhysical Card A payment card that is printed or embedded in wearables and sent to customers directly. Physical cards are created by first creating a virtual card and then upgrading it to a physical card. They are sent in an inactive state and must be activated by the card assignee before first use. dashboards.
• Card Friendly Name is now also a column in the Details table of all dashboards.

This makes the dashboards better suited to day-to-day operational queries and investigations.

Mobile SDK improvements​

This release ships alongside several mobile SDK updates:

• Biometric enrollment improvements-more granular failure responses, an inactivity timeout during enrollment, and clearer error messages when a session is interrupted. See: React Native v5.3.0, iOS v3.4.0, and Android v3.9.0.
• Step-up authentication reliability-clearer failure messages when SDK configuration or Play Integrity checks are still being prepared. See: React Native v5.3.1, Android v3.10.0.

Upcoming breaking changes​

Two breaking changes announced in our March 2026 release require integration work before the production deadline of October 31, 2026:

• Verification of PayeeVerification of Payee The EU equivalent of Confirmation of Payee (CoP). A service that validates the name of a payment beneficiary against the IBAN registered with their bank or Payment Service Provider (PSP) before a SEPA payment is executed. for EUR 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).-mandated by the EU Instant Payments Regulation (IPR). Applies to programmesProgramme 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. with OWTsOWT Outgoing Wire Transfer - a transaction that moves funds from a Weavr managed account to a bank account held at a third-party financial institution. OWTs require the managed account to have an assigned IBAN and the user to complete Strong Customer Authentication. in EUR. See the VoP overview and the create and execute guide.
• Linked Card UsersCard User The person that a card is assigned to and who will use the card for purchases. Weavr does not support anonymous cards, and therefore all cards must be linked to a card user before a card can be used. For consumers, the card owner and the card user is typically the same person. For corporates, the card users are employees or individuals authorised to spend the corporate's funds.-every active managed cardManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User. must be linked to a user with complete mandatory data and 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. enrollment. Applies to programmesProgramme 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. that issue cards. See the virtual cards documentation, authorised user onboarding, and 3DS configuration.

To enable either feature on your sandbox account, contact our support team.

Fixed​

• Fixed biometric enrollment race condition on initialisation.

Fixed​

• Fixed biometric enrollment race condition on initialisation (resolved in Android SDK 3.10.2)

Fixed​

• Fixed biometric enrollment race condition on initialisation.

Changed​

• Bumped Android components dependency to 3.10.0
• When a security-sensitive user journey (e.g., enrollment, biometric login, or step-up approval) fails because configuration or Play Integrity could not be ready in time, WeavrError.message may now include a more specific reason (such as timeout or token failure) instead of a generic network error

Fixed​

• Fixed cases where enrollment, biometric login, or step-up approval could start before Play Integrity was fully ready, which could lead to missing integrity data or a poor user experience (resolved in Android SDK 3.10.0)

Changed​

• Error messages on failure-when a security-sensitive user journey (for example, enrollment, biometric login, or step-up approval) fails because configuration or Play Integrity could not be ready in time, listeners and callbacks may receive a more specific ErrorResponse.message (including a short reason such as timeout or token failure) instead of a generic network error.

Fixed​

• Timing around config and PSAPSA Push Step-up Authentication - the mechanism in our mobile SDKs that delivers a step-up challenge to an enrolled device as a push notification and verifies it with the user's device biometrics. PSA covers device enrollment, biometric login, and biometric verification of SCA challenges for sensitive operations such as outgoing wire transfers or accessing card details. Exposed as `UXComponents.psa` on iOS and Android and via `initializePSA` on React Native. flows-fixed cases where enrollment, biometric login, or step-up approval could start before Play Integrity was fully ready, which could lead to missing integrity data or a poor user experience.

Changed​

• Updated iOS SDK version to v3.4.0

Changed​

• Updated iOS SDK version to v3.4.0
• Updated Android SDK version to v3.9.0

Added​

• BiometricsEnrollmentResult to define the potential outcomes of the enrollment process.

Changed​

• Updated iOS SDK version to 3.4.0
• Updated Android SDK version to 3.9.0

Deprecated​

• Deprecated startEnrollment(firebaseToken: string, authToken: string): Promise<Result<string, WeavrError>>; in favor of startEnrollment(): Promise<BiometricsEnrollmentResult>;

Migration guide​

Update any calls to startEnrollment(firebaseToken: string, authToken: string) to startEnrollment(), making sure you take the following actions:

• Ensure you have provided a fresh token to setUserToken()
• Ensure you have provided a fresh Firebase Cloud Messaging (FCM) token via updateFCMToken()
• Update your call to startEnrollment to a snippet similar to:

let result = await startEnrollment();

switch (result.case) {
  case "completed":
    console.log("Enrollment completed");
    break;

  case "initialisationError":
    console.log("SDK not initialised:" + result.error);
    break;

  case "cryptographyError":
    console.log("Cryptography error:" + result.error);
    break;

  case "noBiometricsAvailable":
    switch (result.biometricAvailability) {
      case "noneEnrolled":
        console.log("Device supports biometrics but none are enrolled");
        break;

      case "hwUnavailable":
        console.log("Biometrics hardware is temporarily unavailable");
        break;

      case "noHardware":
        console.log("Device has no biometrics hardware");
        break;
    }
    break;

  case "challengeFailed":
    console.log("Challenge failed:" + result.cause);
    break;

  case "failedBiometricsChallenge":
    console.log("User failed biometrics challenge");
    break;

  case "unauthorized":
    console.log("Unauthorized. Please sign in again.");
    break;

  case "userDoesNotConsent":
    console.log("User did not consent to enrollment");
    break;

  case "failedToLoadBrand":
    console.log("Failed to load biometrics configuration");
    break;

  case "noPhoneNumberAvailable":
    console.log("No phone number available");
    break;
}

Added​

• Added startEnrollment(activity, certificates, completion) to improve the result reporting of enrollment flow via WeavrEnrollmentResult.

Changed​

• Improved SDK initialization performance-internal security token generation is now deferred until first use, reducing startup latency.

Fixed​

• Fixed 401 responses during enrollment not dismissing the flow correctly.

Deprecated​

• Deprecated startPSAEnrollment(activity, firebaseToken, authToken, certificates, listener) in favor of startEnrollment(activity, certificates, completion).

Migration guide​

To adopt the new startEnrollment method you need to take the following actions:

Ensure you have called the following prerequisites in order:

1. UXComponents.initialize(context, env, uiKey)-at app startup
2. UXComponents.psa.initialize(context, psaENV, logger)-at app startup
3. UXComponents.setUserToken(context, token, listener)-after user login
4. UXComponents.psa.updateDeviceToken(fcmToken, listener)-after user login

Update your calling site to a snippet similar to the following:

UXComponents.psa.startEnrollment(
    activity = this,
    certificates = R.array.com_google_android_gms_fonts_certs,
    completion = { result ->
        when (result) {
            is WeavrEnrollmentResult.Completed ->
                println("The enrollment was completed successfully")
            is WeavrEnrollmentResult.InitialisationError ->
                println("There was an error while initialising the enrollment flow: ${result.error}")
            is WeavrEnrollmentResult.CryptographyError ->
                println("There was an error in the cryptography operations: ${result.error}")
            is WeavrEnrollmentResult.FailedBiometricsChallenge ->
                println("The user failed the biometrics challenge")
            is WeavrEnrollmentResult.Unauthorized ->
                println("The token present in the SDK is not valid")
            is WeavrEnrollmentResult.UserDoesNotConsent ->
                println("The user cancelled the flow")
            is WeavrEnrollmentResult.FailedToLoadBrand ->
                println("Failed to load the brand configuration")
            is WeavrEnrollmentResult.NoPhoneNumberAvailable ->
                println("No phone number available to perform the SMS OTP flow")
            is WeavrEnrollmentResult.NoBiometricsAvailable ->
                println("No biometrics available. Availability: ${result.availability}")
            is WeavrEnrollmentResult.ChallengeFailed ->
                println("The challenge failed due to ${result.cause}")
        }
    }
)

Result reference​

Added (adoption is optional)​

• Added startEnrollment(viewController:completion:) to improve the result reporting of enrollment flow via BiometricsEnrollmentResult.
• Added credentials to WeavrSecureLoginData.

Changed (also optional)​

• Surfaced HTTP 401 errors in startEnrollment(vc:token:completion:) by providing an ErrorResponse with a 401 code. This code should be handled by triggering a new login, and setting the token on the SDK again via UXComponents.
• Improved wording on alerts displayed during the start of the enrollment flow.

Fixed​

• Fixed scenarios where SecureCardNumberLabel fails to detokenize without reporting an error.

Deprecated​

• Deprecated startEnrollment(vc:token:completion:) in favor of startEnrollment(viewController:completion:).

Migration guide​

To adopt the new startEnrollment method you just need to take the following actions:

• Ensure you have provided a fresh token to UXComponents.setUserToken(token:)
• Update your calling site to a snippet similar to the following:

UXComponents.psa.startEnrollment(viewController: viewController) { res in
    switch res {
    case .completed:
        print("The enrollment was completed successfully")
    case .initialisationError(error: let error):
        print("There was an error while initialising the enrollment flow: \(error)")
    case .cryptographyError(error: let error):
        print("There was an error in the cryptography operations of the enrollment flow: \(error)")
    case .failedBiometricsChallenge:
        print("The user failed the biometrics challenge")
    case .unauthorized:
        print("The token present in the SDK is not valid")
    case .userDoesNotConsent:
        print("The user cancelled the flow")
    case .failedToLoadBrand:
        print("Failed to load the brand configuration.")
    case .noPhoneNumberAvailable:
        print("No phone number available to perform the SMS OTP flow.")
    case .noBiometricsAvailable(hardwareSupportsBiometrics: let hardwareSupportsBiometrics):
        print("No biometrics available. Hardware supports biometrics: \(hardwareSupportsBiometrics)")
    case .challengeFailed(cause: let cause):
        print("The challenge failed due to \(cause)")
    }
}

User roles​

Users within a corporate identity often interact with your service for a specific, everyday purpose - such as making purchases on an assigned card, or initiating payments. Beyond these end users, corporatesCorporates Business entities that can be onboarded as identities on Weavr. Corporate identities represent companies and require Know Your Business (KYB) verification. They can have multiple authorised users and issue cards to card assignees. also typically have users who perform support and administrative functions, such as overseeing financial instrumentsInstrument 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)., controlling fund flows across the organization, or managing users.

Weavr recommends following the principle of least privilege: each user should only be able to access and operate on the financial instrumentsInstrument 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). and data that are relevant to their specific function.

To support this, Weavr has introduced a set of pre-configured roles that can be assigned to users to achieve the appropriate access level for their function.

This optional feature can be adopted at your own choice. If not utilized, users will continue to enjoy all of the rights and permissions that they do today.

For more information, see the authorized user roles documentation and the Users endpoints.

Linked card users (breaking change)​

For embeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. operating a program where cards are issued to corporate identities, Weavr is introducing a mandatory process whereby managed cardsManaged Card A payment card (virtual or physical) that can be created and managed through the Weavr platform. Cards can operate in prepaid mode (with their own balance) or debit mode (linked to a managed account). All cards must be assigned to a card assignee who is an Authorised User. must be linked to users. This is to ensure:

• Every active card is linked to a valid card userCard User The person that a card is assigned to and who will use the card for purchases. Weavr does not support anonymous cards, and therefore all cards must be linked to a card user before a card can be used. For consumers, the card owner and the card user is typically the same person. For corporates, the card users are employees or individuals authorised to spend the corporate's funds. with complete mandatory data
• Card usersCard User The person that a card is assigned to and who will use the card for purchases. Weavr does not support anonymous cards, and therefore all cards must be linked to a card user before a card can be used. For consumers, the card owner and the card user is typically the same person. For corporates, the card users are employees or individuals authorised to spend the corporate's funds. have valid credentials and are enrolled for 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.
• Cards cannot be used until all mandatory data for the linked card userCard User The person that a card is assigned to and who will use the card for purchases. Weavr does not support anonymous cards, and therefore all cards must be linked to a card user before a card can be used. For consumers, the card owner and the card user is typically the same person. For corporates, the card users are employees or individuals authorised to spend the corporate's funds. is provided

The change supports compliance requirements for sanctions screening and channel enrollment, and establishes a consistent approach across all card schemes.

The linking of cards to users should be done via the existing userId field when creating or updating a card.

For more information, see the virtual cards documentation and the Managed Cards endpoints.

To enable this feature on your sandbox account please contact Weavr support.

Fixed​

• No longer clears all data in the keychain for the app when the user calls UXComponents.clearUXComponentsCache.

Added​

• Italian (it) locale support across all SDK screens.

Fixed​

• Fixed password fallback screen content not being vertically centered on the screen.