Reconciliation using webhooks

Introduction

This guide provides a practical overview of how to reconcile payments using webhook events from our system. It is based on a detailed breakdown of various outgoing and incoming payment scenarios, showing how each transaction flows through the system — from instruction creation to processing and final booking.

You will learn how to interpret balance changes across different stages of a payment, including when and how webhook notifications are triggered. This is particularly useful for understanding how to reconcile your own system’s records with ours, especially around End of Day events.

---

How to Use This Guide

Each section corresponds to a specific payment scenario (e.g. an outgoing SEPA Instant payment instructed on a business day). Within each section:

• Events are listed in the order they occur.
• Each row represents a point-in-time update to a transaction or balance.
• Balance columns show the available and booked balances at that point in time.
• Webhooks events (including the eventType) are highlighted to show when you'll receive updates from our system.
• Closing balances are included to demonstrate the state of the account after all events and the End of Day process.

---

Key Concepts

Event Types

• Instruction Created: The initial submission of a payment.
• Payment Processed: The payment has been submitted to the scheme and accepted.
• Payment Booked: An accounting event indicating that the transaction has impacted the account balance.
• Webhook Events: System-generated notifications sent to your endpoint that inform you of changes in transaction state or balances. The Webhooks guide lists all supported events.

🔎

Note: "Processed" and "Booked" are independent events and may occur in any order

Depending on scheme rules and compliance steps (e.g. sanction screening), booking may occur before or after processing

Balance Types

• Available Balance: Funds available for immediate use.
• Booked Balance: The accounting balance that includes settled transactions.
• These may differ temporarily, especially during periods of high activity or End of Day processing.

Timing and End of Day

• The End of Day process depends on the account branch and currency. For this guide, we will assume it begins at 7:00 PM and that it may take some time to complete.
• Transaction timestamps and balance updates may span across days depending on the type of transaction, scheme rules, and processing timing.
• Processing times are for illustrative purposes and can vary.

---

Learn More

• Payment lifecycle Documentation
• Webhooks Events Documentation

---

Outgoing Payment Scenarios

Below are several distinct scenarios for outgoing payments, showing how our system behaves under different timing, scheme, and processing conditions.

Scenario 1: Instant Payment Before EOD

This scenario illustrates an instant outgoing payment (e.g. SEPA Instant) made before End of Day on a valid financial business day, with no delays.

This is a typical example of a fast, uninterrupted payment flow where processing and booking happen close together and on the same day.

Closing Balances

---

Scenario 2: Payment Delayed Due to Sanction Screening

This scenario illustrates a standard SEPA Credit Transfer where the payment is slightly delayed due to internal compliance/sanction screening checks.

It demonstrates how the "booked" event can occur before the "processed" event, depending on internal checks and timing.

Closing Balances

ℹ️

Note: Compared to Scenario 1, the processed and booked events are reversed here due to sanction screening delays.

---

Scenario 3: Payment After EOD or on Non-Business Day

This scenario shows a payment made either after the End of Day process or on a non-valid financial business day.

As a result, the system pushes the value date and transaction date to the next valid business day (T+1).

Closing Balances

---

Scenario 4: Rejected Payment

This scenario illustrates a rejected outgoing payment, such as a SEPA Instant transfer rejected by the scheme or by internal validation.

The rejection results in no changes to balances and is confirmed via a dedicated webhook.

Closing Balances

---

Scenario 5: Reversed Payment

This scenario demonstrates a payment that was initially processed and booked but subsequently reversed.

Reversals can occur when the payment scheme rejects the payment.

Closing Balances

---

Scenario 6: Instant Payment During EOD

This scenario shows an instant outgoing payment made during the End of Day process.

While the payment is processed and value-dated on the same day, the booking is delayed until after EOD, affecting the timing of balance updates.

Closing Balances

---

Incoming Payment Scenarios

These examples show how incoming payments are handled depending on the timing of receipt and the system's End of Day (EOD) processing.

---

Scenario 7: Incoming Payment Before EOD

This scenario covers an incoming payment received and booked on a valid financial business day, before End of Day.

It shows the standard flow for incoming funds that are fully settled and reflected within the same business day.

Closing Balances

---

Scenario 8: Incoming Payment After EOD or on Non-Business Day

This scenario demonstrates an incoming payment processed after the End of Day process or on a non-business day.

Because of timing, the transaction is processed and booked on the following valid business day (T+1).

Closing Balances

---

Scenario 9: Incoming Instant Payment During EOD Process

This scenario illustrates an incoming instant payment received during the End of Day process.

Although the payment is processed quickly, it is booked only after the End of Day cycle finishes, resulting in a T+1 booking.

Closing Balances

ℹ️

Note: Although the instant payment is received on Monday, it is booked only after the EOD process ends, hence the transaction and value dates are both set to Tuesday (T+1).

Other scenarios

Returns

A return is treated as two separate payments:

1. An outgoing payment (the original transaction that was sent out), and
2. An incoming payment (the returned funds).

The incoming payment will include a flag ("return":true") in both the IncomingPaymentProcessed webhook payload and the GET payments response to indicate it is a return.

The remittance information will also contain the transaction reference of the original outgoing payment.