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.

Block mobile number change for 24 hours after account password change or email address change​

As a measure to improve the security of information belonging to end-customers, we are introducing a new rule that will help securing user’s account.

If a user changes their password (via the reset password flow)

/passwords/lost_password/start /passwords/lost_password/resume

they will not be able to change the mobile number in the next 24 hours.

This guards against account-hijack risks by keeping the mobile number unchanged to receive security notifications, and preventing takeover of second-factor authentication.

Longer Requires_SCA validity for wire transfers and Sends​

Until now, SCA authorisation for OWT and Send payments has allowed a pending/pending_challenge status for up to 30 minutes.

As more businesses use embedded payments within multi-party approval workflows, this may not be enough time for an approving person to complete the SCA step on a pending payment, especially where users are dealing with forward-dated or bulk payments (both features we are releasing soon). Accordingly we have increased the timeout to 7 days to accommodate these use cases.

Block list of commonly encountered spam or throwaway email domains​

Working with accurate data and verifiable user-identities is essential to a well run embedded finance programme.

One problem that can face embedders, is end-users registering accounts with throwaway email domains. This could mean those users lose access to the email address, and is a common sign of invalid users, including potentially malicious sign ups.

Therefore we have implemented throughout our systems, a block list of commonly encountered temporary or spam email domains. We will validate all sign ups against this list and block any attempt to register with an email addresses from these domains.

Error 409 - "Email_Domain_Not_Allowed" - will be returned if an email domain on the list is used.

We review and maintain this block list regularly. However, please contact us if you feel sign ups are being blocked incorrectly.

Bulk Transactions​

There are often times that end customers want to work through a list or batch of payments, and doing this one by one can be rather slow and inefficient.We’re introducing a new Bulk Transactions feature which enables Embedders to present a new workflow to end customers where they can execute multiple payments under a single SCA approval. The individual payments will be automated and status of each, plus the overall Bulk Transaction, communicated via webhooks.Both OWTs and Sends can be used as the payment method in Bulk Transactions.

Bulk Transactions can also handle mixtures of GBP and EUR in the Payables, provided a Corporate has funding accounts in the right currencies.If all Payables in a Bulk Transaction list are to Payees previously registered in a Corporate Trusted Payees list then an SCA exemption can be applied, further reducing friction in business payments use cases.

Sender ID of SMS OTPs to Singaporean phone numbers (+65)​

We have updated the Sender ID of the SMS OTP for card transactions of cardholders with a Singapore mobile number (+65). This will now show as being originated by “Thredd”, and will ensure the SMS message is not blocked due to an unregistered Sender ID. This is as a result of a regulatory change in Singapore coming into effect on 31st July that requires all SMS Sender IDs to be registered.