Consumer registration retry with previously unvalidated email address​

Previously, if a Consumer End User (Root User Identity on Consumer Programme) initiated an account signup 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 custome 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 enrolls 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 enrollment 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 enrollment process.

To address this, we have made improvements. Now, when a user completes the enrollment 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 signups.

Therefore we have implemented throughout our systems, a block list of commonly encountered temporary or spam email domains. We will validate all signups 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 signups 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.

SMS OTP expiry time​

In order to provide a consistent experience and level of security for end-customers using SMS OTPs, the validity of all SMS OTPs are now aligned to 5 minutes, whereas some actions previously had a longer validity. This applies to mobile verification and all step-up actions.

Please find here more details about our Step-up Documentation.

New step-up required after successful password change​

As a measure to improve the security of information belonging to end-customers, we are introducing a new rule regarding token validity after a user changes their password.

When a user changes their password (reset password flow) /passwords/lost_password/start /passwords/lost_password/resume, they will now have to perform a step-up to view information that may have been previously covered by a step-up in the last 180 days. This is because the validity of the tokens will have been reset and requires a fresh step-up.

Please find here more details about our Step-up Documentation.

New dashboard field for end-customer “Fee Group”​

The Consumers Overview and Corporates Overview dashboards can be used to monitor any new identities that are created, and their relevant details.

We have now introduced a “Fee Group” column within the Details tables; this can help you monitor which identities are linked to the plans that you support.

Reject duplicate identities for consumers programmes​

We are launching a new feature that will block same user creating multiple identities on your programme. This is going to help you:

1. Prevent fraud
2. Increase security
3. Improve customer support
4. Enhance compliance
5. Reduce costs

When detecting a duplicate identity, we will communicate via webhook the following:

• identity_id

• reason of rejection

• state of the account

• timestamp

Here’s an example of a response for a Duplicate identity:

Reversal of returned Outgoing Wire Transfers​

We are improving the processing of transactions if an Outgoing Wire Transfer is returned by the beneficiary bank or other payment service provider, and making the status of the original Outgoing Wire Transfer clearer.

If an Outgoing Wire Transfer was sent successfully, but ultimately refused and returned by the beneficiary bank, the funds will be credited back to the managed account, as well as any fees (this option can be selected via a new portal option). The original Outgoing Wire Transfer will also be updated with a new state RETURNED (currently the Outgoing Wire Transfers remain in the state COMPLETED). When calling a statement there will be a new transactionState entry with a RETURNED state, indicating the OWTs that were returned.

A new state RETURNED will be added to the “Outgoing Wire Transfer transaction” webhook, and will be sent if an Outgoing Wire Transfer is updated to this state.

The Outgoing Wire Transfers will also have the state RETURNED in the following APIs

GET: outgoing_wire_transfers

GET: outgoing_wire_transfers/{id}

GET: managed_accounts/{id}/statement

In the portal, in the Managed Account activity statement, the original Outgoing Wire Transfer will have a tag displayed “RETURNED”.

Previously, an OWT would never transition beyond a COMPLETED state. However, it will now be possible for an OWT to transition from COMPLETED to RETURNED.

Restrictions on onboarding Non Profit Organisations​

This change will impact you if you plan to onboard charities or non-profit organisations, because financial services for these types of organisation are no longer supported.

The full list of supported company types is listed in the API documentation, and the restriction of non-profit organisations will be enforced when creating a corporate using POST multi/corporates.

Corporates of type NON_PROFIT_ORGANISATION will not be accepted and if you attempt to onboard a company having company.type = NON_PROFIT_ORGANISATION, a 409 COMPANY_TYPE_UNSUPPORTED conflict response will be returned.

Country of residence required upon consumer identity creation​

The end consumer’s country of residence is key information that is required at the very first step of onboarding (consumer creation) so that the consumer can be directed to the correct onboarding flow depending on the jurisdiction in which they reside.

Currently, when creating a consumer identity using POST /multi/consumers, the country of residence of the consumer (rootUser.address.country) is optional. In such cases, the country would be provided later, during the due diligence process.

We are now making the country of residence mandatory immediately upon creation, in POST /multi/consumers. This will be used to help determine the appropriate due diligence process that the user needs to go through.

If a country is not provided in the call, the API will respond with 400 Bad Request Error.

Removing “Set spend rules for a managed card” deprecated API​

The deprecated “Set spend rules” PUT API will be removed in favour of the 3 existing API endpoints:

Create spend rules config API endpoint: This new POST API endpoint should be used when setting up the spend rules for the first time on a card.

Update spend rules config API endpoint: This new PATCH API endpoint should be used when spend rules have already been set on a card and these need amending to add or alter the rules that are currently configured.

Delete spend rules config API endpoint: This new DELETE API endpoint should be used when spend rules need to be removed that are currently configured on a card.

Unlike the PUT spend rules API endpoint, when using the create, update and delete spend rules API endpoints, only the rules that you want to configure need to provided. The rules that do not apply can be left out.

Affected APIs:

PUT /managed_cards/{id}/spend_rules

POST /managed_cards/{id}/spend_rules

PATCH /managed_cards/{id}/spend_rules

DELETE /managed_cards/{id}/spend_rules

Retrieving Spend Rules

The current spend rules response combines all rules that apply. This response object will be deprecated and the Get Spend Rules API endpoint enhanced to contain three response objects (groupings):

Card level spend rules: These are spend rules that are associated with the specific card itself

Identity level spend rules: These are spend rules that are associated with the cardholder (owner of the card).

Profile level spend rules: These are the spend rules that are configured in the Multi portal > Settings > Managed Cards screen

Please note that the response objects will only contain rules that have been configured within its group, thereby omitting all un-configured rules.

Affected APIs:

GET /managed_cards/{id}/spend_rules

Additional SCA methods for 3DS transaction verifications​

Following up on our alternative multifactor authentication methods release we have done recently where we introduced biometrics and third party auth app push confirmations (via Twilio Authy), we are now making biometrics and push authentication available for confirmation of card purchases, in addition to the existing default solution using SMS one-time passcodes (OTPs). These alternative multifactor authentication methods are designed to be 3-D Secure (3DS) and SCA-compliant out of the box.

Embedders with native mobile apps are invited to beta test biometric 3DS/SCA for card payments while we recommend all other (web application) setups test out push confirmations via Twilio Authy. Both of these new multifactor authentication methods add convenience and security benefits compared to SMS OTPs, as well as enhancing brand recognition and app engagement in the UX around card payment confirmations.

If you choose to use Twilio Authy or Biometrics, one-time-passwords via SMS will be automatically configured as a fallback option to ensure that your customers always have a way to verify their purchases.

SMS is a mandatory selection as a fallback authentication method when configuring Twilio Authy or Biometrics for Primary authentication methods for 3DS.

Please contact Weavr Support to learn more on how you can benefit from this new feature.

Data Insights - Terminology Alignments and Enhancements​

We are continuously working on improving the functionality within Data Insights to allow you to analyse and understand your data better. As part of this release, we have worked on various alignments across our dashboards to ensure further consistency and uniformity including:

1. Renaming of ‘Deposits’ within the Managed Accounts Incoming Transfers dashboard. Going forward, we are referring to this transaction type as ‘Incoming Wire Transfer’. Note that this will be a consistent terminology used throughout all Data Insights dashboards when referring to this transaction type.

2. Currently, Details tables within dashboards show:

• Transaction Base Amount: amount in your billing currency
• Transaction Amount: amount in the original transaction currency

Going forward, the Transaction Amount column will be showing the instrument amount (i.e. the amount in the currency of the instrument). The reason for this enhancement is that the Instrument Amount portrays a more correct value of the transaction since this is the amount that is used to adjust balances. Please note that there will be minimal to no changes to the previously reported numbers. This change applies to the following dashboards:

• Card Authorisations
• Card Settlements
• Managed Accounts Overview
• Managed Accounts Incoming Transfers
• Sends Overview

SMS Sender ID set to "AUTHMSG" for OTP and SCA SMSes sent to UK​

We have made improvements to the Sender ID of the SMS that is sent during 3DS verification to OTP and SCA SMSes sent to the UK. The SMSes will be sent with “AUTHMSG” as SenderID

Simplified company ownership (UBO) questionnaire for KYB onboarding​

Part of our ambition to improve the corporate onboarding journey, we are releasing a simplified UBO form, that will allow Root users completing KYB on behalf of their Corporate to better understand the details needed when declaring a Ultimate Beneficial Owner (natural person owning at least 25% of the shares or voting rights).

SMS notification to old SCA-enrolled mobile number when replaced by new mobile number​

Enhancement for security around SCA: if an end user changes his mobile number enrolled for receiving SMS OTPs, we will send an SMS notification to their previously enrolled mobile number provided, that old mobile number was previously validated. This message by default states: "Your account’s mobile number ending in {last 4 digits of the previous mobile number} has been updated with {last 4 digits on the new mobile number}. If you haven’t requested this change, please contact support".

Change email via PATCH - one request per minute​

If an end user requests to change their email address, we send a validation email for them to confirm. We have now added a 1 minute delay between any re-sends of this validation email to prevent spamming or accidental repeat messages.

Do not display deactivated Corporate identities​

Part of the Single Login Accessing Multiple Corporates feature, we have implemented a new functionality that will allow users to be displayed only the Active identities they are linked to. When calling Get/Identities the response will only contain the Active Identities that the user is linked to.

Trusted payees list for Outgoing Wire Transfers and Sends​

Allow end customers to save payees for Outgoing Wire Transfers and Sends into a "trusted payees" list. Aside from convenience and a reduced chance of making errors when making payments, this allows for the introduction an SCA exemption, where the account holder can request that payments to saved beneficiaries are exempted from the requirement to pass an SCA challenge every time.

Please contact Weavr Support to learn more on how you can benefit from this new feature.

Ability to increase the maximum allowable characters on bespoke plastic cards​

If you provide physical cards for your customers and opt for our bespoke plastic cards; depending on your bespoke design and configuration, it will be possible to increase the maximum allowable characters of the nameOnCard and nameOnCardLine2 fields printed on the cards, to a maximum of 27 characters per field.

For on-demand designs, the maximum allowable characters for both fields will remain at 20 characters.

If you already use a bespoke card design, or would like to upgrade your cards and design, please contact Weavr Support to determine the maximum allowable characters for your bespoke plastic card programmes.

Authorisation Forwarding​

We will be introducing the ability for card purchase authorisation details to be forwarded to you via a webhook. This enables you to play a part in whether a card purchase is accepted or declined.

Authorisation Forwarding is an optional feature that can assist you to decide whether to accept or decline Authorisation on a card purchase in real time and it enables you to run your own checks on top of any spend controls you may have configured in the card profiles or on the card itself when your customers perform purchases.

Please contact Weavr Support to learn more about this feature.

Beneficiary names for OWTs now support special characters​

When creating an Outgoing Wire Transfer (OWT), it will be possible to include special characters as part of the destinationBeneficiary.name field.

The supported characters are inline with the accepted SEPA or FPS payment schemes. If an unsupported characters is used this will be automatically converted to “.”, avoiding any interruption to the OWT submission.

For SEPA we follow the EPC guidelines of the Extended Character Set.

For FPS, the special characters are:

• "/" (forward slash)
• "-" (hyphen)
• "?" (question mark)
• ":" (colon)
• "(" (left paranthesis))
• ")" (right parenthesis)
• "." (full stop)
• "," (comma)
• "’" (right single quote)
• "+"(plus sign)
• (blank space)
• "#" (hash)
• "=" (equals)
• "!" (exclamation mark)
• ” (right double quote)
• "%" (percentage)
• "&" (ampersand)
• "*" (asterisk)
• "<" (less than)
• ">" (greater than)
• ";" (semicolon)
• "{" (left curly bracket)
• "@" (commercial at)
• CrLf (carriage return line feed)

Ability to increase the maximum allowable characters on bespoke plastic cards​

If you provide physical cards for your customers and opt for our bespoke plastic cards; depending on your bespoke design and configuration, it will be possible to increase the maximum allowable characters of the nameOnCard and nameOnCardLine2 fields printed on the cards, to a maximum of 27 characters per field.

For on-demand designs, the maximum allowable characters for both fields will remain at 20 characters.

If you already use a bespoke card design, or would like to upgrade your cards and design, please contact Weavr Support to determine the maximum allowable characters for your bespoke plastic card programmes.