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.
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:
- Technical validation
- Business validation
- 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
| 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. |
| 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.
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
| Response code | Description | Use case |
|---|---|---|
| 0 | Approved | Approved response code. This is used when authorisation is approved (full amount). |
| 3 | Invalid Merchant | Decline response code. Used to indicate that the purchases at this merchant/merchant category is not allowed. |
| 4 | Pick up card | Decline response code. This is used when authorisation is declined because the card has been closed due to fraud. |
| 5 | Do not honor | Decline response code. This is a generic decline code that does not specify why it is declined. Should be noted that card schemes expect that more descriptive response codes are used whenever possible. |
| 10 | Approved for partial amount | Approved response code. This response code is used to indicate partial approval. Can only be used if the merchant has indicated in the request that they will accept a partial approval. |
| 12 | Invalid Transaction | Decline response code. This response code is used when missing or incorrect data in the authorisation message is preventing the processing of the authorisation. Examples can be missing security values or non-existing currency codes. |
| 13 | Invalid Amount | Decline response code. This response code is used when the amount of the transaction is not acceptable. Example use cases include if the reversal amount does not match the original authorisation amount or adjustment is bigger than the original authorisation amount. |
| 14 | Invalid card number | Decline response code. This response code is used when the card number from the merchant does not exist and the transaction is declined due to that. This can happen if the cardholder makes a typo when buying online or if there is fraudulent attempt to guess valid card numbers (‘BIN attack’) |
| 30 | Format error | Decline response code. This response code is used when the authorisation message does not comply with the format requirements of the card scheme. |
| 41 | Lost card pick up | Decline response code. This is used when authorisation is declined because the card has been closed as lost. |
| 43 | Stolen card pick up | Decline response code. This is used when authorisation is declined because the card has been closed as stolen. |
| 51 | Not sufficient funds | Decline response code. This is used when authorisation is declined when there is not sufficient available balance on the card account. |
| 54 | Expired card | Decline response code. This is used when authorisation is declined due to that the card has expired. |
| 55 | PIN incorrect | Decline response code. This is used when the PIN entered by the cardholder is incorrect. |
| 57 | Transaction not allowed for cardholder | Decline response code. This is used to indicate that there are issuer or customer-set rules due to which the authorisation will be declined. |
| 58 | Transaction not allowed for merchant | Decline response code. This is used if the transaction type is not allowed for the card or is not known. |
| 59 | Suspected fraud | Decline response code. This is used when the transaction is flagged as fraud by the fraud validation process. |
| 61 | Exceeds withdrawal amount limit | Decline response code. This is used when the authorisation is declined due to a spend control. For example, if a customer has set a £100 ATM limit and tries to withdraw £120. |
| 62 | Restricted card | Decline response code. This is used e.g. in cases when a merchant has the card token saved (‘on file’) and tries to make a charge but the token is suspended. |
| 65 | Activity count limit exceeded | Decline response code. This is used when a spend control counter prevents usage. Example use cases include PSD2 contactless limiters and other spend controls where the number of transactions is set. |
| 75 | PIN tries exceeded | Decline response code. This is used when authorisation is declined because the customer has entered the wrong PIN too many times. |
| 81 | Foreign network error | Decline response code. This is solely used by the card scheme in advices to indicate that there has been an error in the network. |
| 82 | Time-out at issuer system / Bad CVV (VISA) | Decline response code. This is used by the card scheme during stand-in processing and CVV security value validation fails at the card scheme. |
| 86 | Cannot verify PIN | Decline response code. This is used by the card scheme during stand-in processing when PIN validation fails or can’t be done at the card scheme. |
| 91 | Issuer unavailable | Decline response code. This is used between card management and the external ledger system, when a response from the external system has taken too long and the issuer is deemed unavailable. |
| 94 | Duplicate transaction | Decline response code. This is used when a merchant re-sends an authorisation that has already been processed and is ignored. This can happen if a response message from Enfuce is lost when sent to the scheme/acquirer/merchant. |
| 95 | No authorisation to match | Decline response code. This is used in cases where it is required that the authorisation message be matched to a previous authorisation message. This is required e.g. when processing a reversal of a previously processed authorisation. If the original authorisation is not found, it can’t be reversed. |
| 96 | System malfunction | Decline response code. This is used when there is a system malfunction. This can indicate that technical validation couldn’t be done at Enfuce or it has taken too long (card scheme response time limits are exceeded). |
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:
- EU Revised Directive on Payment Services (PSD2)
- 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)
- Merchant category codes to whom this applies:
- 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.