Multi API v3.48.2

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 (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).) 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 EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. Android and iOS mobile apps, in line with 3-D Secure (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.) standards.

Using biometrics 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./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). provides an excellent blend of security and convenience. Integration with biometrics is available for any EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. with an Android or iOS app who has already implemented a baseline 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). 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 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. 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 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. 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 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. 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 EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. 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, open a support ticket.

Notification for rejected Incoming 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).

When an Incoming 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). (IWTIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds.) is received Weavr will 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. the EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. a webhook to confirm its status. As all IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. are screened in accordance with compliance and risk rules, some IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. 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 IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. that reached the states PENDING and COMPLETED. This meant that there was a gap in communication for IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. that ultimately reached the final state of REJECTED.

Weavr will now 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. an “Account deposit” notification via webhook with the state: REJECTED where applicable.

IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. that have been rejected are also currently displayed in Data Insights in the Embedder PortalEmbedder Portal A web-based portal where embedders can access their Weavr account, manage API credentials, configure settings, view dashboards, and access documentation. The portal provides access to both sandbox and production environments, with separate credentials for each..

Webhook impacted: Account deposit

FAQ - Why are IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. rejected?

The most common situation in which an IWTIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. would be rejected is if a compliance review is initiated, and subsequently finds the IWTIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. 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, IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. can be rejected according to automated criteria only. This particularly applies to SEPA Instant IWTsIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds., which are subject to compliance and risk screening but cannot be held for manual review.

In both instances of the IWTIWT Incoming Wire Transfer - a transaction that occurs when funds from a bank account held at a third-party financial institution are moved to a Weavr managed account. IWTs are initiated externally by the owner of the source bank account, and the managed account must have an assigned IBAN to receive funds. 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 MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API

To help improve the resiliency of integrations with the Weavr MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. API, we’re extending support for idempotency to the following endpoints:

• POST/users- Create and Authorised User
• Post/stepup/challenge/otp/channel- Issue a one-time passcode that can be used to Step Up a token
• POST/stepup/challenge/otp/{channel}/verify- Verify a Step-Up token using a one-time passcode
• POST/managed_cards/{id}/spend_rules - Create spend rules for a 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.

The updated documentation regarding idempotency in the MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. 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 MultiMulti Weavr Multi is an embedded finance solution that allows you to integrate financial services into your own application, providing a seamless experience for your customers. It enables you to offer managed accounts, managed cards, and transactions without requiring financial expertise. 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 UserRoot user The individual who creates the identity. For corporate identities, the root user needs to be a legal representative of the corporate such as a director or a representative who has the power of attorney over the company. For consumer identities, the root user is the owner of the identity. Every identity must always have one 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.