Skip to main content

​
Authorisation

The merchant’s payment terminal generates an authorisation request that is sent to the merchant’s acquirer, who in turn forwards it to the card scheme (Visa or Mastercard), from where it is sent to the issuer or the issuer’s processor.
After the issuer has processed the authorisation request, the response is sent back the same way:
The authorisation process includes both technical validations and business validations. If the necessary validations are successful, the available amount is reduced by the authorisation amount plus any potential fees and currency mark-ups. The merchant will receive a response to confirm whether the request was successful/declined and an authorisation code that serves as the confirmation of a successful authorisation. The amount remains blocked until:
  • The financial transaction is received or
  • A reversal is received or
  • Until the authorisation is cleared.
An authorisation block usually clears when it is matched with a financial transaction. However, if no matching financial transaction is received, the system will automatically clear the authorisation after 7 days. Unmatched authorisations are purged once per day.

​
Authorisation processing at Enfuce

The authorisation process consists of three consecutive steps:
  1. Technical validation
  2. Business validation
  3. Fraud validation
Depending on the setup, all or some of these steps are handled by Enfuce. This section will describe the scope and purpose of each step. Please refer to the Authorisation Control page guide for setups where some of the steps are the responsibility of the issuer.

​
Technical validation

Technical validation refers to the practice of verifying that the security elements present in the authorisation message comply with the data and keys in the system. The technical validation of data elements is categorised based on whether the transaction is ‘Card present’ or ‘Card not present’. For ‘Card present’ transactions, the validation is determined by different security elements captured from the chip/magnetic stripe at the point of interaction. These validations include PIN, CVV/CVC, chip certificate, expiry date, card status etc. For ‘Card not present’ transactions, the chip/magnetic stripe cannot be read. There are other security elements to be verified, such as CVV2/ CVC2, CAVV/AAV (3D Secure validation), expiry date and card status. In case the verification of the technical authorisation gives a negative result, Enfuce will decline the authorisation and generate a response to the card scheme. In the next table, we describe the different technical validations which are performed. Data element validation for both ‘Card present’ and ‘Card not present’ instances ‘Card present’ data element validation ‘Card not present’ data element validation The technical validation is not done for authorised transactions posted via the API (Top-up and Refund positive balance).

​
Business validation

Business validation refers to the validating rules defined by yourself or your customer. These rules include, for example, card and account status, available balance and your advanced spend controls. If the business validation fails, Enfuce will decline the authorisation and generate a response to the card schemes. The following tables describe the different business rule validations for authorisations.

​
Credit and debit cards

The business validation is also performed for the following transactions posted via the API:
  • Refund positive balance ‘RE’ (debiting)
    • A refund positive balance transaction posted via the API will be rejected if there isn’t a sufficient amount of available balance.
  • Prepaid top-up ‘TP’ (crediting)
    • A Prepaid top-up transaction posted via the API will be rejected if the limits in the spend control for said transaction type have been reached.

​
Fraud validation

If both technical and business validations are successful, the authorisation request is forwarded to Enfuce (or external) fraud monitoring system for fraud validation. Fraud validation aims to reduce the risk of fraudulent activity that might result in financial losses and damage to reputation. As part of the fraud validation process, Enfuce also validates that customer authentication has been performed as required. Please see the Authentication guide for more details on these requirements. See more on the fraud section of our guide.

​
Authorisation reversals and authorisation of credit transactions

Merchants can reverse authorisations in cases where the financial transaction is not yet sent and the authorisation block is the only action done for the purchase. In this case, Enfuce receives an authorisation reversal and the original authorisation is reversed and the available balance is increased immediately. Merchants also send authorisations for credit transactions. Credit transactions can be purchase refunds or so-called ‘original credits’ like casino winnings. As per card scheme recommendation, these authorisations are treated as information of an upcoming credit. When the authorisation is processed, it does not increase the available balance until the financial transaction is processed.

​
Authorisation response

After the authorisation processing is concluded, Enfuce generates a response that directs the merchant on how to proceed with the transaction. If validations are successful and the authorisation is approved, the purchase can be finalised. If the authorisation is declined, the merchant needs to discontinue the purchase or ask for an alternative payment method. The below table lists the different response codes used and their use case.

​
Response codes

Please be aware that Visa and Mastercard impose a non-compliance fee on issuers if more than 5% of card-not-present transactions are declined with response code 05 (“Do Not Honor”). Therefore, generic response codes should be avoided when the specific reason for decline can be provided. From October 2025, Response code 57 must not be used by Visa issuers. Incorrect use of Response Code 57 will be reclassified to a generic decline response code (05).

​
Advanced spend control response codes

The following response codes are returned when a payment is declined due to a limit rule set up via advanced spend controls. (This service is sold separately.)

​
Response codes currently not in use

Some response codes from card schemes are defined but not widely used. These codes are often reserved for future scenarios or specific edge cases, and as such, they rarely appear in active transactions. Below is a table listing these response codes and their potential use cases.

​
Understanding Payment Declines and Response Descriptions

When a payment is declined, besides the response code, if available for the specific payment, there is also a response description that provides more context about why the transaction failed. This description includes a return code and a short explanation, and it can be accessed it via our transaction endpoint. In some cases, multiple issues might cause a decline. However, because only one response code can be sent to the card network and the payment terminal, our system must determine which reason to prioritize. This decision is made using a built-in prioritization logic.

​
Overview of Decline Reason Prioritization

Here’s a simplified overview of how these reasons are prioritized:
  1. Technical Issues
Problems with the card or account, such as:
  • Card/account is blocked or closed
  • Invalid CVV or expiration date
  • Wrong PIN
  • Token is disabled
  1. Business Rules
Payment restrictions based on usage rules, like:
  • Transactions blocked in specific countries
  • Spending limits (e.g., monthly cap)
  1. Fraud Detection
Transactions declined due to suspected fraud, such as:
  • Fallback declines
Example: How Prioritization Works In a payment attempt where two issues occur simultaneously:
  • The cardholder enters the wrong PIN (055 – Incorrect PIN)
  • The monthly spending limit is exceeded (061 – Usage Limit "MONTHLY_ALL" Amount Exceeded)
Although both problems are detected and logged by our system, only one decline reason can be returned externally. In this case, the incorrect PIN is prioritized because it falls under the “Technical Issues” category, which takes precedence over business rules. As a result:
  • The response description shown in the transaction endpoint will refer only to the wrong PIN.
  • The response code sent to the card scheme will also be 55, corresponding to the incorrect PIN.

​
Response descriptions

The most common descriptions are listed below:

​
Stand-in Processing (STIP)

Stand-in processing is a card scheme service that responds to authorisation requests on behalf of the issuer. STIP is used when the issuer (or issuer processor) is not available to respond to the authorisation request. STIP responds only when the issuer does not respond, is unavailable, cannot be reached, or when it provides an invalid response. The STIP parameters and limits are defined in the card scheme and they determine which authorisations can be approved even when the issuer is unavailable. The available parameters and limits differ depending on the product type (credit/debit/prepaid). If a BIN sponsor is used, the BIN sponsor will define the limits for STIP. The card scheme sends advice messages to inform the issuer of the authorisations that they have processed (both approved and declined) during the unavailability period. Enfuce processes and captures these advice messages after connections are re-established and adjust the available balances accordingly. In the scope of authorisation control and authorisation notifications, the STIP advice messages are treated like authorisation requests and will trigger webhook messages to the issuer.

​
Authorisation notifications

A notification can be triggered by Enfuce for each authorisation after the processing has been completed. The notification provides a real-time message that a transaction has been completed (or attempted) with the card. The notification can be used to confirm a successful/declined authorisation to the customer. The notifications are not queued and cannot therefore be re-generated if missed. See our API documentation for more information on the content of each notification message.

​
Authentication

​
Requirements for authentication

There are two main drivers for authentication during the transaction flow:
  1. EU Revised Directive on Payment Services (PSD2)
  2. Card scheme requirement to authenticate
Both are mandated in order to reduce fraud and retain trust in the payment system. By complying with the PSD2 regulation, you will also comply with the card scheme requirements which makes it natural to use the EU regulation as a base. Below we describe the authentication requirements and methods. Please see the authorisation page for a description of how Enfuce validates that an authentication has been performed. To meet these requirements, Enfuce has implemented a solution for card scheme transactions that will:
  • Decline authorisations originating from the EEA area that have not been verified by SCA and to which the exemptions do not apply.
  • Approve authorisations originating from the EEA area that have not been verified by SCA but to which exemptions apply.
  • Not require 3DS authentication for e-commerce transaction that have been flagged by merchants as exempt or are low value purchases.
Note:
  • The acquirer country defines whether the transaction is performed within EEA. The merchant country can be different from the acquirer country. If the acquirer country is outside EEA, then the SCA mandate does not apply.
  • For API-triggered transactions, the issuer is responsible for meeting the SCA requirements. Enfuce will not perform any validation and assumes that required authentications are performed.

​
Strong Customer Authentication (SCA) exemptions

SCA exemptions are defined based on the level of risk, amount, recurrence and the payment channel used for the execution of the payment. These exemptions aim to achieve the right balance between convenience of the payment experience and fraud reduction.
  • Contactless transactions with a low value
  • Unattended transport and parking terminals
    • Merchant category codes to whom this applies:
      • 4111 (Transportation – Suburban and Local commuter passenger, incl ferries)
      • 4112 (Passenger railways)
      • 4131 (Bus lines)
      • 4784 (Bridge and Road Fees, Tolls)
      • 4789 (Transportation Services)
      • 7523 (Automobile parking lots and garages)
  • Trusted beneficiaries
    • Your customer can whitelist merchants they trust.
    • Enfuce does not currently support this.
  • Recurring transactions
    • This has to be marked as recurring by the merchant and a trace ID is present to ensure that first transaction has been authenticated
  • Merchant-initiated transaction
    • For merchant-initiated transactions, SCA will be required for the first payment. So long as the subsequent payments are initiated by the merchant, further SCA will not be required so long as the amounts being charged are within the reasonable expectation of the end customer.
  • Low fraud – Transaction Risk Analysis
    • If the payment service provider’s (acquirer or issuer) fraud rates are below set thresholds, this exemption can be evoked. The party that evokes the exemption also assumes the risk of not authenticating.
    • Can be overruled by the other party, i.e., the acquirer may apply the exemption, but the card issuer can overrule.
  • Low-value payment (acquirer or issuer)
    • Enfuce has set up an issuer low-value limit of 30€ (or equivalent amount) for e-com transaction
    • Can be overruled by the other party, i.e. the acquirer may apply the exemption, but the card issuer may overrule.
  • Mail order or telephone order transactions
  • Secure corporate payments
    • Under the SCA-RTS Article 17, PSPs are allowed not to apply SCA for payments made by payers who are both legal persons and not consumers. This is only the case where the payments are initiated electronically through dedicated payment processes or protocols that are not available to consumers. This is subject to the view of local regulators.
    • Card payments done with corporate cards through the global card schemes do not fall under the exemption.

​
Authentication at a physical location

There are multiple ways to perform an authentication if the purchase is completed at a physical location.
  • Chip & PIN: If the customer uses a physical card at the point of sale, the authentication is performed with the chip card (possession) and PIN (knowledge). It should be noted that magnetic stripe is not considered safe enough according to today’s regulations (i.e., it’s not proof of something you have) because they are so easy to copy. The same applies to signatures.
  • Digital wallets: Digital wallets require the customer to authenticate before the purchase by opening the digital wallet. The tokenised card in the wallet (possession) becomes available with a security code (knowledge) or a biometric identifier like fingerprint or facial recognition (inherence).
  • Biometric cards: If a customer has a biometric card (possession), the authentication is done through a fingerprint sensor right on the card body (inherence).

​
Exemptions from authentication at a physical location

The merchant is responsible for determining if authentication is required for a specific transaction based on local regulations and card scheme rules. If the merchant does not authenticate, the liability of potential fraud can shift and the merchant risks that the issuer declines the authorisation, as it has not been authenticated. The issuer is required to comply with the same rules as the merchants and if, e.g., an exemption applies to the transaction, the issuer should not decline due to missing authentication. Enfuce checks during the authorisation process if authentication is performed as expected.