We have introduced two new API endpoints to allow users to cancel and update payment run lines when a payment run is created.
Effective:
06 December 2024 on Sandbox
10 December 2024 on Live
These endpoints enable users to cancel or update specific payments flagged by CoP (Confirmation of Payee) results, avoiding the need to cancel the entire payment run.
When a payment is in the PENDING_CONFIRMATION status, users with a Creator role can cancel or update a payment run line before the user with a Controller role confirms the payment run.
To enhance security during payment run authorization and to help end-users verify the correct payment run, we have introduced a unique Payment Run ID in the Payment Run Authorisation UI Component.
Effective:
06 December 2024 on Sandbox
10 December 2024 on Live
Details:
Each payment run will now be assigned a unique identifier to ensure accuracy during the authorization process.
The unique Payment Run ID will also be included in the SCA SMS OTP message sent to end-users, providing an additional layer of verification.
We've introduced a new authentication method that allows your users to log in via passcode. You can now embed this as a UI component, providing a secure and seamless login experience using a passcode.
Effective:
04 November 2024 on Sandbox
05 November 2024 on Live
To enable passcode authentication, configure your application by first activating it in your embedder portal. Navigate to Settings > Authentication Configs > Weavr Authentication and toggle on 'Weavr Passcode'.
Just like the password option, you first need to integrate the Weavr UI library into your application, followed by the Passcode UI Component. The Passcode UI component lets you collect your customer’s passcode securely and converts it into a token, which you can safely send to Weavr using the API.
note
The passcode is set to 4 digits by default.
More information on how to embedded the passcode UI component is available in our documentation.
As mentioned in our previous update, to mitigate against security risks, we are now requiring the user who is updating an authorised user to step-up their token.
Effective:
28 October 2024 on Sandbox
29 October 2024 on Live
Creating and updating user continues to be an operation that can be performed by a user that has either an Admin role or a User Manager role, or both. More about roles can be found in our documentation.
Review and update your application logic to accommodate the update a user endpoint that requires a stepped up token. If your user is trying to update a user and the token is not stepped up, you need to handle the new HTTP 403 STEP_UP_REQUIRED error code. This will help prevent any disruptions to your integration.
As mentioned in our previous update, whenever your customers creates a GBP payment run, all Payment Service Providers using the UK Faster Payment System will need to perform a check on the payee's name to ensure it matches the account details based on the sort code and account number. This requirement aims to help prevent payments from being accidentally sent to the wrong account or maliciously misdirected. This process is known as Confirmation of Payee (CoP).
CoP is only available for UK-domiciled accounts that use the UK domestic payment scheme of Faster Payments.
To support CoP, we made significant changes to the payment run API endpoints and the payment run lifecycle. Below is a summary of these changes:
When a user creates a payment run in Faster Payments, they must specify the type of beneficiary account, which can be either PERSONAL or BUSINESS. The state of the payment run will transition to an interim state of QUEUED instead of PENDING_CONFIRMATION.
In this state, a CoP check is performed on the payee details for each payment in the run. The HTTP 200 response response of this endpoint will return a new object called validationsOutcomes, containing the status of the matching performed (e.g. EXACT_MATCH, CLOSE_MATCH or NO_MATCH) and the reasonCode. A list of the reason codes can be found here.
To accommodate the changes for CoP, we have made updates to the states within the payment run process:
Removing theVERIFYING_REQUIREMENTS and CREATED states.
We are introducing the QUEUED state: This reflects the asynchronous nature of the payment run creation is an asynchronous process. This status indicates that the payment run is in the process of being validated. One of the validation steps being the CoP checks for every payment line within the payment run.
The get a payment run and get payment runs endpoints have been updated to reflect the removal of old states and the addition of new ones. We have also included CoP results in a the new object validationOutcomes
We have introduced a new API endpoint for updating a payment run, allowing users to modify the payee details of individual payments within the run. Based on the CoP results, this functionality enables users to edit specific payments without needing to cancel and re-create the entire payment run.
info
Updating a payment run can be done by a user with a Creator role and will help the user with a Controller role to approve the payment run.
The Payment Run Authorisation UI Component has been updated to display the CoP results next to each payment so that the user with a Controller role can further verify the payee details.
The payment run can be cancelled at any time if the CoP results do not meet the required criteria
If no action is taken, your application wouldn't be able to handle the updated responses when creating a payment run resulting to your users not being able confirm the run.
To minimize risk, at this stage we will be limiting access to the product to only Enterprise Businesses. To differentiate between Enterprise and Micro Enterprise businesses, we are adding two additional steps to the current onboarding process:
1. New Terms & Conditions agreement onboarding screen
Onboarding flows for Buyers will change to require an updated method of recording agreement to financial institution terms and conditions (FI T&Cs).
All Buyer Admin users will now be shown the following screen when onboarding:
This enables us to record the agreement of the End Customer to the FI T&Cs directly, as well as automatically update the version of T&Cs if they are revised in future. T&Cs updates will be communicated in advance in each case.
This FI T&Cs agreement screen will be added automatically to the KYB UI Component, prior to the Customer Due Diligence steps (e.g. identity verification and proof of address) in the rest of the process.
2. Updated/moved Micro-enterprise declaration in KYB onboarding
As well as the above new T&Cs step for all onboarding flows, we will now require a clearer Micro-enterprise declaration, which we are adding into the KYB onboarding:
As shown, the Buyer's Admin User needs to answer the two additional questions and then agree to the declaration about whether the Buyer is or is not considered a Micro-enterprise.
Error code micro-enterprise
If the business is a Micro-enterprise, the KYB UI Component will send you an error event with code MICRO_ENTERPRISE_NOT_SUPPORTED
We are strengthening the verification process for linking accounts by ensuring that the activation of a Linked Account requires the successful completion of two verification steps; a declaration of ownership via an SCA challenge and internal checks by Weavr:
When adding a Linked Account via the Account Information Service (AIS) UI Component it is critical to confirm that the registered linked account belongs to the Identity attempting to link it. As a result, the state of the linked account will initially transition to PENDING_CHALLENGE rather than LINKED, A user with the Controller role of the Identity must then complete an Strong Customer Authentication (SCA) challenge to confirm ownership of the Linked Account.
Linked Account declaration UI Component
More information about our Linked Account Declaration UI Component can be found here.
SCA challenge state
If the SCA challenge fails, the Linked Account will remain in the PENDING_CHALLENGE state until a successful SCA challenge is completed.
More information about linked an account can be found in our documentation.
A name verification check will be automatically triggered by the Weavr platform and, when necessary, flagged for review by the Weavr Compliance team. This ensures that the name of the Linked Account holder matches the Identity registered with Weavr. The internal checks are required as another layer in the verification process to verify that the Linked Account belongs to the same person of the Identity.
During this process, we have introduced a new state, PENDING_VERIFICATION, which will remain until the Compliance checks are completed. These checks will result in either a REJECTED or LINKED status.
Compliance Checks
The Compliance will reach out to the Identity before rejecting the Linked Account.
Updates to the Linked Account webhooks and Get endpoints
If no action is taken, your application will be unable to handle the updated responses when linking a new account, preventing your users from performing an SCA challenge. As a result, the linked account will remain in the PENDING_CHALLENGE state.
New Linked Account SCA Declaration Challenge UI Components
In the UK, APP (Authorized Push Payment) Fraud is a growing type of scam, where fraudsters trick individuals into authorizing payments to accounts controlled by criminals. Unlike traditional fraud, where unauthorized transactions are made without the victim’s consent, APP fraud involves convincing the victim to willingly transfer money under false pretenses.
Weavr is committed to mitigating this type of fraud. To that end, we have enhanced our security measures for when your users add a linked account and we have refined the onboarding process.
To minimize risk, at this stage we will be limiting access to the product to only Enterprise Businesses. To differentiate between Enterprise and Micro Enterprise businesses, we are adding two additional steps to the current onboarding process:
1. New Terms & Conditions agreement onboarding screen
Onboarding flows for Buyers will change to require an updated method of recording agreement to financial institution terms and conditions (FI T&Cs).
All Buyer Admin users will now be shown the following screen when onboarding:
This enables us to record the agreement of the End Customer to the FI T&Cs directly, as well as automatically update the version of T&Cs if they are revised in future. T&Cs updates will be communicated in advance in each case.
This FI T&Cs agreement screen will be added automatically to the KYB UI Component, prior to the Customer Due Diligence steps (e.g. identity verification and proof of address) in the rest of the process.
2. Updated/moved Micro-enterprise declaration in KYB onboarding
As well as the above new T&Cs step for all onboarding flows, we will now require a clearer Micro-enterprise declaration, which we are adding into the KYB onboarding:
As shown, the Buyer's Admin User needs to answer the two additional questions and then agree to the declaration about whether the Buyer is or is not considered a Micro-enterprise.
Error code micro-enterprise
If the business is a Micro-enterprise, the KYB UI Component will send you an error event with code MICRO_ENTERPRISE_NOT_SUPPORTED
We are strengthening the verification process for linking accounts by ensuring that the activation of a Linked Account requires the successful completion of two verification steps; a declaration of ownership via an SCA challenge and internal checks by Weavr:
When adding a Linked Account via the Account Information Service (AIS) UI Component it is critical to confirm that the registered linked account belongs to the Identity attempting to link it. As a result, the state of the linked account will initially transition to PENDING_CHALLENGE rather than LINKED, A user with the Controller role of the Identity must then complete an Strong Customer Authentication (SCA) challenge to confirm ownership of the Linked Account.
Linked Account declaration
The ownership declaration is facilitated through an SCA challenge via a UI Component, which will be provided by Weavr.
SCA challenge state
If the SCA challenge fails, the Linked Account will remain in the PENDING_CHALLENGE state until a successful SCA challenge is completed.
More information about linked an account can be found in our documentation.
A name verification check will be automatically triggered by the Weavr platform and, when necessary, flagged for review by the Weavr Compliance team. This ensures that the name of the Linked Account holder matches the Identity registered with Weavr. The internal checks are required as another layer in the verification process to verify that the Linked Account belongs to the same person of the Identity.
During this process, we have introduced a new state, PENDING_VERIFICATION, which will remain until the Compliance checks are completed. These checks will result in either a REJECTED or LINKED status.
Compliance Checks
The Compliance will reach out to the Identity before rejecting the Linked Account.
Updates to the Linked Account webhooks and Get endpoints
If no action is taken, your application will be unable to handle the updated responses when linking a new account, preventing your users from performing an SCA challenge. As a result, the linked account will remain in the PENDING_CHALLENGE state.
New Linked Account SCA Declaration Challenge UI Components
To mitigate against security risks, we are now requiring the user who is updating an authorised user to step-up their token.
Effective:
28 October 2024 on Sandbox
29 October 2024 on Live
Creating and updating user continues to be an operation that can be performed by a user that has either an Admin role or a User Manager role, or both. More about roles can be found in our documentation.
Review and update your application logic to accommodate the update a user endpoint that requires a stepped up token. If your user is trying to update a user and the token is not stepped up, you need to handle the new HTTP 403 STEP_UP_REQUIRED error code. This will help prevent any disruptions to your integration.
Starting this October, whenever your customers creates a GBP payment run, all Payment Service Providers using the UK Faster Payment System will need to perform a check on the payee's name to ensure it matches the account details based on the sort code and account number. This requirement aims to help prevent payments from being accidentally sent to the wrong account or maliciously misdirected. This process is known as Confirmation of Payee (CoP).
CoP is only available for UK-domiciled accounts that use the UK domestic payment scheme of Faster Payments.
To support CoP, we made significant changes to the payment run API endpoints and the payment run lifecycle. Below is a summary of these changes:
When a user creates a payment run in Faster Payments, they must specify the type of beneficiary account, which can be either PERSONAL or BUSINESS. The state of the payment run will transition to an interim state of QUEUED instead of PENDING_CONFIRMATION.
In this state, a CoP check is performed on the payee details for each payment in the run. The HTTP 200 response response of this endpoint will return a new object called validationsOutcomes, containing the status of the matching performed (e.g. EXACT_MATCH, CLOSE_MATCH or NO_MATCH) and the reasonCode. A list of the reason codes can be found here.
To accommodate the changes for CoP, we have made updates to the states within the payment run process:
Removing theVERIFYING_REQUIREMENTS and CREATED states.
We are introducing the QUEUED state: This reflects the asynchronous nature of the payment run creation is an asynchronous process. This status indicates that the payment run is in the process of being validated. One of the validation steps being the CoP checks for every payment line within the payment run.
The get a payment run and get payment runs endpoints have been updated to reflect the removal of old states and the addition of new ones. We have also included CoP results in a the new object validationOutcomes
We have introduced a new API endpoint for updating a payment run, allowing users to modify the payee details of individual payments within the run. Based on the CoP results, this functionality enables users to edit specific payments without needing to cancel and re-create the entire payment run.
info
Updating a payment run can be done by a user with a Creator role and will help the user with a Controller role to approve the payment run.
The Payment Run Authorisation Component has been updated to display the CoP results next to each payment so that the user with a Controller role can further verify the payee details.
The payment run can be cancelled at any time if the CoP results do not meet the required criteria
If no action is taken, your application wouldn't be able to handle the updated responses when creating a payment run resulting to your users not being able confirm the run.
We’ve introduced a new webhook that allows you to receive notifications when a linked account consent of a Buyer is set to expire within the next 10 days.
Effective:
01 October 2024 on Sandbox
01 October 2024 on Live
The webhook sends real-time notifications, helping you stay informed about upcoming buyer linked account consent expirations, this will reduce the risk of account disruptions due to expired consent.
We have updated the permissible company types in the Create a Buyer endpoint to match our current KYB restrictions.
Effective:
12 September 2024 on Sandbox
13 September 2024 on Live
The NON_PROFIT_ORGANISATION and SOLE_TRADER enums have been removed from the company type object in the Create a Buyer endpoint. As a result, when onboarding a new buyer, the available company types are now limited to: LLC, PUBLIC_LIMITED_COMPANY, and LIMITED_LIABILITY_PARTNERSHIP.
We have improved the functionality of the user manager role, allowing users with the admin role to assign the user manager role to users who already have a role assigned.
Effective:
03 September 2024 on Sandbox
24 September 2024 on Live
Previously, we restricted the User Manager role to be assigned to only one user. However, with this release, we're allowing the user with the Admin role to assign the user manager role to multiple users.
As previously communicated, we are introducing a breaking change to the Buyer endpoints to enhance your ability to track the status of currency creation. This breaking change will include modifications to the HTTP 200 response when creating and updating a buyer, as well as changes to the webhook events to support buyer updates.
In the HTTP 200 response of the create a buyer endpoint, the supportedCurrencies field has been restructured as an array of objects. We have added a status field to indicate the status of each supported currency created. The status field will include the following enums:
PENDING_KYB_APPROVAL: The buyer’s KYB process is pending approval.
STEPUP_LOGIN_REQUIRED: The buyer needs to perform a stepped-up login for higher authentication.
PENDING_CREATION: The system is awaiting the completion of the ZBA creation process.
ACTIVE: The ZBA has been successfully created and is ready for use.
UNAVAILABLE: The currency is unavailable and cannot be used.
note
The HTTP 200 response of the get buyer details have also been updated to support the supportedCurrencies field has been restructured as an array of objects and the addition of the status field to indicate the status of each supported currency created.
The update a buyer endpoint has been enhanced to allow updating the admin user's roles and the supportedCurrencies. The HTTP 201 response now includes supportedCurrencies as an array of objects, each with a status field indicating the status of each supported currency.
KYB information (company and adminUser information) has been removed from the update a buyer endpoint, and a new endpoint Update Buyer's KYB details has been created specifically for updating KYB.
note
We also removed the resetMobileCounter from the update a buyer endpoint which had redundant information.
To accommodate these changes, we have updated buyer activation webhook to a Buyer Update webhook. The new webhook now includes the status of a buyer's supportedCurrency updates in its payload.
Review and update your application logic to accommodate the changes in the supportedCurrencies field and begin capturing the associated status. This will help prevent any disruptions to your integration.
Primary administrators of Embedder product/operations teams can now add, temporarily deactivate and reactivate, and remove additional users for the Embedder Portal via a “Manage Users” screen.
Effective:
13 August 2024 on Sandbox
20 August 2024 on Live
Primary administrators of Embedder product/operations teams can now add, temporarily deactivate and reactivate, and remove additional users for the Embedder Portal via a “Manage Users” screen. Please login to the Portal to test. This feature is available via the Portal UI only, not via API.
Please note “delete” does not actually delete a user, it just permanently deactivates that user credential.
Data Insights is your go to Business Intelligence solution, providing you with near-real time dashboards that will help you in gathering insights, whilst empowering everyone in your company to explore data and make informed decisions. The dashboards are instantly available when setting your Embedded finance programme, on both your Sandbox and Production environments.
Effective:
12 August 2024 on Sandbox
14 January 2025 on Live
The purpose of these dashboards is to:
allow users to access retrospective management reports, such as activity KPIs
support the day-to-day management of programmes such as:
a. monitoring for patterns or issues in general
b. supporting individual end-customers proactively or reactively
c. having a shared view of specific customers or transactions when working with Weavr 2nd/3rd tier support
drill-down into segments to inspect more detail on individual items
Each dashboard provides focused views to help you in analysing your data, including:
Overview: high-level overview of your main KPIs, including daily trends for the last 30 days
Analysis: a set of charts that can be used to analyse better your consumers and their activity
Details: a detailed table, providing you with granular data at identity, instrument or transaction level
An informational tooltip is also available within each chart, providing definitions and granularity details pertaining to that chart. Additionally, drop-down filters can be used across all dashboards, making it easier to find what you are searching for.
To help you get started in understanding the main dashboards currently available on Data Insights, have a look at the table below:
Dashboard Name
Description
Buyer
Insights on creation and status of new buyers
KYB
Insights on the KYB process and beneficiaries
Payment Run
Insights on payment runs created by Buyers to settle their outstanding financial obligations with their suppliers
Linked Account
Insights on linked accounts, in order to fund payments within a payment run
SCA
Insights on SCA events, including details on when end-users are accessing their payment account information as well as initiating transactions
API Calls
Insights on API Requests
Detailed documentation around Data Insights is also available within the knowledge base section of the Weavr support portal. This is also linked via the Help button within the Embedder Portal.
We’d like to hear your feedback about Data Insights. Please speak with your Weavr contacts to share your ideas.
The original communication indicated that the deprecated delete a linked account endpoint would be removed by 3 July 2024. This removal has now been rescheduled to 20 August 2024 on the Live environment.
We are excited to introduce the ability to fund and pay suppliers in both EUR and GBP currencies. This optional new feature provides greater flexibility and convenience.
Effective:
12 August 2024 on Sandbox
20 August 2024 on Live
How to enable multi-currency payment runs:
Login to the Embedder Portal: access your account on the embedder portal.
Update the supported currency in Buyer Settings: by switching on the second currency.
Update the Buyer details: via the PATCH/buyers endpoint to add the new supportedCurrencies.
important
To activate the new supported currency, a buyer user with the Admin role must authenticate and step-up their token to confirm and complete the activation.
When creating a payment run with multiple currencies, the plugin will automatically split the payment run into separate groups based on each currency. Buyers will be able to fund EUR payment run groups using a EUR linked account and a GBP payment run group using a GBP linked account.
note
If you provide an unsupported currency when creating a payment run, you will receive an HTTP 409 error code UNSUPPORTED_MULTIPLE_CURRENCIES and if the currency is not active, you will receive an HTTP 409 error code ZERO_BALANCE_ACCOUNT_INVALID_STATE. You will need to handle these errors accordingly.
Additionally, the Payment Run Authorisation Component and the payment run screen on the embedder portal have been updated to support and display multi-currency payment runs effectively.
We are introducing idempotency to a list of endpoints in the plug-in API. This is can be achieved by including the idempotency-ref header in the requests.
Effective:
12 August 2024 on Sandbox
20 August 2024 on Live
Using Idempotency is optional. However, if you decide to use it, you need handle the new HTTP 409 error code IDEMPOTENT_REQUEST_IN_PROGRESS. Additionally, if an idempotent endpoint is called with an idempotency-ref header exceeding 8000 characters, an HTTP 413 Payload Too Large error should be returned. If an idempotent endpoint is called twice with the same idempotency-ref but with different payloads, an HTTP 422 Unprocessable Entity error should be returned.
On 3rd September 2024, we are introducing a breaking change to the Buyer endpoints to enhance your ability to track the status of currency creation. This breaking change will include modifications to the HTTP 200 response when creating and updating a buyer, as well as changes to the webhook events to support buyer updates.
In the HTTP 200 response of the create a buyer endpoint, the supportedCurrencies field has been restructured as an array of objects. We have added a status field to indicate the status of each supported currency created. The status field will include the following enums:
PENDING_KYB_APPROVAL: The buyer’s KYB process is pending approval.
STEPUP_LOGIN_REQUIRED: The buyer needs to perform a stepped-up login for higher authentication.
PENDING_CREATION: The system is awaiting the completion of the ZBA creation process.
ACTIVE: The ZBA has been successfully created and is ready for use.
UNAVAILABLE: The currency is unavailable and cannot be used.
note
The HTTP 200 response of the get buyer details have also been updated to support the supportedCurrencies field has been restructured as an array of objects and the addition of the status field to indicate the status of each supported currency created.
The update a buyer endpoint has been enhanced to allow updating the admin user's roles and the supportedCurrencies. The HTTP 201 response now includes supportedCurrencies as an array of objects, each with a status field indicating the status of each supported currency.
KYB information (company and adminUser information) has been removed from the update a buyer endpoint, and a new endpoint Update Buyer's KYB details has been created specifically for updating KYB.
note
We also removed the resetMobileCounter from the update a buyer endpoint which had redundant information.
To accommodate these changes, we have updated buyer activation webhook to a Buyer Update webhook. The new webhook now includes the status of a buyer's supportedCurrency updates in its payload.
Review and update your application logic to accommodate the changes in the supportedCurrencies field and begin capturing the associated status. This will help prevent any disruptions to your integration.
We are making a number of changes in this release to how we handle expiry of proof of ID (PoI) documents in KYC and KYB. Expiry refers to the “valid until” or “expires” date shown on the form of ID (such as a passport or national ID card).
Effective:
23 July 2024 on Sandbox
24 July 2024 on Live
The key points are as follows:
The Buyer's KYB good standing depends on the individual PoI documents being valid (not expired) for the Admin User (/appointee), plus ALL of Ultimate Beneficial Owners (UBOs). All of the Buyer's accounts will be restricted from transacting if any of the required IDs are deemed to be out of date after attempts to alert the stakeholders, until brought back into good standing.
In any actual restriction action Weavr will send a webhook and notification email as well as proactive support team engagement.
The Embedder has the primary responsibility to communicate with End Customers and their representatives/stakeholders in advance of PoI expiry and in the event of documents having expired. Embedders' systems should provide one or more advance warnings to the relevant end customer contacts.
Weavr will now send webhooks to the Embedder’s endpoint for every soon-to-expire PoI 30 days before expiry, 10 days before, and on the day of expiry. In addition a final warning is sent 10 days after the day of expiry. Embedders should use these webhooks to construct the relevant notifications for End Customer stakeholders.
In addition to the above webhooks, Weavr will send emails directly to the affected Admin User (or non-director Admin User plus director appointing them). The email content is as follows and can be customised by the Embedder for their programme, on request via support ticket:
The above email will be sent 30/10/0 days before as well as 10 days after the ID document expiry date.
The 30/10 days before and 10 days after expiry timeframes are configurable per Embedder programme: please contact Weavr if you wish to make changes in this regard.
Please note that any accounts currently affected by having one or more PoI documents already expired at the go-live date of this release, will already be subject to compliance case management with Embedder support teams. Any soon-to-expire cases after the go-live date will begin receiving reminders immediately.
We have introduced a new User Manager role. This role is designed to enable delegation of the user management tasks from users with the Admin role. The permissions associated with the role include authorised user creation, role assignments and user deactivation. This change aims to streamline administrative processes and improve system security by delegating specific responsibilities.
Effective:
10 July 2024 on Sandbox
11 July 2024 on Live
Users with the Admin role, now have the ability to create an authorized user with User Manager permissions. The User Manager will not have the ability to create, fund or confirm a payment run, nor will they be able to link or unlink a linked account.
important
The permissions of the admin role has not changed. This means that users with the Admin role will continue to have user management capabilities.
note
For system security purposes, the User Manager role cannot create or deactivate another Admin or User Manager. These changes are implemented to enhance system security by ensuring that critical operations and role management are restricted to Admin users only.
We have updated the linked accounts screen in the embedder portal to provide you with more information about your buyers linked accounts.
Effective:
01 July 2024 on Sandbox
09 July 2024 on Live
When logging in to you embedder portal, and you select a Buyer > Linked Bank Accounts you'll see two new columns displaying the 'Status' and the 'Consent expiries in'.
The 'Status' will display the status of the linked bank account, Linked or Unlinked.
The 'Consent expires in' will display the days left until the buyer is required to re-consent the linked account before it expires.
We are delighted to announce that Weavr is enabling EEA customers to make use of the Embedded Payment Run Solution. Apart from the UK, Embedded Payment Run is now available for end-customers in the European Economic Area. End-customers residing in the EEA can now onboard, fund and make domestic payments in Euros on the SEPA bank transfer rails.
To ensure that you can support your buyers to link an account and to fund a payment run we have created an endpoint that retrieves all the available institutions that use open banking.
We suggest that you enable your end-customers to verify that their current financial institutions are supported by Weavr before they onboard.
Account Information Service (AIS) Consent in the EEA
In the EEA, the Account Information Service (AIS) consents can be granted up to 180 days. This means that your users are required to extend their consent to continue using the associated Linked Account every 180 days.
Retrieve the linked account consent expiry and status
To extend the consent in EEA you need to provide the linkedAccountId parameter of the linked account in the AIS UI Component.
Extending an AIS consent before the 180 days pass
The consent can be initiated before 180 days elapse, this means that your user will be shown a consent renewal request screen for Weavr to continue accessing their bank account information. If the user clicks on 'I Consent' your user will be redirected to their Bank's portal to approve the consent request. In the Banking portal, the bank will ask them to authenticate and re-confirm the bank account to be shared.
Initiating the AIS consent after 180 days, can still be extended, however your user will be shown an expired consent screen. To renew the consent, your user will be redirected to their Bank's portal to approve the consent request. In the Banking portal, the bank will ask them to authenticate and re-confirm the bank account to be shared.
When you open a sandbox account, upon the registration form you are required to choose the jurisdiction you are residing in. If you select "EEA" (European Economic Area) then by default, the EUR currency will be selected.
We have made improvements to the get payment runs endpoint, enabling you to filter and sort the returned payment runs.
By default, the list of payment runs will be sorted in descending order based on their creation date, meaning the newest payment run will appear at the top of the list. This ensures that the most recent payment runs are immediately visible for easy access.
The following filters are now supported:
status - The status of the payment run.
reference - The unique paymentRunRef of the payment run.
min_amount - The minimum total amount of the payment run.
max_amount - The maximum total amount of the payment run.
We are making webhook event signatures more robust with the new method optional to adopt at present. For now, both the previous method and the new method are supported. The new method described below will become the only supported method on a timeline confirmed in a future breaking change release. In the meantime please update your integration so you are ready.
Webhook event signatures allow Embedder's applications to verify that a message received originates from Weavr. We require that all Embedders implement such security mechanisms. The previous (still live) method is described in the Webhooks event documentation here.
In the new method we are using HMACSHA256 to create a signature from a hash of the entire message (call-ref + payload + published-timestamp) instead of just the timestamp. This provides proof of integrity of the message (i.e. it has not been tampered with).
This new signature value is being passed as a new parameter in the header denoted by signature-v2; the signature parameter in the header will continue to be present for now, having a value based on the hashed published-timestamp..
We have added a validation to the start admin user email verification endpoint to ensure that the email address the admin users provided is not already registered with Weavr. The enum returned in such cases will be EMAIL_NOT_UNIQUE.
Please update your backend to handle this new validation.
We have made improvements to our error messages within the Account Information Service (AIS) flow to ensure that users can only link one account at a time.
With this update, a specific error message, CANNOT_LINK_MULTIPLE_ACCOUNTS, will be generated if users try to link more than one account. This error message will only be received during the AIS UI Component phase.
Users with the controller role must now ensure they link only one account during the AIS flow. Attempting to add multiple accounts will trigger the linked account update webhook with the new CANNOT_LINK_MULTIPLE_ACCOUNTS error. This change aims to streamline the account linking process and reduce errors.
We are improving the look and feel of the AIS UI Component by adding a new textHoverColor property which allows you to apply a colour to the text on pointer hover for your AIS UI Component - Bank Selection.
You can utilize the textHoverColor by changing the colour of the text upon moving the mouse pointer over the bank selection element to indicate that it is clickable.
More details on the AIS UI Component is available in our documentation.
We are improving the look and feel of the Payment Run Authorisation UI Component by adding a new rowColor property which allows you to change the background color of the consecutive row in the payments table.
The Payment Run Authorisation UI Component currently offers a alternatingRowColour background colour, with the addition of the rowColor property, you can also assign the colour of the row of the rows which are not alternating, giving you flexibility in your look and feel preference of the Payment Run Authorisation UI Component
More details on the AIS UI Component is available in our documentation.
The delete a linked account endpoint, currently deletes the linked account, and once a linked account is deleted it cannot be retrieved. This makes it difficult for your buyers to trace and reconcile which linked account was used to fund previous payment runs.
We have exposed two new simulator endpoints where the user can simulate an issue and verify an SCA challenge for a payment run. The simulator endpoints will help you trigger processes in Sandbox that in Production are triggered from an external action rather than from your application. This way you can test scenarios that otherwise you would only encounter in the Live environment.
We have created a new endpoint to enable users with controller role to unlink bank accounts. Bank accounts should be unlinked if the buyer does not want to use them to fund payment runs anymore, thus removing the risk of using the wrong bank account in the future.
Response: the updated linkedAccount object and the status will change from CONNECTED and DISCONNECTED to LINKED and UNLINKED.
If your buyers try to confirm and/or fund a payment run using an unlinked account, you will receive an HTTP 409 error code LINKED_ACCOUNT_INVALID_STATE.
When calling the GET linked accounts or GET linked account endpoints, you will receive the unlinked account information with the status as UNLINKED and the consent of the account as EXPIRED.
You will be notified when a buyer unlinks an account if you are subscribed to the linked account webhook event. The linked account webhook event will also be updated to receive the status as UNLINKED and the consent of the account as EXPIRED.
We are removing the baseCurrency field from the Buyer object.
After the change, you will not be required to send the baseCurrency field when creating or updating a buyer. When retrieving the buyer details, the baseCurrency field will not be returned anymore.
If no action is taken, your application may fail when retrieving the details of a buyer if it is expecting to receive the baseCurrency field as part of the response.
We are continuing to improve the payment run creation process by ensuring that a payment run cannot be created if the Zero Balance Account was not created.
A Zero Balance Account is automatically created for each supported currency as soon as your customers completed onboarding, therefore if your customer didn't complete onboard and tried to create a payment run the API endpoint will return an HTTP 409 error ZERO_BALANCE_ACCOUNT_INVALID_STATE.
We understand the importance of accessibility and efficiency when it comes to monitoring your webhook events and for this reason, we have introduced an Event Log page within the Embedder Portal to provide you with a better user experience.
We restructured the list of webhook events to be presented in descending order, with the latest created event displayed first.
To view the webhook logs, please login to your sandbox embedder portal and go to Webhook Logs.
More details on webhook logs is available in our documentation.
We have updated the Controller role permissions so that a user that is assigned this role can retrieve payment runs.
Previously, if the view all payment runs and/or view a payment run where called by a user that has the Controller role, the endpoints would have returned an HTTP 403 error.
Following this change, the two endpoints will start returning the corresponding payment runs.
More details about the controller's permission are available here.
The Account Information Service (AIS) consents are granted for up to 90 days, after which, your users are required to extend their consent to continue using the associated Linked Account therefore we have updated the AIS component to support the extension of the consent.
Retrieve the linked account consent expiry and status
The consent can be initiated before 90 days elapse, this means that your user will be shown a consent renewal request screen for Weavr to continue accessing their bank account information. If the user clicks on 'I Consent' then the AIS consent will extended for another 90 days.
Initiating the AIS consent after 90 days, can still be extended, however your user will be shown an expired consent screen. To renew the consent, your user will be redirected to their Bank's portal to approve the consent request. In the Banking portal, the bank will ask them to authenticate and re-confirm the bank account to be shared.
We have improved the security of payments in a payment run by validating and ensuring that the supplier bank account details provided by your buyers are not the linked account or the zero balance account bank account details.
A buyer can only perform supplier payments to third party bank accounts and cannot use the Payment Run to send payment betweens their accounts. A buyer can add a linked account in multiple stages of the payment run lifecycle, therefore we have added the validations in the below endpoints:
When a user confirms the payment run or when a PIS is initiated and the supplier bank details include:
Linked account the endpoint will fail with an HTTP 409 error BANK_ACCOUNT_CANNOT_BE_LINKED_ACCOUNT
The payment run together with all the payments within the payment run will transition to a CANCELLED status and you will receive a payment run update webhook and payment update webhook, informing you that the payment and payment run have transitioned to a CANCELLED status.
We have exposed simulator endpoints that will help you trigger processes in Sandbox that in Production are triggered from an external action rather than from your application. This way you can test scenarios that otherwise you would only encounter in the Live environment.
The Step up - Issue one time password endpoint now allows the end-user to re-send a new OTP up to one time, if the first issue a step-up challenge attempt resulted unsuccessful.
To be able to issue another step-up challenge, you need to wait 15 seconds (or more) from the first attempt.
Triggering the step-up challenge API after 15 seconds from the first attempt then the first attempt will be invalidated and the user will need to respond to the new challenge.
Triggering the step-up challenge API before 15 seconds will return an HTTP 409 RETRY_IN_15SEC.
The step-up challenge can be retried 2 times after which an HTTP 400 INVALID_REQUEST will be returned. The user will have to logout and login again to issue a new step-up challenge.
Note: 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.
The creation of an Authorised User for a Buyer is a key moment in the integrity of the security for that Buyer. To mitigate against security risks, we are now requiring the user who is creating a new authorised user to step-up their token. Creating Authorised Users continues to be an operation that can be performed by a user that has the Admin role.
When the user inputs a wrong OTP, they will be shown an error message and will be allowed to re-enter a new OTP. If they reach the last try, a message will be shown specifying that is the last try. Once a wrong OTP is inputted for the last try the Secure UI Component will return an error event with code CHALLENGE_LIMIT_EXCEEDED.
