10 posts tagged with "payment-runs"

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.

Cancel a payment run line​

Allows cancellation of individual payment lines before confirmation by a Controller.

• Cancel a payment run payment (https://weavr-multi-api.redoc.ly/3.51.0/tag/Access#operation/putCancelPaymentRunPayment)

Update a payment run line​

Allows modification of payment line details before confirmation by a Controller.

• Update a payment run payment (https://weavr-multi-api.redoc.ly/3.51.0/tag/Access#operation/putPaymentRunsId)

More information can be found in our documentation here.

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.

Affected UI Components:

• Payment Run Authorisation UI Component

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.

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.

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:

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.

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.

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.

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.

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:

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

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.

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

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:

• 25 June 2024 on Sandbox
• 26 June 2024 on Live

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.

Affected Endpoint

• GET /payment_runs

Effective:

• 14 May 2024 on Sandbox
• 17 May 2024 on Live

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.

Simulator API Endpoints​

• Issue a Payment Run SCA challenge:
  • This endpoint will allow you to simulate an SCA challenge for a payment run.
• Verify a payment run SCA challenge:
  • This endpoint will allow you to simulate a verification of the SCA Challenge for a payment run

Note: These endpoints are only available on Sandbox and won’t work in the Live environment.

More details on simulators is available in our documentation

Effective:

• 29 April 2024 on Sandbox
• 30 April 2024 on Live

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.

You can find more information about the Zero Balance Account and Payment Run creation in our docs.

Affected API endpoints:

• POST/payment_runs

Effective:

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

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:

Create a payment run​

When a user is creating a payment run and the supplier bank details includes a:

• Linked account the endpoint will fail with an HTTP 409 error BANK_ACCOUNT_CANNOT_BE_LINKED_ACCOUNT
• Zero balance account the endpoint will fail with an HTTP 409 error BANK_ACCOUNT_CANNOT_BE_ZERO_BALANCE_ACCOUNT respectively.

The payment run together with all the payments within the payment run will transition to a CANCELLED status.

Confirm a payment run & Payment Initiation Service (PIS) UI Component​

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.

Affected API endpoints:

• Create a payment run
• Confirm a payment run

Affected UI components:

• Payment Initiation Service UI Component