Fund a Payment Run
Enable your customers to allocate funds for a payment run via one of their linked accounts.
To fund a payment run, you need:
- A payment run with the
PENDING_FUNDSstatus - A linked account
- A logged-in user with the
Controllerrole - For Open Banking a redirect URL configured in the portal via Settings > Application Details
Different banks have different transaction limits which may interfere with the payment run funding process. If Weavr detects that a limit is going to be reached, the payment run is automatically split into groups, each having its own funding process.
Weavr does it's best to keep track of such banking limits. Contact us if your customers encounter an unhandled limit.
Embed the Payment Fund Secure UI Component
The first step to fund a Payment Run is to embedded the payment fund UI Component into your application. Follow the Payment Fund UI Component integration guide to learn how to embed this flow within your product.
Fund payment run process
Start the funding process by retrieving the funding groups via API.
The API endpoint returns one or more funding groups to be used during the funding process.
For each funding group returned, the user is asked to consent for funds to be transferred from their chosen linked account to the Zero balance account (ZBA).
ZBA Sweeping Consent
If the chosen linked account is being used to fund a payment run for the first time, the UI component first requests the user to give their consent to sweep the ZBA.
The sweeping consent enables Weavr to transfer any residual funds in the account back to the Linked account at end-of-day (6pm CET). This ensures that no funds are kept unnecessarily in the account.
To confirm the consent, the user must successfully complete SCA. At the moment, this will be done by sending an OTP to the user's registered mobile device which needs to be inputted by the user in the UI component. The OTP expire after 5 minutes of inactivity.
Open Banking funding
Once the consent is approved and the user is using open banking he is presented with another screen that has the amount of the payment run that will be requested and if they agree; they are redirected to their Banking Portal. In their Banking Portal, the bank will ask them to authenticate themselves and will show the amount being transferred to the user.
For the UI component to work, you must configure the Open Banking redirect URL in the portal. This URL is used to redirect the user back to your product once they complete the funding process.
If the user approves, this triggers a bank transaction with the approved amount to be transferred from the linked account to the ZBA. The user is then automatically redirected to your product on the configured Open Banking redirect URL. If the user clicks on I Don't Consent, the component triggers a decline event which should be handled by the application.
With our solution, you are not required to become a third-party provider (TPP) or an Agent of a TPP. Instead you can use our UI components to embed the Open Banking flows in your product.
Manually funding Account
After consent is approved and the user chooses manual funding, they are presented with a screen showing the payment run amount, funding account details, and step-by-step instructions to complete the transfer through their bank to fund the ZBA.
The payment run can only be executed once the ZBA is fully funded by the user. The funding amount and reference must exactly match the details displayed in the Payment Fund UI component; otherwise, the plugin will reject the transaction
Funding Matching Logic
When funding a payment run, Weavr follows a structured matching process to ensure accurate allocation of funds:
Reference Match
The system first checks if the reference included in the funding request matches the reference associated with a pending payment run.
- If a match is found, the payment run is funded and the associated payments are executed.
Amount Match
If no reference match is found, the system will look for pending payment runs that match the funding amount.
- If only one payment run matches the amount, the funding is allocated to that run and the payments are executed.
- If no matching payment runs are found, the funding is rejected and the funds are returned to the sender.
- If multiple runs match the funding amount, the system will allocate the funding to the oldest matching payment run.
This logic ensures that payment runs can still be matched reliably even when the reference is altered or masked by the originating bank.
Execute payments
Depending on the banking rails supported by your customer's bank, the transfer may be instant or else can take up a number of hours.
As soon as funds are received in the ZBA, the payments within the run's funding group are automatically triggered and the payment run status transitions to EXECUTING. A payment run event is sent to you, notifying you that the supplier payments are being executed.
Once all payments are executed, the payment run transitions to a COMPLETED status. If one or more payments failed, the payment run status transitions to COMPLETED_WITH_ERRORS.
Testing Grouping Logic in Sandbox
To better understand how payment run grouping works in practice, we recommend testing this logic in the Sandbox environment.
You can simulate the funding process using the Mock Bank, which has a default funding limit of £10,000 (or €
10,000) per transaction.
For example, if you create a payment run containing two payments of £10,000 each (total £20,000), the system will automatically split the payment run into two groups, each conforming to the configured limit. This will allow you to:
- Observe how payments are grouped based on funding thresholds
- Verify how the system behaves before going live
- Ensure your implementation handles grouping correctly
If you need support setting up your test scenarios or interpreting the results, feel free to reach out to us.