While Enfuce offers a fully managed authorisation process where transactions are declined and approved according to predefined spend controls, authorisation control allows you to take part in the decision process of each authorisation.

The authorisation control messages include all relevant transaction data:

  • Amount (in transaction currency and card currency)
  • Transaction type
  • Merchant and acquirer country
  • Merchant info (ID, city, name, merchant type)
  • Transaction conditions (how were card details captured, how was the cardholder verified, was the cardholder present, is it a recurring transaction, etc.)
  • Digital wallet specifics (which digital wallet or ecom token was used)

With the data, you can create highly sophisticated and tailored controls that can be used to offer your customers purpose-specific cards like travel cards that only work to buy airline tickets and pay for hotels. You can create customisable user experiences by allowing the cardholder to fully control how, when and for what the card can be used. In addition to the transaction-specific data, the authorisation message also contains account, customer, card and token identifiers that help you effortlessly identify who is doing the transaction and potentially link the cardholder to data from other databases like a CRM or scoring system further improving the decision making.

​
Key benefits of authorisation control

  • Have real-time control over which transactions are approved and which are declined.
  • Enrich your decision-making by combining transaction data with your own data.
  • Offer your customers cards with detail-level customised controls.
  • Enables real-time credit line issuance per transaction.

​
Authorisation process with authorisation control

Authorisation control introduces the issuer as an additional party to the authorisation process:

The validations done by Enfuce and yourself have many different possibilities and we will align on those during your implementation project. By default, when authorisation control is used, the technical validations are done by Enfuce, while business and fraud validations can be done either by Enfuce and/or yourself.

Enfuce will provide you with relevant transaction data and then you will set up rules on your side. By applying the incoming transaction data to the setup rules, you can make the decision if authorisation should be approved or declined.

(Note that the below example is merely for visualisation purposes, please refer to the API documentation for the full API call content. )

​
Detailed process description

  1. The cardholder uses card/card credentials at the merchant or in an online shop to make a purchase.
  2. The purchase is recorded in a payment terminal/system (POS).
  3. The merchant has an acquirer for processing its transactions. The acquirer forwards the authorisation request to the correct card scheme.
  4. The card scheme receives the authorisation request, and based on the BIN range, determines which issuer (processor) it should be forwarded to.
  5. The flow continues depending on whether Enfuce is available or not.
    1.  If the Enfuce system is available, the request is forwarded to Enfuce.
    2.  If Enfuce is not available, the card scheme will respond to the authorisation based on Stand In Processing (STIP) rules defined by you. If the card scheme responds based on STIP rules, the card scheme will send an advice message once Enfuce is available again, which Enfuce will then forward to you (“SCHEME_ADVICE”).
  6. Enfuce will run agreed validations (technical/business/fraud)
    1. If validations at Enfuce are successful, the authorisation control process will proceed with Issuer validation.
    2. If Enfuce validations are unsuccessful, the authorisation will be declined and a declined reason to the card scheme is sent. you can receive information about declined authorisations via the Notification webhook.
  7. The authorisation is forwarded to you for further validation. If the issuer system is available, Enfuce will send a request to the issuer system to make validations if authorisation should be approved or declined.
    1. After the issuer system has processed the authorisation, it is expected to send an “approved” or “declined” response to Enfuce. If the issuer validation is unsuccessful (”declined”), the authorisation will be declined and will proceed with generating a declined reason to the card scheme.
    2. If the issuer system is unavailable, Enfuce will proceed to generate the response to the card scheme. Depending on the criticality of the validations done by the issuer system, the authorisation can either be approved based solely on Enfuce validation or then declined if critical validations remain undone due to issuer unresponsiveness.
  8. Enfuce will orchestrate a response to the card scheme based on the different validation results (technical, business, fraud). If any of these have responded “declined”, the authorisation will be declined. No overriding is done. Simultaneously, the authorisation is recorded in the system and the available balance (if the balance resides at Enfuce) and the spend controls are updated.
  9. The card scheme will forward the authorisation via the acquirer to the merchant.
  10. If the authorisation is declined, the cardholder is not able to make the purchase.
  11. If the authorisation is approved, the merchant’s systems will generate a financial transaction of the purchase.
  12. The card scheme will collect the financial transactions from all acquirers and combine them into clearing files, which are sent 2-6 times per day (depending on the scheme and agreement with the Issuer) to the Enfuce system.
  13. Enfuce receives the clearing files, processes them and posts the transactions to the card accounts based on the card number (PAN).
  14. The data export transaction files are available to you via Enfuce file transfer (SFTP).

​
Guaranteed delivery of advice and adjustments

To ensure that you receive all relevant messages, we have a guaranteed delivery process. In case the issuer is unavailable:

  1. Enfuce will immediately retry to send the message after a failed call.
  2. Enfuce will retry every 10 minutes to send the message (for 24 hours) until it is successfully received by the issuer.

The guaranteed delivery applies to the following message categories:

  • REVERSAL_ADVICE
  • SCHEME_ADVICE
  • ADJUSTMENT
  • DECLINED_AUTH_ADVICE / APPROVED_AUTH_ADVICE (only for issuers who handle their own fraud management)

REQUEST messages are not in the scope of the guaranteed delivery as they require immediate action and they can’t be processed in retrospect, unlike the advice and adjustments.

​
Authorisation Control API

We have experts who have decades of experience in authorisations which is why we know how hard it is to master all variations, identify all relevant variables and how not to get tangled in the technical parts of authorisation logic but rather look at the business and user experience value. We have taken all our knowledge and experience and created an API that we would want to work with ourselves.

The card schemes still rely solely on ISO8583, a standard created decades ago that is far from the developer-friendly APIs we are all accustomed to today. We have translated this complicated format to an API that has complete and concise data and is easy to read and work with. This will allow developers that have none to limited experience in authorisations to quickly integrate and create business value without requiring substantial amounts of knowledge and experience.

The API has the following logical elements:

See Enfuce’s authorisation control API documentation for further details.

​
Issuer requirements

The authorisation process is key for card usage. If authorisation responses from Enfuce and the issuer fail, the customer will have a card that doesn’t do its job. Responses are also very time-sensitive. The longer the process takes, the longer the customer has to wait at the checkout.

Issuers are required to have high availability and high-performance systems:

  • A rules engine that will make decisions based on Enfuce-provided transaction data and issuer rules if authorisation should be approved or declined.
  • Uptime > 99% (24/7/365).
  • Response to Enfuce within 1 sec.
  • Capability to process multiple transactions per second during peak times.
Change PINAdvanced spend controls