After an authorisation is approved and is captured, the status on the authorisation is set to closed and a Transaction object is created. This normally happens within 24 hours; however hotels, airlines, and car rental companies are able to capture up to 31 days after authorisation.
When an authorization is captured, two things happen.
The status on the authorisation is set to closed, releasing the purchase amount held by that authorisation. A balance transaction of type issuing_authorization_release is created to represent this.
Spending controls, real time authorisation controls, and card status (whether a card is active or not) don’t apply for capture. They can be used to determine whether authorisations are approved, but captures for approved authorisations always succeed.
Handling other transactions
In addition to regular transactions, there are a few other cases that you should be ready to handle.
Refunds are transactions with type of refund.
When we create a transaction representing a refund or credit, we try to link it to the original payment authorisation. Refunds aren’t necessarily tied to the original payment transaction or authorisation, so linking them is an inexact science. As a result, we might link to an unrelated authorisation or be unable to link to an authorisation at all (for example, if the card is credited rather than refunded). In these cases, the authorization field of the transaction is set to null, and the transaction won’t be linked to the authorisation. We process all refunds and credits the same way, regardless of their linkage to a payment authorisation.
