Each payment on the Balance Platform goes through a series of events. Most of the events are triggered by the processing merchant, the business that processed the card payment. These events then result in funds being deducted from or added to the balance account. We inform you of these events through:
- Webhooks
- The Transfers page in your Customer Area.
The following diagram shows an overview of the payment flow and the payment stages.
This page provides information about payment stages and how these affect funds in the balance account. When you are already familiar with payment stages, you can refer to Payment-related events for specific webhook types and examples.
Payment request received
When a cardholder pays with an Adyen-issued card, the processing merchant sends a payment request to the card issuer (Adyen). When Adyen receives the payment request, we send a balancePlatform.transfer.created webhook message that contains information about the received payment request, such as the amount and which merchant initiated the payment.
Payment authorised
When the processing merchant sends a payment authorisation request to the card issuer, Adyen approves or declines the payment based on your relayed authorisation decision, the outcome of transaction rules, and other validations. Adyen sends a balancePlatform.transfer.updated webhook message to inform your server of the payment authorisation request and of the result.
When the payment is authorised, the payment amount is reserved but not yet deducted from the balance account. When you check the balance account details, the payment amount is reflected as a reserved amount.
The processing merchant can then proceed to capture the payment, cancel the payment, or let the authorisation expire.
Authorisation adjusted
The processing merchant can adjust the previously authorised amount. For example, a hotel can adjust the amount when the guest incurs expenses in addition to the amount that was authorised for the room. In this case, Adyen sends a balancePlatform.transfer.updated webhook message to inform your server of this event.
Authorisation expired
A payment authorisation expires when the processing merchant fails to capture the payment after the set expiry period of 7 days. In the balance account, the previously reserved amount is added back to the available amount.
Adyen sends a balancePlatform.transfer.updated webhook message to inform your server of this event.
Authorisation canceled
The processing merchant can cancel a payment authorisation up until the moment the funds are captured. In the balance account, the previously reserved amount is added back to the available amount.
Adyen sends a balancePlatform.transfer.updated webhook message to inform your server of this event.
Payment captured
A payment capture is the stage where Adyen deducts the purchase amount, as instructed by the processing merchant, from the balance account. The flow is as follows:
- When a transaction is authorised, the amount is reserved on the cardholder’s balance, but not yet deducted from the balance.
- During capture, the merchant confirms the transaction and asks for the reserved funds to be transferred.
- When the payment is captured, the reserved amount is deducted from the balance account and sent to the processing merchant. Adyen sends a balancePlatform.transfer.updated webhook message to inform your server of this event.
A full capture, which collects the entire authorised amount, is the default. However, there are other types of payment captures. These include partial captures, overcaptures, multicaptures, and forced captures.
Partial capture
A partial capture occurs when a processing merchant captures less than the original authorised amount. The remaining funds from the authorisation are released after the expiry timeframe.
Example:
The cardholder orders two items in one transaction and pays in total EUR 120.00. The full transaction amount is authorised and reserved on their card.
However, one of the items is no longer available. The processing merchant ships only one item, worth EUR 80.00, and makes a partial capture request for that amount. The authorisation for the remaining funds expires.
Multiple partial captures
An authorisation can be followed by multiple separate captures. This is also referred to as multicapture.
Multiple partial captures are common with online retailers and in the airline industry, where one transaction represents a purchase order that includes multiple items.
Example 1:
The cardholder orders two items in one transaction and pays in total EUR 120.00. The full transaction amount is authorised and reserved on their card.
The merchant ships one of the items, worth EUR 80.00, and makes a partial capture request for that amount. The second item is delayed, so the remaining EUR 40.00 stays reserved.
When the last item ships later, the merchant captures the remaining EUR 40.00.
Example 2:
A cardholder books a round-trip flight with the same airline. The full amount for both legs of the journey is authorised at the time of booking.
The airline captures each ticket separately, even though both are booked at the same time. Both captures are made against the same initial authorisation.
Overcapture
An overcapture occurs when the amount captured is higher than the originally authorised amount. This can happen in scenarios where the final amount is higher than the original authorisation.
Example:
At a restaurant, the card is authorised for the cost of the meal. After the customer adds a tip and signs the receipt, the final amount is updated. The restaurant then captures the full amount, including the tip.
Forced capture
A forced capture means that a transaction is captured without a valid authorisation because the authorisation was declined or never received. This can happen in:
- Offline environments, such as when buying snacks on an airplane.
- Automated environments, like vending machines or parking garages.
- Technical failures, where an online authorisation cannot be completed, and the transaction is submitted later as a capture.
In these cases, the card scheme sends a capture request to Adyen without a matching authorisation. Adyen cannot decline forced captures and must process the transaction and deduct the funds. You can identify this with authorisationType set to syntheticAuthorisation in the transfer webhook message.
You or the cardholder can dispute a forced capture if the transaction is illegitimate. Whether the dispute leads to a chargeback depends on whether authorisation was required, the transaction type, and regional rules.
Important points to note:
-
A forced capture skips the balance check because balance checks occur during authorisation, not during capture. If there are not enough funds in the balance account at the time of capture, the transaction can lead to a negative balance. To avoid this, we recommend making sure that the balance account always has sufficient funds to cover card payment operations.
-
If the forced capture is linked to an inactive or blocked balance account, Adyen debits the amount from the liable balance account of your platform.
Example:
A cardholder buys a snack on an airplane for EUR 5.00. Because the airplane is offline, the payment terminal cannot request authorisation. The transaction is submitted as a capture when the airplane lands and reconnects.
Payment refunded
The cardholder can ask to get their funds back. When the processing merchant initiates a refund, Adyen sends a balancePlatform.transfer.updated webhook message to inform your server of the refund request.
