Skip to main content
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:
For card not present transactions, the chip or the magnetic stripe of the card cannot be verified. We review the following data elements:
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:
This list is not exhaustive, and it includes only a few examples.
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.
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.

​
Authorisation Hold

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
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.

​
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.

​
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:
    • 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.