The following diagram shows an overview of the payment flow and the payment stages.<\/p>\n
![\"Diagram](\"\/user\/pages\/docs\/07.issuing\/23.payment-stages\/payment-stages.svg?decoding=auto&fetchpriority=auto\")
<\/p>\n
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<\/a> for specific webhook types and examples.<\/p>\n 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<\/a> webhook message that contains information about the received payment request, such as the amount and which merchant initiated the payment.<\/p>\n 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<\/a>, the outcome of transaction rules<\/a>, and other validations<\/a>. Adyen sends a balancePlatform.transfer.updated<\/a> webhook message to inform your server of the payment authorisation request and of the result.<\/p>\n 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<\/a> amount.<\/p>\n The processing merchant can then proceed to capture the payment, cancel the payment, or let the authorisation expire.<\/p>\n 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<\/a> webhook message to inform your server of this event.<\/p>\n 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<\/a> amount is added back to the available<\/a> amount.<\/p>\n Adyen sends a balancePlatform.transfer.updated<\/a> webhook message to inform your server of this event.<\/p>\n The processing merchant can cancel a payment authorisation up until the moment the funds are captured. In the balance account, the previously reserved<\/a> amount is added back to the available<\/a> amount.<\/p>\n Adyen sends a balancePlatform.transfer.updated<\/a> webhook message to inform your server of this event.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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<\/a>.<\/p>\n Example<\/strong>:<\/p>\n 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.<\/p>\n 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.<\/p>\n An authorisation can be followed by multiple separate captures. This is also referred to as multicapture.<\/p>\n Multiple partial captures are common with online retailers and in the airline industry, where one transaction represents a purchase order that includes multiple items.<\/p>\n Example 1<\/strong>:<\/p>\n 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.<\/p>\n 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.<\/p>\n When the last item ships later, the merchant captures the remaining EUR 40.00.<\/p>\n Example 2<\/strong>:<\/p>\n 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.<\/p>\n The airline captures each ticket separately, even though both are booked at the same time. Both captures are made against the same initial authorisation.<\/p>\n 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.<\/p>\n Example<\/strong>:<\/p>\n 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.<\/p>\n 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:<\/p>\n 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<\/a> set to syntheticAuthorisation<\/strong><\/span> in the transfer webhook message.<\/p>\n 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.<\/p>\n Important points to note:<\/p>\n 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<\/a> to cover card payment operations.<\/p>\n<\/li>\n 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.<\/p>\n<\/li>\n<\/ul>\nPayment request received<\/h2>\n
Payment authorised<\/h2>\n
Authorisation adjusted<\/h3>\n
Authorisation expired<\/h3>\n
Authorisation canceled<\/h3>\n
Payment captured<\/h2>\n
\n
Partial capture<\/h3>\n
Multiple partial captures<\/h3>\n
Overcapture<\/h3>\n
Forced capture<\/h3>\n
\n
\n
![\"Diagram](\"\/user\/pages\/docs\/07.issuing\/23.payment-stages\/refund.svg?decoding=auto&fetchpriority=auto\")
<\/p>","url":"https:\/\/docs.adyen.com\/issuing\/payment-stages","articleFields":{"description":"Learn about the payment stages and when funds are added to or deducted from the balance account.","next_steps":[{"title":"Configure authorisation","description":"Approve or decline payments by using transaction rules or relayed authorisation.","url":"\/issuing\/authorisation","required":true},{"title":"Set up webhooks","description":"Receive payment updates through webhooks.","url":"\/development-resources\/webhooks\/configure-and-manage","required":true},{"title":"Payment-related events","description":"Learn which webhook types to expect.","url":"\/issuing\/webhook-types\/payment-events","required":true}],"last_edit_on":"06-12-2019 14:44","parameters":{"directoryPath":"\/issuing"}},"algolia":{"url":"https:\/\/docs.adyen.com\/issuing\/payment-stages","title":"Payment stages","content":"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:\n\nWebhooks\nThe Transfers page in your Customer Area.\n\nThe following diagram shows an overview of the payment flow and the payment stages.\n\nThis 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.\nPayment request received\nWhen 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.\nPayment authorised\nWhen 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.\nWhen 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.\nThe processing merchant can then proceed to capture the payment, cancel the payment, or let the authorisation expire.\nAuthorisation adjusted\nThe 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.\nAuthorisation expired\nA 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.\nAdyen sends a balancePlatform.transfer.updated webhook message to inform your server of this event.\nAuthorisation canceled\nThe 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.\nAdyen sends a balancePlatform.transfer.updated webhook message to inform your server of this event.\nPayment captured\nA 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:\n\nWhen a transaction is authorised, the amount is reserved on the cardholder\u2019s balance, but not yet deducted from the balance.\nDuring capture, the merchant confirms the transaction and asks for the reserved funds to be transferred.\nWhen 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.\n\nA 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.\nPartial capture\nA 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.\nExample:\nThe 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.\nHowever, 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.\nMultiple partial captures\nAn authorisation can be followed by multiple separate captures. This is also referred to as multicapture.\nMultiple partial captures are common with online retailers and in the airline industry, where one transaction represents a purchase order that includes multiple items.\nExample 1:\nThe 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.\nThe 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.\nWhen the last item ships later, the merchant captures the remaining EUR 40.00.\nExample 2:\nA 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.\nThe airline captures each ticket separately, even though both are booked at the same time. Both captures are made against the same initial authorisation.\nOvercapture\nAn 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.\nExample:\nAt 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.\nForced capture\nA forced capture means that a transaction is captured without a valid authorisation because the authorisation was declined or never received. This can happen in:\n\nOffline environments, such as when buying snacks on an airplane.\nAutomated environments, like vending machines or parking garages.\nTechnical failures, where an online authorisation cannot be completed, and the transaction is submitted later as a capture.\n\nIn 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.\nYou 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.\nImportant points to note:\n\n\nA 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.\n\n\nIf the forced capture is linked to an inactive or blocked balance account, Adyen debits the amount from the liable balance account of your platform.\n\n\nExample:\nA 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.\nPayment refunded\nThe 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.\n","type":"page","locale":"en","boost":18,"hierarchy":{"lvl0":"Home","lvl1":"Adyen Issuing","lvl2":"Payment stages"},"hierarchy_url":{"lvl0":"https:\/\/docs.adyen.com\/","lvl1":"https:\/\/docs.adyen.com\/issuing","lvl2":"\/issuing\/payment-stages"},"levels":3,"category":"Issuing","category_color":"green","tags":["Payment","stages"]},"articleFiles":{"payment-stages.svg":"![\"\"](\"https:\/\/docs.adyen.com\/user\/pages\/docs\/07.issuing\/23.payment-stages\/payment-stages.svg?decoding=auto&fetchpriority=auto\")
","refund.svg":"![\"\"](\"https:\/\/docs.adyen.com\/user\/pages\/docs\/07.issuing\/23.payment-stages\/refund.svg?decoding=auto&fetchpriority=auto\")
"}}