11 posts tagged with "buyers"

As mentioned in our previous update, we are implementing measures to combat Authorized Push Payment (APP) Fraud.

Effective:

• 28 October 2024 on Sandbox
• 29 October 2024 on Live

Changes in Buyer Onboarding​

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.

Documentation links:

• KYB Onboarding
• Buyer Due Dilligence

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.

Changes to the Linked Account Process​

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:

1. Declaration of Ownership via SCA Challenge​

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.

More information about linked an account can be found in our documentation.

2. Internal Checks by Weavr​

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.

Updates to the Linked Account webhooks and Get endpoints​

We have updated the Linked Account update webhook event and both the Get linked accounts and a linked account with the new states: PENDING_CHALLENGE, PENDING_VERIFICATION and REJECTED.

Updates to the Linked Account states on the Embedder Portal​

The linked accounts in the embedder portal have been updated to display the new states: PENDING_CHALLENGE, PENDING_VERIFICATION and REJECTED.

Action required​

Migrate your application to start handling the new updated states related to the Linked Account verification process:

• PENDING_CHALLENGE: The Linked Account is pending challenge.
• PENDING_VERIFICATION: The Linked Account is pending the completion of the required verification steps.
• REJECTED: The Linked Account did not pass one or more verification steps and is not eligible for use.

If no action is taken​

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

• Linked Account SCA Declaration Challenge.

Affected Webhook Events

• Linked Account Update

Affected API endpoints:

• GET/linked_accounts
• GET/linked_accounts/{linked_account_id}

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.

Effective:

• 28 October 2024 on Sandbox
• 29 October 2024 on Live

Changes in Buyer Onboarding​

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.

Documentation links:

• KYB Onboarding
• Buyer Due Dilligence

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.

Changes to the Linked Account Process​

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:

1. Declaration of Ownership via SCA Challenge​

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.

More information about linked an account can be found in our documentation.

2. Internal Checks by Weavr​

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.

Updates to the Linked Account webhooks and Get endpoints​

We have updated the Linked Account update webhook event and both the Get linked accounts and a linked account with the new states: PENDING_CHALLENGE, PENDING_VERIFICATION and REJECTED.

Action required​

Migrate your application to start handling the new updated states related to the Linked Account verification process:

• PENDING_CHALLENGE: The Linked Account is pending challenge.
• PENDING_VERIFICATION: The Linked Account is pending the completion of the required verification steps.
• REJECTED: The Linked Account did not pass one or more verification steps and is not eligible for use.

If no action is taken​

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

• Linked Account SCA Declaration Challenge

Affected Webhook Events

• Linked Account Update

Affected API endpoints:

• GET/linked_accounts
• GET/linked_accounts/{linked_account_id}

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.

Affected API endpoints:

• POST/buyers

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.

Effective:

• 03 September 2024 on Sandbox
• 24 September 2024 on Live

Summary​

API Endpoint changes​

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.

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.

Event webhook changes​

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.

Action required​

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.

If no action is taken​

If no action is taken, your application may encounter issues when parsing the buyer resource object.

Affected webhook events:

• Buyer activation

Affected API endpoints:

• POST/buyers
• GET/buyers
• PATCH/buyers

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:

1. Login to the Embedder Portal: access your account on the embedder portal.
2. Update the supported currency in Buyer Settings: by switching on the second currency.
3. Update the Buyer details: via the PATCH/buyers endpoint to add the new supportedCurrencies.

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.

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.

Affected UI Components:

• Payment Run Auth Component

Affected Endpoints:

• POST/buyers
• PATCH/buyers
• POST/payment_runs

More details on creating a payment run is available in our documentation

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.

Effective:

• 03 September 2024 on Sandbox
• 24 September 2024 on Live

Summary​

API Endpoint changes​

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.

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.

Event webhook changes​

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.

Action required​

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.

If no action is taken​

If no action is taken, your application may encounter issues when parsing the buyer resource object.

Affected webhook events:

• Buyer activation

Affected API endpoints:

• POST/buyers
• GET/buyers
• PATCH/buyers

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.

Please read the full article on Proof of ID expiry to find out more (requires Weavr Support Portal login).

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.

Effective:

• 01 July 2024 on Sandbox
• 09 July 2024 on Live

EEA countries supported​

Weavr is now supporting buyers residing in the following countries:

Austria	Belgium	Cyprus	Denmark
Finland	France	Ireland	Italy
Estonia	Luxembourg	Latvia	Netherlands
Norway	Poland	Portugal	Slovakia
Slovenia	Spain	Sweden

Retrieve Open Banking Institutions​

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.

New API endpoints:

• Get Institutions

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​

The Get Linked Accounts & Get a Linked Account endpoints have been updated to contain the consent information with the below fields:

• expiresAt
• expiresIn
• status

Note: If the consent, expired the:

• expiresAt will contain a value of '0'.
• expiresIn will contain the date in the past of the AIS consent expired.

You will also receive the AIS consent expiry and status (expiresAt, expiresIn & status) in the link account update event.

Extend the AIS consent​

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.

• Extending an AIS consent after the 180 days pass​

  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.

Buyer endpoints updated to accept 'EUR'​

We have updated the buyer endpoints to accept the 'EUR' currency in the supportedCurrencies object:

• POST/buyers
• GET/buyers
• PATCH/buyers

Payment run endpoints updated to accept 'EUR'​

We have updated the payment run API and events endpoints to accept the 'EUR' currency in the currencies object:

• POST/payment_runs
• GET/payment_runs
• GET/payment_runs/{payment_run_id}
• GET/payment_runs/{payment_run_id}/fund

Events endpoints update:

• Payment Run Update
• Payment Update

Linked account endpoints updated to accept 'EUR'​

We have updated the linked account API and event endpoints to accept the 'EUR' currency in the currencies object:

• GET/linked_accounts
• GET/linked_accounts/{linked_account_id}
• POST/linked_accounts/{linked_account_id}/unlink

Updated Events endpoints

• Linked account update webhook

Embedder Portal settings​

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.

Effective:

• 5 June 2024 on Sandbox
• 26 June 2024 on Live

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.

Affected endpoints:

• POST/buyers/verification/email/send

Effective:

• 5 June 2024 on Sandbox
• 26 June 2024 on Live

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.

Action required​

Review and update your application logic to remove dependencies on the baseCurrency field. This will help prevent and disruptions to your integration.

If no action is taken​

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.

Affected API endpoints:

• POST/buyers
• GET/buyers
• PATCH/buyers

Effective:

• 27 February 2024 on Sandbox
• 20 March 2024 on Live

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.

Affected API endpoints:

• Create a user

More details on how to step-up a token are available in our documentation.