56 posts tagged with "Multi-v3"

Streamlined API call for incrementing a card spend limit​

In embedded finance use cases delivering employee-spendable benefits / rewards / allowances, a common approach is for employers to set an allowance per employee (/card) on a periodic basis (e.g. monthly, weekly). In some cases, the employer may want to allow the employee to carry over any ‘unused’ budget from the previous period into a new period.

This can be achieved via the Weavr APIs by establishing an “ALWAYS interval” and a “limit”, and then setting a new, higher limit when reaching the end of the period. Until now this required two calls, GET all 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. (to determine the current limit), then after calculating the new limit, a second call to PATCH update the spend rules on that 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..

Weavr now offers a streamlined way of doing this, as follows:

We have introduced a new parameter in the spendLimit array - updateMethod with the following enums:

• OVERWRITE : (default option if left null). Overwrites the previous values for the spendLimit object i.e. sets new limits

• INCREMENT : This will increase the existing value of the spend limit by the amount input the value field.

If INCREMENT is used in conjunction with an ALWAYS interval (as in the example given), it can negate the need for the first GET (of the limit) and the calculation of the new limit. Simply call the PATCH with updateMethod set to INCREMENT, interval to ALWAYS and the value you want the limit to increase by.

INCREMENT can be used on all intervals, not just ALWAYS. You cannot decrease a limit using INCREMENT.

APIs affected:

PATCH /managed_cards/{id}/spend_rules

Data Insights - new 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). Events dashboard​

PSD2 defines that Strong Customer Authentication (SCA) via multifactor authentication needs to be used when End Customers access their sensitive payment account information and make payments.

To help EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. programme operations and support teams track and troubleshoot 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). actions of End Customers through their programme, we are introducing a new Data Insights dashboard 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.: 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). Events.

EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. staff can now gain an overview 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).-type auth events, including the ability to filter by country and authentication channel.

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). events covered include:

• Device enrolment

• Session Step-Up

• Transaction confirmation

• 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. initiation

• 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. management

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. users can deep-dive into each segment by using the drill-down functionality available across various charts.

Within this dashboard, you can also access a dedicated SMS Analysis tab which you can use to track the journey of SMSs and understand how long SMSs take in each state. This can be helpful for troubleshooting any SMS deliverability issues that are emerging in support cases for particular customers or regions, often due to local telecoms reasons.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of 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 which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following 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 endpoints can (optionally) be called idempotently:

• POST /managed_accounts to create a Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr.

• POST /managed_cards to create 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.

• PATCH /managed_cards/{id} to update 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.

• DELETE /managed_cards/{id}/spend_rules to delete all 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.

Further information on idempotency is provided in our API Docs here.

Email to End User for new device biometrics enrolment​

EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. have the option of enabling mobile device biometrics (facial recognition or fingerprints depending on hardware and Android vs iOS) as a multifactor authentication method, provided their application offers End Users a mobile app.

When an End User successfully enrols their first device or a new device for biometrics, 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 them. As well as confirming a successful enrolment, this is also a security feature to alert them in case the device enrolment was not done by them. (In addition to this email, Weavr continues to 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. a webhook to 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. on the status change of the biometrics enrolment flow.)

The following is the default template for this email, where the example text “PasscodeApp” would change to 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.’s application name:

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.

Additional endpoints now supporting idempotency​

As mentioned in previous Release Notes, we are extending the list of 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 which can be called idempotently. This can be achieved by including the idempotency-ref header in the requests.

In this release, the following 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 endpoints can (optionally) be called idempotently:

• PATCH /managed_accounts/{id} to update a Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. details

• POST /managed_cards/{id}/physical/activate to activate a physical cardPhysical 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.

• POST /managed_cards/{id}/physical/replace_damaged to replace a damaged physical cardPhysical 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.

• POST /managed_cards/{id}/physical/replace_lost_stolen to replace a lost or stolen physical cardPhysical 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.

• POST /managed_cards/{id}/physical/contactless_limit/reset to reset the contactless limit for a physical cardPhysical 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.

Further information on idempotency is provided in our API Docs here.

Card Settlement Reversal indicated in 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.​

We have made changes to the way a payment card Settlement Reversal is presented on 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. in the 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. transaction activity view. Previously, only the transaction type was shown, without a merchant name.

In order to help EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. support staff to reconcile a reversal with the relevant settlement, this view now displays the merchant name.

The changes made to 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. statement user interface will not affect the endpoints provided 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 or 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. Back-office API for the generation of 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. statements.

Enrolling new biometrics auth factor now has additional security requirement​

When enrolling a mobile device for the biometrics authentication factor, an additional step is now required to corroborate the link between the legitimate user and the device. The user will need to have a successfully registered mobile number to use for SMS OTP prior to starting the biometrics enrolment.

As part of the biometrics enrolment flow, the user will need to pass an SMS OTP challenge.

When the end user requests to enrol their device, we check if there is a mobile number associated to that user:

• If there is a verified number, 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. an OTP over SMS to the user’s registered mobile number, which they can input in the request screen (provided in our biometrics SDK). If this OTP is valid, enrolment is successful.

• if there is a number available, but not verified, 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. an OTP over SMS to the user’s registered mobile number, which they can input in the request screen (provided in our biometrics SDK). If this OTP is valid, enrolment is successful and mobile number is automatically verified.

• If the user does not have a mobile number or would like to change with another mobile number, 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. needs to call

PATCH/corporates PATCH/consumers

before triggering the SMS challenge for biometrics enrolment flow.

When a user tries to enrol his device for biometrics without having a mobile number, we are returning 409 - Mobile_Number_Not_Available

Other scenarios when PATCH should be called are:

• user has an invalid format of the mobile number - 409 Mobile_Number_Invalid
• user has a mobile number with a country code not supported - 409 Mobile_Country_Not_Supported

All these changes will be part of our future mobile SDKs releases.

Default complexity level for passwords is now set to 4​

As part of a wider series of changes to enhance security for End Customers, we are increasing the default complexity level of the passwords to level 4. This means, that the password must be:

• between 8 and 30 characters
• include a lowercase character
• include an uppercase character
• include a digit and a special character
• different from any of the 5 last such passwords used

If your users are having a Level 1 complexity password, they will be allowed to continue using Level 1 password until:

• password expires - Level 4 complexity will be required for the new password
• user triggers Forgot password flow - Level 4 complexity will be required for the new password
• user changes the current password - Level 4 complexity will be required for the new password

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.

SEPA 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. now require description text from end user​

In order to comply with European regulation, a payment reference must be provided by the payer when instructing a SEPA Outgoing 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). (OWTOWT 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.) regardless of the purpose of that OWTOWT 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.. As such, the description field will become mandatory for SEPA 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. (the field exists but before this change was not mandatory). This requirement applies to both single 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. and those created in bulk transactions.

(NB currently adding a description/reference is not mandatory on UK Faster Payments - i.e. for 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 GBP.)

The End Customer is required to provide the text during the UX flow of creating an OWTOWT 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.. Therefore, 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., if you have not previously made this field available in your application, you must now add it and make it mandatory to complete, in order to proceed with the OWTOWT 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. flow.

Here is example text for labelling the field in your application:

“Reference - Add text which to pass to the payee as the reason for payment or any payment reference”

End Customers may use this field as appropriate to the scenarios in which they are creating 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 your application, e.g. to add an invoice number or customer number on the payment to a business payee.

This text must be provided and confirmed by the End Customer. Therefore if your application suggests text for the End Customer to use, there must still be the option for them to edit it and accept the final text when proceeding with their OWTOWT 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..

The field currently accepts a maximum of 35 alphanumeric characters, observing the SEPA extended character set (SEPA Requirements for an Extended Character Set (UNICODE Subset) - Best Practices)

The endpoints impacted are:

POST /outgoing_wire_transfers

POST /outgoing_wire_transfers/bulk/create

If the field is left empty or invalid, and your application attempts to submit the OWTOWT 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. to the Weavr system, our API will return a 400 error noting the description field is “REQUIRED”.

For successfully completed 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., the description is currently returned in the GET Outgoing 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). Transaction APIs, and the GET Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. Statement API.

OTP retries are now limited​

We will limit the number of times an OTP can be submitted incorrectly, to reduce the risk of fraud or abuse. This applies to all scenarios where an OTP is submitted by any kind of user.

For the example below, the number of attempts is 5. However, EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. should handle the error appropriately rather than assume a fixed number of attempts.

Example:

After the 4th incorrect attempt a 409 Failed will be returned with error - "ONE_CHALLENGE_LIMIT_REMAINING"

After the 5th incorrect attempt a 409 Failed will be returned with error - "CHALLENGE_LIMIT_EXCEEDED"

If the challenge is being performed to verify a transaction (such as an OWTOWT 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. or a 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.), after the 5th incorrect attempt, the state of the corresponding transaction will be updated to "REJECTED" and no further challenges can be triggered against this transaction.

Submitting another verify call will return Failed 409 - "STATE_INVALID"

Endpoints affected: /multi/challenges/otp/{channel}

/multi/authentication_factors/otp/{channel}/verify

/multi/stepup/challenges/otp/{channel}/verify

/multi/outgoing_wire_transfers/{id}/challenges/otp/{channel}/verify

/multi/sends/{id}/challenges/otp/{channel}/verify

The time limits for submitting an OTP to complete an action remain the same regardless of the timings of one or more errors or retries.

Phone numbers must now have standard country code for SMS delivery​

In order to improve SMS deliverability we are making it mandatory to include the country code with the '+' symbol in the phone number.

Ensure your users are entering the mobile number in the following format: [+Country Code] [ Mobile Number]

For existing Identities, EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. do not need to amend data manually or ask End Customers to take any action, as Weavr will standardise existing data.

Creation of 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. now requires Step-Up​

Creation of an Authorised User linked to an Identity is a key moment in the integrity of the security for that Identity.

Therefore we are now requiring a session Step-Up when creating a new Authorised User. A new Authorised User can be created by the 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. or by another Authorised User. The active user can Step Up their token by completing a second authentication factor.

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. supports the following methods:

• One-time password via SMS
• Biometrics
• Twilio Authy Push Notification More details on how to step-up a token are available on our documentation.

KYCKYC Know Your Customer - the identity verification process for consumer identities. This process allows you to seamlessly and securely verify your user's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. and KYBKYB Know Your Business - the identity verification process for corporate identities. This process allows you to seamlessly and securely verify your business customer's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. now require email verification at start of process​

Previously it has been possible to start the KYCKYC Know Your Customer - the identity verification process for consumer identities. This process allows you to seamlessly and securely verify your user's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. and KYBKYB Know Your Business - the identity verification process for corporate identities. This process allows you to seamlessly and securely verify your business customer's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. processes with an unverified email address, and validate it later. Now we require the email address of the 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. in Consumer and Corporate scenarios to be verified by an end user action before the KYCKYC Know Your Customer - the identity verification process for consumer identities. This process allows you to seamlessly and securely verify your user's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. or KYBKYB Know Your Business - the identity verification process for corporate identities. This process allows you to seamlessly and securely verify your business customer's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. process can begin.

Email verification begins as described in our documentation for creating a Consumer or Corporate Identity.

• An email verification link is valid for 60 minutes - we recommend EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. provide clear instructions to end users to explain the time limit

• 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.’s application can offer UI to the end user to “resend email verification link”.

• Call the “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 verification code to the 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.” API endpoint again

• If 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.’s application requests to re-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 verification link, the new link will again be available for 60 minutes from the time it is created (and the previous link cannot be used)

• If the user does not verify the email address within the time limit, and the link expires, the user will not be able to login (Weavr returns “403 Forbidden”) and therefore 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.’s application will need to prompt the end user to start the onboarding process again

• If the user tries to start KYCKYC Know Your Customer - the identity verification process for consumer identities. This process allows you to seamlessly and securely verify your user's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers./KYBKYB Know Your Business - the identity verification process for corporate identities. This process allows you to seamlessly and securely verify your business customer's identity. Weavr will ask users to submit the necessary information and documentation so that they can get approved by financial providers. without having the email verified, we will respond with 409 - Email_Unverified

API handling Step-Ups now uses consistent error code​

In the situation when an API is called, and a Stepped-Up token is required but has not been provided, we currently respond with STEP_UP_REQUIRED, but sometimes as a message, and sometimes as an error. We have now aligned all our APIs to provide the response as an error code rather than a message. The endpoints impacted are:

GET /managed_cards

POST /managed_account

POST /managed_cards

GET /managed_accounts

GET /managed_accounts/{id}

GET /managed_cards

GET /managed_cards/{id}

PATCH /managed_accounts

PATCH /managed_cards

POST /managed_cards/assign

POST /managed_cards/{id}/physical

POST /managed_cards/{id}/physical

GET /managed_cards/{id}/physical/pin

POST /managed_cards/{id}/physical/replace_damaged

POST /managed_cards/{id}/physical/replace_lost_stolen

POST authentication_factors/push/{channel}

POST /users

In all cases if the session is not Stepped Up validly, we will respond with the error above.

New feature: payment card renewals​

Payment cards issued across Weavr embedded finance programmes carry expiry dates. Up till now, if a cardholder needed to replace an expiring card, and the embedded finance use case called for it, the new card issued would have a new card number. This can cause inconvenience for cardholders because a new card number begins a new transaction history in terms of statements, reporting, and (where applicable) balances.

We are now introducing payment card renewals which allow the cardholder to be issued a new card with the same card number as before, with a new expiry date and CVV.

Here are some key points:

• Renewal of a card, keeping the original card number, is an optional setting at the card level;

• Cards not set to renew will still, as before, expire and not be automatically replaced;

• When a card is set to renew, Weavr will automatically issue the new card;

• This is available for both virtual 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.;

• Automatic advance warning of upcoming card expiry is now available for all payment cards.

The option to enable automatic renewal of cards can be set at the point of creation for new cards, or can be updated at any point before the renewal date for existing cards.

EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. can choose to expose this choice to the End Customers. If 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. chooses to enable automatic renewal for a specific card or more generally, we advise seeking agreement from the End Customer, although technically no end user interaction or confirmation is required in the current setup.

In the case of 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., lead time is required to allow for delivery to the cardholder. Where renewal is enabled on a physical cardPhysical 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., the new card will be sent out with the process starting (currently by default) 30 days ahead of the expiry date, based on an internal “renewal date” for the card.

With this lead time in mind, EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. should take the opportunity to check with the End Customer, further in advance of this renewal process, that their address for delivery of the card(s) is still up-to-date.

By default cards that are currently issued, and new cards issued from now on, will not automatically be set to renew. Therefore 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. needs to take a decision in general on their programme, and specifically within subsets of cardholders, whether to take advantage of this feature.

Key points about a new card on a renewal basis:

• The long card number of the new card is the same as the original card

• The expiry date is updated

• The card has a new CVV

• The PIN on the card remains the same as set by the cardholder, and they can update the PIN any time

• The spend control rules applied to the original card are applied to the new card

• New 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. must be activated (via the API as per activating any new card), while new virtual cardsVirtual Card A payment card that is created instantly and can be used for e-commerce and online purchases. Virtual cards are issued through the Mastercard network and are automatically enrolled in the 3D Secure program for increased security and limited fraud risk. They can be created in prepaid or debit mode. are renewed with updated details immediately

• Cards provisioned in mobile wallets (Google and Apple) are expected to continue working without the cardholder having to update or replace the original card they added

• Soon-to-expire cards remain active and usable until the new card is activated

Note: renewal of expiring cards is a different scenario from replacement of a lost or stolen card. In those scenarios the original card would be blocked immediately and a new card would be issued with a different long card number, as a security measure.

Notifications are sent via webhook relating to upcoming card renewals and expiry events:

CARD_ABOUT_TO_EXPIRE (60 days, 30 days, and 1 day before expiry date)

CARD_RENEWED

CARD_EXPIRED

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.’s system will need to listen on a new webhook:

/managed_cards/expiries/watch

New simulator tools have been added Sandbox area of 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. to enable developers to test events related to card renewals and expiry.

Further developer documentation is available here.

Mobile wallet type (Google Pay / Apple Pay) included in card purchase webhooks​

Embedded finance programmes with cards can apply to enable mobile wallet provisioning, allowing cardholders to add their card(s) to Google Pay or Apple Pay. Thanks to the dual benefit to users of enhanced security and convenience, programmes taking advantage of mobile wallet provisioning typically see a strong uplift in product engagement, card spend frequency, average transaction values, and overall card spend volume.

In order to help EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. track these KPIs we are introducing a digitalWalletDetails object in the Card Authorisation and Card Settlement webhooks that notes the digitalWalletType (GOOGLE_PAY or APPLE_PAY). This makes it possible to tell, for any card purchase, if it was used through one of these mobile wallets.

EmbeddersEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. whose programmes already allow End Customers to provision cards to mobile wallets can immediately start using this information for business intelligence, as well as making the data available for End Customers e.g. for use in accounting and business spend monitoring.

Webhooks impacted:

• Card authorisations

• Card settlements

Linking multiple related authorisations and settlements, in card purchase webhooks​

In some business purchasing situations with commercial cards 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., a merchant may seek a single cardholder authorisation for a total amount for a purchase and then break down a purchase into individual items (such as travel tickets). These will then appear to the cardholder as multiple smaller settlements. Previously only the first relatedAuthorisationId or relatedSettlementId was returned by Weavr in the ‘Card authorisation’ or ‘Card settlement' webhooks. This meant that references for any additional related transactions were omitted.

We have now introduced new fields in that can accommodate an array of related transaction IDs, so that 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.’s system, and through this the End Customer can correctly view a group of settlement transactions which relate to an original authorisation.

The fields added are:

• Card authorisation webhook - relatedAuthorisationIds

• Card settlement webhook - relatedAuthorisationIds and relatedSettlementIds

Alphanumeric SMS Sender ID for Finland and UAE​

A few months ago, we implemented an enhancement to the Sender ID used in the SMS messages containing One Time Passwords (OTPs) and 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).) for users with UK phone numbers. This was aimed at telecoms rules and deliverability of SMS.

The enhancement involved transitioning from the alphanumeric Sender ID "AUTHMSG" to the default "WEAVR" - or a customised one, for some EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. programmes on request. This change only affected SMS messages sent to UK numbers, while other countries continued to receive messages with numeric Sender IDs.

We are now introducing a similar change for Finland and the United Arab Emirates (UAE). Regulators in these countries require that Sender IDs in SMS messages be alphanumeric to prevent blocking. As a result, users with phone numbers in these countries will now receive SMS messages with the default "WEAVR" Sender ID or the custom one specified by 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..

This enhancement is automated and users with the country codes +358 (Finland) and +971 (UAE) will automatically receive the new Sender ID when requesting an OTP or 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)..

Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. Root Email and Processor Token added to Data Insights​

As EmbedderEmbedder A company or developer that integrates Weavr's embedded finance services into their own application to provide financial services to their end customers. operations teams managing B2B programmes in production, you’ll often want to drill down into certain details for support cases for Corporate End Customers, or create reports to help with proactive customer success monitoring.

To help with this, we have added two new fields as columns in the details view of the Managed AccountsManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. dashboard 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.:

• Root Email, i.e. the email address of the 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. Identity owning each Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr.

• Processor Token, i.e. an identifier for a Managed AccountManaged Account An account held at a financial institution that can be created and managed through the Weavr platform. Each account has a balance where customers can hold funds. Optionally, an IBAN can be assigned to enable wire transfers to bank accounts outside of Weavr. in our underlying payment system that can be useful 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. and Weavr in support cases where we need to track a transaction state or exception