Skip to content

Authorisation and authentication of payments

Authorisation

An authorisation refers to the merchant obtaining approval or denial of a card transaction from the issuer. The authorisation process starts when a customer makes a purchase. 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.

This illustration demonstrates the authorisation process

After the issuer has processed the authorisation request, the response is sent back the same way:

This illustration demonstrates the response after authorisation request

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.

This illustration demonstrates the 3 steps of authorisation

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

 

Data Description
PAN The following validations are done based on the PAN:
Is the PAN an existing PAN within the system? If the PAN is non-existing, the authorisation will be declined.
Luhn algorithm – does the check digit match with the rest of the PAN?
Expiry date The system will check that the expiry date matches with the expiry date in Enfuce system

 

‘Card present’ data element validation

 

Data Description
iCVV validation (cvc/cvv on chip) Validation of the iCVV. If verification fails the authorisation request is declined.
The purpose of the Integrated Chip Verification Value is to protect against the copying of the magnetic stripe data from the chip for creation of a counterfeit magnetic stripe card. The iCVV on the magnetic stripe data contained in the chip is different from the CVV1 value on the physical magnetic stripe.
Cryptogram validation (ARQC) Validation of the Authorisation Request Cryptogram to check that the EMV chip has not been tampered with. If validation fails, the authorisation request is declined.
Track 1 data validation (magnetic stripe transactions) Validate if track 1 data is included in the transaction if the Service Code indicates that data must be present.
Validate that the CVV1/CVC1 of track 1 is correct.
Track 2 data validation (magnetic stripe transactions) Validate that CVV1/CVC1 on track 2 of the magnetic stripe is correct.
Terminal verification result (TVR) The issuer rules for Terminal Action Analysis are known as Issuer Action Codes (IACs). System will analyse the Issuer Action codes to check if the performed offline data authentication has failed.
Card verification result (CVR) Validation of the Card Verification Result that resides in the EMV data
PIN Verification Service PIN validation done by comparing against stored & encrypted value.
(PVV might be used in some cases)
Card Sequence number Validation of card sequence number. Note that previous sequence numbers can be used if card status allows it but not non-existing ones.

 

‘Card not present’ data element validation

 

Data Description
CVV2/CVC2 validation Security code validation when using card in e-commerce environment. The card schemes will perform pre-validation and Enfuce will repeat the validation.
3DS certificate validation (CAVV/AAV) Verify that the authentication result value in CAVV/AAV field of the authorisation message matches the 3DS authentication value. Decline if not equal.

 

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

Data Description
Account and card statuses Both the card and the account need to have the status ‘OK’ for the authorisation to be approved. Card status ‘Card no renewal’ is also considered OK. If the card or the account has any other status, the authorisation is declined. Also, a card can be blocked during delivery. Until the cardholder activates the card, authorisations are declined.

In case there are several reasons for rejecting the authorisation, Enfuce will prioritise the card status when generating the response code: For example, if the customer enters the wrong PIN and has a blocked card, the response will be given based on the blocked card.
See card and account sections for statuses.

Advanced spend controls Spend controls will decline authorisations based on the rules set up per spend control. See the advanced spend controls section for more details.
Online PIN tries Enfuce has an ‘Online PIN tries’ feature that will restrict the number of online PIN tries.
Available balance Available balance needs to cover the settlement amount of the purchase plus fees and markup.
See the description of available balance for more details.

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.

See more on the fraud section of our guide.

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.

 

Category Description Example
Knowledge Something only the payer knows A password, PIN
Possession Something only the payer has A chip card, pre-registered mobile phone
Inherence Something the payer is Biometric factors (facial recognition, fingerprint, voice recognition)

 

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.