Biometrics for 3-D Secure card purchases in Android and iOS apps
Previously we’ve made biometrics in mobile apps available as a multifactor authentication option in Strong Customer Authentication (SCA) flows for account access and authorising financial transactions, excluding card payments. We are now extending biometrics support so that card payments can be confirmed by End Customers via face recognition or fingerprints in Embedder Android and iOS mobile apps, in line with 3-D Secure (3DS) standards.
Using biometrics for 3DS/SCA provides an excellent blend of security and convenience. Integration with biometrics is available for any Embedder with an Android or iOS app who has already implemented a baseline SCA solution (with SMS OTP or push authentication).
Our biometrics SDK is available for native iOS, native Android, React Native, and Flutter.
Find out more info on how to set up 3DS in our documentation.
Security notification email to End User on password change
As part of a wider series of changes to enhance security for End Customers, Weavr will now send an email directly to any End User who has changed their password. This ensures they are notified of a successful change in normal circumstances, and alerts them to unwanted changes in the event of a security breach.
End Users of Corporates and Consumer Identities can change their password via:
- the "reset password/forgot password" flow
- when logged in, in a "change password" flow
As with other transactional emails sent by Weavr directly to End Users, as the Embedder you have the option to apply your own brand design and potentially wording changes to this email template, subject to approval.
To create or change customised email templates, please open a support ticket.
Notification for rejected Incoming Wire Transfers
When an Incoming Wire Transfer (IWT) is received Weavr will send the Embedder a webhook to confirm its status. As all IWTs are screened in accordance with compliance and risk rules, some IWTs may be held in a suspended state pending a review, or immediately rejected back to the payer.
Previously, an “Account deposit” webhook was only sent for IWTs that reached the states PENDING and COMPLETED. This meant that there was a gap in communication for IWTs that ultimately reached the final state of REJECTED.
Weavr will now send an “Account deposit” notification via webhook with the state: REJECTED where applicable.
IWTs that have been rejected are also currently displayed in Data Insights in the Embedder Portal.
Webhook impacted:
Account deposit
FAQ - Why are IWTs rejected?
The most common situation in which an IWT would be rejected is if a compliance review is initiated, and subsequently finds the IWT cannot be accepted (for example if the End Customer failed to provide the requested Source of Funds declaration in time).
In addition to manual compliance reviews, IWTs can be rejected according to automated criteria only. This particularly applies to SEPA Instant IWTs, which are subject to compliance and risk screening but cannot be held for manual review.
In both instances of the IWT rejection, funds will be returned to sender.
Additional digitalWalletType in in card purchase webhooks
In a previous release we introduced a digitalWalletDetails object in the Card Authorisation and Card Settlement webhooks that notes the digitalWalletType (GOOGLE_PAY or APPLE_PAY).
We are now introducing a third enum to digitalWalletType - MERCHANT_TOKEN - which is used when the transaction was conducted via a merchant tokenised version of the card. This refers to a card on file and is typically used for recurring transactions such as subscriptions.
Extending idempotency support to additional endpoints in Weavr Multi API
To help improve the resiliency of integrations with the Weavr Multi API, we’re extending support for idempotency to the following endpoints:
POST/users- Create and Authorised UserPost/stepup/challenge/otp/channel- Issue a one-time passcode that can be used to Step Up a tokenPOST/stepup/challenge/otp/{channel}/verify- Verify a Step-Up token using a one-time passcodePOST/managed_cards/{id}/spend_rules- Create spend rules for a Managed Card
The updated documentation regarding idempotency in the Multi API can be found here. We strongly recommend you review this documentation if you are planning to make use of idempotency, or indeed even if you are already doing so.
Weavr plans to extend idempotency support to most endpoints in the Multi API over a number of upcoming releases
Additional information provided when a user is INACTIVE
Users with an INACTIVE state are already displayed in the portal. A common reason why a Root User may reach this state is because during onboarding, they did not verify their email address (via the email verification process described in our documentation) within the time limit.
We have added additional information to the portal when a user is INACTIVE because of this reason.
You now have the option to filter users ABANDONED.
If an ABANDONED user registers again with the same email address (and completes the verification), the user becomes ACTIVE and will no longer be considered ABANDONED.