Skip to main content

13 posts tagged with "breaking-change"

View All Tags

Breaking Change (28 October 2024) Stepup required for patching an authorised user

· One min read

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.

Action required

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.

If no action is taken

If no action is taken, your application will encounter issues when updating an authorised user.

stepup

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

Affected API endpoint:


Breaking Change (28 October 2024) Introducing Confirmation of Payee (CoP for GBP payments)

· 4 min read

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).

Effective:

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

Payment Run and Payments API Endpoint Summary

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:

Create a Payment Run API endpoint updates

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.

info

The CoP results will also be sent through the payment run update and payment update webhook events.

Once the CoP results are returned, the payment runs state will transition to PENDING_CONFIRMATION.

Payments Run states updates

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.

Payments states updates

To add more visibility and to align the payment statuses with the payment run, we have made the below changes:

  • Removing the SUBMITTED and CREATED state from the Payment Run.
  • Adding:
    • QUEUED
    • PENDING_CONFIRMATION
    • EXECUTING
    • AWAITING_FUNDS

Get payment run endpoints

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

New Update a Payment Run API endpoint

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.

More information about roles can be found here.

Payment Run Authorisation UI Component

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

Payment Run lifecycle

The payment run lifecycle has been updated accordingly to explain the new overview states:

Payment Run State machine

Summary of Action required

Migrate your application to start handling:

  1. The create a payment run endpoint now requires the type to be specified as either PERSONAL or BUSINESS when creating GBP payments.
  2. The new updated states related to Payment Run statuses and the Payment Run line statuses.
  3. Accept the updated response with the CoP results (validationOutcomes)for the following:
    1. Webhook events:
      1. Payment Run Update
      2. Payment Update
    2. UI Components:
      1. Payment Run Auth Component
    3. API endpoints:
      1. POST/payment_runs
      2. GET/payment_runs
      3. GET/payment_runs/{payment_run_id}
  4. Optionally, use the PATCH/payment_runs/{payment_run_id} endpoint to edit Payee details of a payment based on CoP results.
danger

This will help prevent any disruptions to your integration.

If no action is taken

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.


Breaking change (28 October 2024) APP Fraud Prevention - Linking an Account

· 4 min read

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:

t&c

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:

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:

microenterprise

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

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.

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.

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.

Compliance Checks

The Compliance will reach out to the Identity before rejecting the Linked Account.

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

Affected Webhook Events

Affected API endpoints:


Breaking change (October 2024) APP Fraud Prevention - Linking an Account

· 5 min read

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:

t&c

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:

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:

microenterprise

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

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.

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.

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.

Compliance Checks

The Compliance will reach out to the Identity before rejecting the Linked Account.

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

Affected API endpoints:


Breaking Change (October 2024) Stepup required for patching an authorised user

· One min read

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.

Action required

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.

If no action is taken

If no action is taken, your application will encounter issues when updating an authorised user.

stepup

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

Affected API endpoint:


Breaking Change (October 2024) Introducing Confirmation of Payee (CoP for GBP payments)

· 4 min read

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).

Effective:

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

Payment Run and Payments API Endpoint Summary

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:

Create a Payment Run API endpoint updates

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.

info

The CoP results will also be sent through the payment run update and payment update webhook events.

Once the CoP results are returned, the payment runs state will transition to PENDING_CONFIRMATION.

Payments Run states updates

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.

Payments states updates

To add more visibility and to align the payment statuses with the payment run, we have made the below changes:

  • Removing the SUBMITTED and CREATED state from the Payment Run.
  • Adding:
    • QUEUED
    • PENDING_CONFIRMATION
    • EXECUTING
    • AWAITING_FUNDS

Get payment run endpoints

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

New Update a Payment Run API endpoint

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.

More information about roles can be found here.

Payment Run Authorisation UI Component

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

Payment Run lifecycle

The payment run lifecycle has been updated accordingly to explain the new overview states:

Payment Run State machine

Summary of Action required

Migrate your application to start handling:

  1. The create a payment run endpoint now requires the type to be specified as either PERSONAL or BUSINESS when creating GBP payments.
  2. The new updated states related to Payment Run statuses and the Payment Run line statuses
  3. Accept the update response with the CoP results (validationOutcomes)on the below:
    1. Webhook events:
      1. Payment Run Update
      2. Payment Update
    2. UI Components:
      1. Payment Run Auth Component
    3. API endpoints:
      1. POST/payment_runs
      2. GET/payment_runs
      3. GET/payment_runs/{payment_run_id}
  4. Optionally use the Patch a payment run endpoint to edit Payee details based on CoP results
danger

This will help prevent any disruptions to your integration.

info

More information, along with the YAML file of the changes, will be provided to you in the coming days.

If no action is taken

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.


Breaking change (03 September 2024) - Adding a new currency status in the buyer resource

· 3 min read

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.
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.

danger

The update a buyer endpoint requires a user with admin role and a stepped up token.

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.

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:

Affected API endpoints:


Removing the deprecated delete a linked account endpoint

· One min read

As previously communicated, we are removing the deprecated delete a linked account endpoint.

Effective:

  • 12 August 2024 on Sandbox
  • 20 August 2024 on Live
note

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.

Action required

Migrate your application to start using the new unlink an account endpoint and remove dependencies on the delete a linked account endpoint.

If no action is taken

If no action is taken, you will receive an HTTP 404 error when calling the delete a linked account endpoint.

Affected API endpoints:


Breaking change (03 September 2024) - Adding a new currency status in the buyer resource

· 3 min read

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.
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.

danger

The update a buyer endpoint requires a user with admin role and a stepped up token.

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.

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:

Affected API endpoints:


Breaking change (5 June 2024) - Removal of the Buyer base currency field

· One min read

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:


Extend an Account Information Service (AIS) Consent

· 2 min read

Effective:

  • 27 March 2024 on Sandbox
  • 2 April 2024 on Live

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.

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 has 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.

To extend the consent you need to provide the linkedAccountId parameter of the linked account in the AIS UI Component.

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.

Affected API endpoints:

More details on how to extend the AIS consent is available in our documentation


Creation of Authorised Users now requires the user to step-up their token

· One min read

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:

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


OTP retries are now limited

· One min read

Effective:

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

To reduce the risk of fraud, we are now limiting the number of times a one-time-password can be submitted incorrectly.

Secure UI Components

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.

Affected Secure UI Components:

API endpoints

We have introduced 2 new error codes for the HTTP 409 response:

  • ONE_CHALLENGE_LIMIT_REMAINING - returned when the user has one try left
  • CHALLENGE_LIMIT_EXCEEDED - returned when the user has exceeded their OTP retries

Affected API endpoints: