> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/cards/card-payment-lifecycle/understanding-final-authorisation-and-pre-authorisation.md). # Understanding Final-Authorisation and Pre-Authorisation The two card-transaction models and what they let you do The authorisation model determines whether the amount is fixed from the start or may still change later. It also determines whether you can capture the payment as-is, change the amount, or cancel it before completion. #### Final-authorisation Final-authorisation is the simpler of the two models. It is best for payments where the amount is known in advance and is not expected to change. * The amount you authorise is the amount you later capture. * You do not change the payment amount during the normal flow. * If the payment should not continue, it can only be cancelled in the cases allowed by your scheme, acquirer, and configuration. Think of this flow as authorise first, capture later, with the same amount throughout. It is the most natural choice for fixed-price purchases such as standard ecommerce orders. This model is usually described as a straightforward authorise-and-capture flow with a limited cancellation window if the payment has not yet been captured. #### Pre-authorisation Pre-authorisation is the flexible model. Use it when the final amount may change, or when you need the option to cancel the payment before it is completed. * You can capture a smaller amount than the amount you originally authorised. * You can release the authorisation instead of completing it, when that is allowed. * You can use it for workflows where the final charge depends on a later event. This model is common in hotel stays, car rentals, travel bookings, deposits, and pre-orders. In those cases, the amount available at the beginning is only an estimate, so the payment needs room to change later. In merchant terms, **pre-authorisation** gives you two kinds of flexibility: you can adjust the amount downward when the final charge is lower, or you can cancel the payment if the order does not go ahead. Use final-authorisation when the amount is fixed. Use pre-authorisation when the amount may change or when you want more control before capture. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/payment-methods/cards/card-payment-lifecycle/understanding-final-authorisation-and-pre-authorisation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.