Skip to content

    Pre-auth Transaction Types

    This section describes the pre-authorization transaction types along with Register call and Process call.

    Pre-authorization and authorization adjustments

    When it is required to adjust the authorized amount before the capture, it can be done by implementing pre-authorization. In pre-authorization payment flow you can increase or decrease the authorized amount if you do not know the final amount to be captured when the transaction begins.

    Pre-authorization enables you to adjust the authorized amount before capture. After a payment is initiated, it allows you to increase or decrease the final amount to be captured during the payment process.

    Authorization types for order adjustments:

    • Pre-authorization is intended for use cases where the final amount to be captured is not yet known, and you may need to increase or decrease the amount at a later stage.
    • Incremental authorization allows you to increase the total authorized amount before you capture it if the authorized amount appears to be insufficient. This is helpful in situations where the total price of goods or services changes. Multiple incremental authorizations can be performed throughout the duration of the transaction.
    • Reversal authorization is used to partially reverse the authorization if the final capture amount is less than the estimated authorized amount.

    Pre-authorization, incremental and reversal authorizations are currently available only for Visa and Mastercard and through Nets DK acquiring only. See Availability for more information.

    Use cases

    There are several common use case scenarios for pre-authorizations and adjusting authorizations via card, particularly within the travel & hospitality sector.

    Below is described a use case for hotels:

    1. Customer checks in at a hotel, hotel sends a pre-authorization request for the room use and at the same time saves the card details for possible future charges.
    2. Customer decides to extend the stay with an additional night; hotel will add these new expanses to the payment and therefore sends incremental authorization to increase the total authorized amount.
    3. Customer checks out from the hotel; the final amount is lower than the authorized amount so hotel processes reversal for the difference and then captures the final amount.
    4. If necessary, the hotel processes delayed charge for the customer card after the customer has left, such as mini-bar charge, using the customer's stored payment details.

    How to use pre-authorization

    This section describes how to use pre-authorization step-by step.

    Step 1: Initialising to Pre-authorize a payment

    There are two options on how to send a pre-authorization transaction:

    Register Call:

    Specify Pre-auth in the Register call according to the API authType=PreAuth. After that, when you send Process(Auth) call, it will be triggered as pre-authorization.

    This option should be used when generating payment links through API and including autoAuth=true or autoSale=true in the Register call.

    • Transaction flow: Register(with preAuth defined)-->Terminal-->AUTH-->(increment/reversal)-->capture

    Process Call:

    Send Register call without AuthType and instead specify AuthType=PreAuth in the Process(Auth) call.

    • Transaction flow: Register-->AUTH(with preAuth defined)-->(Increment/Reversal)-->capture

    Current authorized amount is displayed in Query call response parameter: “authorizedAmount”, it is the sum of preAuth, incrementalAuth and reversalAuth.

    Step 2: Adjusting the authorization (Optional)

    After you have pre-authorized any amount, it is still possible to adjust the authorized amount at any time.

    • If the customer spends more than expected, you may obtain an additional authorization using an incremental authorization request.
    • If the estimated authorization exceeds the final amount, you must reduce the authorized amount using a partial authorization reversal before capturing. Please note that reversal authorization request can only be used here if it has been preceded by incremental authorization.

    If you haven't adjusted the initial pre-authorization and the final amount is lower than the estimated amount, you need to include isFinalCapture=true parameter to the capture request to partially reverse the authorization.

    When sending incremental or reversal authorization, you need to add the sub parameter “AuthType” in the Process(Auth) call and specify according to below instructions.

    Step 3: Finalizing the pre-authorized payment

    After making your last authorization adjustment, you need to capture the payment to finalize the transaction. Capture the final amount with the Process(Capture) call.

    If you haven’t adjusted the initial pre-authorization and the final amount is lower than authorized amount, then you need to include isFinalCapture=true parameter to the capture call to reverse the remaining authorization hold.

    If you need to charge the customer for an additional amount after they have left, and you stored customer's payment details with pre-authorization request, you can apply these additional charges by performing MIT transaction using the token (panhash).

    Pre-authorization parameters

    Pre-authorization parameters should be sent in Register Call or Process Call.

    • For Register Call, AuthType=Preauth
    • For Process Call, operation=Auth and AuthType=Preauth

    If the parameter is sent in Register Call, then no need to send AuthType=Preauth in the Process Call.

    Incremental authorization

    For incremental authorization, specify the following parameters in the Process call:

    • operation=Auth and
    • AuthType=IncrementalAuth and
    • Transactionamount=[additional authorization amount]

    An incremental authorization request must only follow a pre-authorization or another incremental authorization.

    Amount field is mandatory for incremental authorization.

    Reversal authorization

    For reversal authorization, specify the following parameters in the Process call:

    • operation=Auth and
    • AuthType=ReversalAuth and
    • Transactionamount=[reversed authorization amount]

    If transaction amount is not specified, then whole authorized amount will be reversed.

    You can partially cancel authorization with reversal request only if the incremental authorization has been used before that. A reversal after a pre-authorization request always reverses the whole amount presented in the pre-auth.

    NoShow and Delayed charges when using pre-authorization

    If initial Preauth is performed with Recurring Type=S, then you can perform MIT UCOF, No-show or Delayed charges for subsequent transactions, same as any other stored credential transactions.

    Please visit the Merchant initiated transactions section for more information.

    Technical flow

    You can find the technical flows for Register and Process call below:

    Register Call

    Netaxept_pre-auth Register call

    Process Call

    Netaxept_pre-auth Process call


    Currently you can use these authorization types only with Visa and Mastercard and through Nets DK acquiring.

    Availability by merchant category

    Visa and Mastercard permit all merchants to submit estimated (pre-authorization), incremental authorizations and reversals for purchase transactions. Estimated and incremental authorizations add significant value to merchants by allowing them to secure approved cardholder funds before any goods or services are consumed.

    Examples of industries where these are commonly used are the travel and hospitality sector, car rental and electric vehicle charging. Certain transaction types will be excluded, including account funding transactions (AFTs) and cryptocurrency purchases.

    Automated Fuel Dispenser (AFD) transactions have a customized authorization framework. Therefore, these authorization types cannot be used to implement the AFD payment flow. For more information on best practices for processing AFD transactions, see here.


    The card schemes have their own rules concerning the authorization validity period in which transaction should be captured. After this period has exceeded, the issuer is not required to to approve the capture request.

    You can often capture a payment successfully after the authorization has expired but it is good to note that this increases the risks of rejecting the transaction later and may increase the fees the acquirer charges for the transaction.

    Incremental authorizations do not extend authorization validity periods.

    The expiry information for pre-authorization for Visa and Mastercard can be seen in the table below:

    Authorization TypeValidity
    Mastercard - Pre-authorisation30 days
    Visa - Estimated authorisation7 days

    Note: Estimated authorizations for Cruise Lines, Lodging and Vehicle rental-merchants are valid 31 days.