Improvement in identifying Beneficiaries​

We have implemented a fresh approach to identifying beneficiaries. You now have the flexibility to allocate your custom reference to a beneficiary, which can be later used to access beneficiary details, including the identifier, beneficiaryId, necessary for initiating payment instructions.

You can now access your custom reference, externalRefs in the following methods:

• POST multi/beneficiaries
• GET multi/beneficiaries
• GET /multi/beneficiaries/\{{beneficiary_id\}\}

Improvement to email address validation during Corporate onboarding​

In the past, Corporate Root Users who attempted to sign up for an account but didn't complete the process because their email address wasn't validated, would encounter an error if they tried again later. This error indicated that the email address was already in use, leaving the user with the option to either use a different email or abandon the sign up process altogether.

To enhance ease of use, we are now enabling users to proceed with a new registration even if their email address was previously awaiting validation from a prior attempt.

Recall that the Weavr Multi API will return error number 409 with the message:

• ROOT_EMAIL_NOT_UNIQUE, if the email the corporate root user attempted has already been validated or is waiting to be validated within the last 60 minutes
• VERIFICATION_CODE_INVALID, if the corporate root user attempts to validate the email address more than 60 minutes after it was sent

Physical Cards Overview Dashboard Enhancement​

As mentioned in our latest communication, physical cards can now be delivered in bulk either for yourself or your customers.

We have enhanced the details panel within the Data Insights section of the Physical Cards Overview dashboard to facilitate the display of bulk-delivered cards. This enhancement is designed to provide you with a more comprehensive view of all physically delivered cards that were dispatched in bulk.

Accepting apostrophes/single quotes in Email Addresses​

You can now start using apostrophes (‘) and single quotes (‘) when registering new email addresses. This enhancement guarantees a more accurate representation of your customer's email addresses during registration.

The affected Multi Product APIs are:

• POST/users
• PATCH/users
• POST/passwords/lost_password
• POST/login_with_password

Improvements to the downloadable PDF Statement for Accounts and Card transactions​

We have updated the downloadable PDF Statements to show the filtered date range, along with the starting and closing balances corresponding to that specific period. This enhancement ensures that the PDF statements are comprehensive and suitable for internal reconciliation, audits, and various other purposes.

Beyond Account transactions, you can now also download PDF statements for your card transactions.

Delivery of Cards in Bulk​

We are now offering the convenience of bulk card delivery, allowing you to receive up to 200 cards in a single package, either for yourself or your customers.

To initiate a bulk delivery request, simply set the bulkDelivery parameter to True and include the contactNumber field in your call. The deliveryAddress parameter must be exactly the same for all the cards marked for bulk delivery.

The delivery methods that support bulk delivery are COURIER with a maximum of 200 cards delivered at once, and REGISTERED_MAIL with a maximum of 90 cards delivered at once.

Physical Cards are dispatched from our supplier twice weekly at 08:00 GMT on Monday and Thursday mornings. Requests received in between these cut-offs (and marked as bulkDelivery) will be packaged into a single bulk delivery.

The affected Multi Product APIs are:

• POST/managed_cards
• PATCH/managed_cards/\{id\}
• POST/managed_cards/\{id\}/physical
• GET/managed_cards
• GET/managed_cards/\{id\}
• POST/managed_cards/\{id\}/physical/replace_damaged
• POST/managed_cards/\{id\}/physical/replace_lost_stolen

Processing deposits improvements​

To avoid confusion, and misunderstandings regarding the availability of funds for a deposit that is being processed, or held for review, we are simplifying the way that we notify you.

Currently, in the case where a deposit is received but held for further checks, or action is required from the end-customer in the form of a Source of Funds (SOF) declaration, we add the amount to the actualBalance of the account and show the transaction as PENDING in the activity statement on the portal. These two events will no longer occur. We will however continue to reach out to you if a SOF declaration is required, via the existing channels. Once any review has been completed successfully, the funds will show in the availableBalance on the account and in the activity statement (as happens today).

Deposits that are being processed, but held for review, can be seen in the deposits dashboard of Data Insights, with state UNDER_REVIEW.

Consumer registration retry with previously unvalidated email address​

Previously, if a Consumer End User (Root User Identity on Consumer Programme) initiated an account sign up but didn't complete the process due to the email address validation not being done, if that person came back later to try again, they would meet an error that the email address is already in use. They would either have to use a different email address, or might give up.

Now, to improve conversion and usability in such a case, we allow the user to continue at the time of the new registration, ignoring if that email address was previously stuck in a validation pending state from a previous registration attempt. Provided the user then completes the email validation (within a standard 60 minute time window), they can proceed successfully.

If the email attempted by the consumer root user is already validated, or waiting to be validated (within the last 60 minutes), Weavr will return an error: 409 "ROOT_EMAIL_NOT_UNIQUE”

If the user is too late trying to validate the email address (after 60 minutes) Weavr returns: 409 "VERIFICATION_CODE_INVALID"

Save custom fields with cards​

We are introducing a new option to save custom fields linked to cards, enabling more advanced data analysis.

You have complete authority and oversight over these fields. The information stored within these fields remains untouched in processing, but it is presented in reports and utilised for filtering, enhancing data manipulation and analysis capabilities.

You can start populating the new externalData object when using the create (POST/multi/managed_cards) or update (PATCH/multi/managed_cards/\{id\}) card APIs with up to 10 Name/Value fields. The exact same fields are returned in the get APIs (GET/multi/managed_cards and GET/multi/managed_cards).

Scheduled Transactions for OWTs and Sends​

Weavr Outgoing Wire Transfers (OWTs), sent via UK Faster Payments or EU SEPA, are immediately executed at the time of authorisation by the account holder. However, for business users, particularly finance professionals in B2B accounts payable scenarios, there's demand for being able to approve an OWT to be executed at a defined future date and time.

Using the new Scheduled Transaction feature, OWTs and Sends authorised by account holders can have an optional forward-dated execution time set, and our system will attempt to execute the OWT only at that time (to within 5 minutes).

OWTs and Sends for immediate execution (i.e. how these payments have normally worked up to now) will continue to work as usual if no Scheduled Transaction date/time is set, i.e. this is not a breaking change and if not adopting the Scheduled Transactions features, Embedders do not need to take any action.

When enabling this feature for end users, care should be taken by Embedders to make the behaviour of an instant payment distinct from a future-dated payment. Where the choice is offered, we recommend showing users "Send money now", selected as default, which the user can un-select to reveal a date and time picker. The Scheduled Transaction date and time should then be clearly displayed in the authorisation and confirmation UI as well.

Inline explainers or tooltips should be displayed to the end user to clarify how a Scheduled Transaction works. For example, the Embedder should make it clear it is a single payment not a recurring payment. Furthermore, the end user can cancel scheduled OWTs or Sends any time up to the execution time: the Embedder must provide information about how to do this, and clear navigation to do so in new UI where end users can review pending OWTs.

An important difference between Scheduled Transactions and ordinary immediate OWTs and Sends is that in a Scheduled Transaction, the balance on the account does not need to be sufficient at the time of the authorisation. This allows the account holder to arrange to fund the required balance any time between the authorisation and the execution time. If the balance in the account is not sufficient at the time of execution, the payment will not execute and Weavr will send the appropriate error message via webhook. In this case, the Embedder should deliver this message to the end user e.g. via notifications and link the user back to view the transaction in question. An OWT that failed for this reason cannot be retried but the Embedder is encouraged to design UX that makes it easy to populate a new OWT instruction that copies the details of the original request.

SCA confirmation will be taken from the account holder at the time of authorisation (i.e. this authorisation remains valid until the future scheduled execution, with no separate SCA check before execution).

This feature will be generally available to all embedders and programmes at no additional charge, including both Corporate and Consumer payment contexts. We're adding documentation and portal reporting interfaces as this is rolled out. Please enquire if this is a priority feature for you to integrate into your Embedded Finance Programme.

Webhook Logs in Embedder Portal​

The Weavr system provides Embedders with a range of webhooks that were sent through your application. Until now, any queries about the historical data of webhooks, including troubleshooting, were only available to Platform Operators, meaning that Embedders had to enquire via Weavr Support.

To accommodate this new developer tool, we are reorganising the main menu to easily locate the Webhook Logs:

Webhook Logs menu item added to the Embedder Portal

Embedders can now access and review a log of webhooks in the Embedder Portal. The webooks are available through a new menu “Webhook Logs” in the main administration portal. Through this new screen, developers can:

• Observe a detailed log of sent webhooks;

• Employ filtering to easily locate webhooks; and

• Manually replay selected webhooks

Portal users can browse a list of webhooks and manually resend webhooks

The Webhook Logs interface will be available to all Embedder programmes at no extra charge, including the Webhook Resend feature. This new feature will be made available automatically to all Embedders upon release to Sandbox. This is one of the first initiatives to help you work better with webhooks, as we continue to further enhance this feature.

Request and use new SMS OTP in session if first SMS was not delivered​

In a current end user login flow with multifactor authentication using SMS OTP, if the user has not received the SMS for any reason, to retry they would have to exit the login flow and start again.

We are updating this flow so that the user can now request one retry, where we send a new SMS OTP (15 seconds or more after the first request), and the user can submit this in the same session - without having to logout and restart the flow.

If the end user receives both the first SMS and the second one at the same time (e.g. a delay in telecom delivering the messages), only the more recent OTP will work.

We recommend adding wording to end user UI to wait at least one minute for delivery of a first SMS OTP before offering a “retry”.

Additional KYB questions when Onboarding a Corporate​

The onboarding process for a Corporate identity (i.e. a company or similar organisation) includes a number of questions related to business details, operations, as well as projected usage.

We are adding two new questions to this questionnaire.

The first asks the respondent whether their business is considered to be a “micro-enterprise”

The second (separate) question asks for their business Taxpayer Identification Number (TIN).

The TIN is the primary reference provided to the business by the taxation authority in the Corporate’s main country of business, so for example for UK businesses this is the HMRC unique taxpayer reference (UTR).

These questions are mandatory for all Corporates in all countries.

Both of these pieces of information help improve the accuracy of risk assessment and other Customer Due Diligence checks such as anti-money-laundering.

Stepped-up token obtained when end user enrols device for biometrics​

We have streamlined the process for end users enrolling for biometrics and logging into the financial zone of the embedder's app for the first time. Instead of treating enrolment and login as separate actions, we have combined them to reduce user effort.

Previously, when a user (including any Consumer or Corporate User) enrolled using biometrics and wanted to perform actions that required a stepped-up token, they had to log in again. This meant an additional step for users who had just completed the enrolment process.

To address this, we have made improvements. Now, when a user completes the enrolment process, which includes a two-factor authentication, we automatically step up the token. This means that the token can be used for accessing the specified endpoints without requiring a separate login.

Additional information provided when user fulfilled Multifactor Authentication challenge​

We are implementing a new status feature for our Access Token functionality to provide clarity on whether the user has already completed the Multifactor Authentication challenge.

When making a POST request to /access_token with a non-Stepped up token, the response will include the "status" field set to "STANDARD". On the other hand, if the token has already been Stepped-Up, the response will indicate the "status" as "STEPPED_UP".

A stepped-up token can be used to access the following endpoints.