> ## Documentation Index
> Fetch the complete documentation index at: https://nextgen-docs.enfuce.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
Authorisation is the process where you (our customer), Enfuce, and the ledger perform a series of real-time checks (validations) to determine whether a transaction must be approved or declined. These checks include validation of transaction data, application of technical and business rules, and verification of available funds.
* If the validations are successful and the ledger approves the authorisation request, the purchase is finalised. A successful authorisation results in an authorisation hold, where the approved amount is reserved and made unavailable for the cardholder to use.
* If the request fails any of the checks or if the ledger declines the request, the authorisation is declined; the merchants either stops the purchase or requests for an alternative payment method.
## Authorisation Workflow
The authorisation process is a part of the transaction lifecycle, and typically consists of the following steps:
1. The card Scheme sends an authorisation request to Enfuce.
2. Enfuce performs initial validations and applies relevant controls.
3. If valid, the request is forwarded to the ledger for further decisioning.
4. The ledger evaluates the request and returns an approval or decline response.
5. Enfuce processes the ledger’s response and determines the final outcome.
6. Enfuce sends the authorisation response back to the card scheme.
## Validations
Depending on the setup, Enfuce, as the processor, performs some or all of the following validations when an authorisation request is received:
Based on how you have configured the payment processing with Enfuce, we perform either all the validations or some of them. During implementation, you can discuss with your customer onboarding manager the extent of control that you will like to manage. By default, we perform the technical validations, while either you or we will manage the business and the fraud validations.
During technical verification, Enfuce reviews the security elements contained in the authorisation message. Data validation depends on the transaction type: **card-present** and **card-not-present** transactions. If technical validation fails, Enfuce declines the authorisation request and sends a corresponding response to the card Scheme.
For card present transactions, the data is captured from the chip or the magnetic stripe of the card used for the payment. We verify the following data elements:
| Element | Description |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| PAN | Review whether the PAN is matching with a PAN existing in our system. If we do not find any similar match, the request is declined. We follow the LUHN algorithm to verify whether the check digit matches with the rest of the PAN. |
| Expiry Date | Verify whether the card's expiry date matches with the expiration date recorded in our system. |
| iCCV Data (CVC/CVV on card chip) | Review the Integrated Chip VerifiThe response is sent to the cacation Value (iCVV) to ensure protection from counterfeit magnetic stripe cards, where the data from the card chip is duplicated. The iCCV contained in the card chip is different from CVV1 included in the magnetic stripe. |
| Cryptographic Data | Verify the authorisation request cryptogram to ensure that the EMV chip has not been tampered. If validation fails, the authorisation request is declined. |
| Track 1 Data (magnetic stripe transactions) | Review whether the CVV1/CVC1 on Track 1 is correct. |
| Track 2 Data (magnetic stripe transactions) | Review whether the CVV1/CVC1 on Track 2 is correct. |
| Terminal Verification Result (TVR) | The issuer rules for Terminal Action Analysis is referred to as **Issuer Action Codes** (IACs). We analyse the IACs to check whether the offline data authentication has failed. |
| Card Verification Result (CVR) | Validate the CVR stored in the EMV chip of the card. |
| Card Sequence Number | Validate the card sequence number. |
For **card not present** transactions, the chip or the magnetic stripe of the card cannot be verified. We review the following data elements:
| Element | Description |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| PAN | Review whether the PAN is matching with a PAN existing in our system. If we do not find any similar match, the request is declined. We follow the LUHN algorithm to verify whether the check digit matches with the rest of the PAN. |
| Expiry Date | Verify whether the card's expiry date matches with the expiration date recorded in our system. |
| CVV2/CVC2 Data | Review the security code of the card used in completing ecommerce transactions — the card Scheme (Visa/Mastercard) performs the pre-validation and we repeat the process. |
| 3DS Certificate (CAVV/AAV) | Validate the authentication result value in the CAVV/AAV field. |
Business validation refers to the application of rules, used to assess whether a transaction must be approved or declined. These rules are a combination of configurations defined by you as a customer, Enfuce’s own controls, applicable regulations, and the card Scheme mandates.
If Enfuce is the BIN sponsor, additional sponsor-level requirements might also be applied. These rules may include checks such as card status, token status, and spend controls. If business validation fails, Enfuce declines the authorisation request and sends a corresponding response to the card scheme.
Business Rule Validations:
| Data | Description |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Card status | The card must be in the active state. If the card is in a different state, the authorisation request is declined. |
| Online PIN tries | Checks the number of incorrect PIN entries. |
| Spend Controls | Spend control and usage limit rules are validated to determine whether a transaction must be approved or declined based on the configured parameters. For more information, see the Spend Controls. |
If both technical and business validations are successful, fraud validation is performed. This step aims to detect and prevent potentially fraudulent activity that could result in financial loss or reputational impact. Enfuce performs fraud validation through applying specialist-defined rules to detect unusual or potentially fraudulent transaction behaviour. These rules are continuously refined, based on industry best practices, fraud trends, and customer-specific behaviour analysis to minimise false positives while maintaining effective fraud prevention. For more information, see the [Fraud Management](/guides/fraud-management/overview).
As part of fraud validation, Enfuce also verifies whether customer authentication has been performed in accordance with applicable requirements. For more information, see the Authentication exemptions.
If an authorisation is approved, the ledger must place the authorised amount on an authorisation hold, ensuring the funds are reserved and unavailable to the cardholder. This hold must remain in place until a matching financial transaction (clearing) is received, a reversal is processed, or the authorisation expires.
In addition, an authorisation amount is also kept on hold in case of cumulative spend controls — if the configured limit exceeds, the authorisation request is declined and the funds are released back to the cardholder's account.
## Authorisation Validity
Card schemes have specific requirements regarding how long an authorisation amount can be held depending on the transaction type and the merchant category. Usually, for standard retail transactions, authorisation holds are valid for **7 days**.
Extended authorisation validity periods (typically up to **30 days**) are permitted for specific merchant categories (MCCs), where delayed clearing or variable amounts are allowed, such as hospitality (for example, hotels, car rentals), travel services (for example, airlines), automated fuel dispensers, and transit or parking.
**Related Parameter in API Endpoint**: [Auth Validity](https://nextgen-docs.enfuce.com/api/transaction-lifecycle/authorisation-control/authorisation-request-openapi#body-transaction-auth-validity)
Please note that this parameter is only for information and displays the Scheme provided value. If an authorisation request is purged, we will send a transaction event webhook with `PURGE_AUTHORIZATION` message category. For more information, see, [Transaction Event Webhook](/guides/transaction-lifecycle/authorisation/transaction-event-webhook).
## Authorisation Expiry and Release
The ledger is expected to purge (that is, release) an authorisation hold when it is no longer valid, usually occurs when no matching clearing transaction or reversal is received within the scheme-defined validity period. Once this period expires, the ledger must release the funds back to the cardholder’s available balance.
We send a transaction event webhook with `PURGE_AUTHORIZATION` message category. For more information, see, [Transaction Event Webhook](/guides/transaction-lifecycle/authorisation/transaction-event-webhook).
## Stand-In Processing (STIP)
When a ledger or Enfuce is unavailable to respond to an authorisation request, the card Scheme approves/declines the request, based on the STIP parameters and limits that are defined for your business. The parameters and limits depend on the card type (debit, credit, prepaid).
If you are using the Enfuce BIN sponsorship, we define the STIP parameters and limits.
The card Scheme acts in the STIP mode, only during the following scenarios:
* Enfuce/Ledger's system is unavailable.
* Enfuce/Ledger's response has timed out.
* Invalid response received from the Enfuce/ledger.
Once the Enfuce/ledger's system is available and responsive, the card Scheme sends an `ADVICE` message to Enfuce — this informs us about the transactions (both approved and declined) processed in the STIP mode.
* We process the data and accordingly adjust the cardholder's account balance (if we are managing the cardholder's account balance in our system).
* Or, if the cardholder's balance is handled in an external ledger, we send a [transaction event webhook](/guides/transaction-lifecycle/authorisation/transaction-event-webhook):
* If the authorisation was approved, we send the `INITIAL_AUTHORIZATION` message category with `ADVICE` function.
* If the authorisation was declined, we send the `DECLINED_AUTHORIZATION` message category with `ADVICE` function.