#topbar-cta-button span {
  background-color: #ffdc10;
  color: #121132;
}

#content-area p > a,
#content-area li > a {
  color: #8937ef;
  font-weight: 400;
  border-bottom: 1px solid #8937ef;
}

#content-area a:has(.icon) {
  border-bottom: none;
  color: #121132;
}

th.top {
  vertical-align: top;
}

/*
Needs more effort to work properly.
Does not work nicely with changing theme via button.

#navbar a:nth-of-type(1) {
    color: #121132;

@media (prefers-color-scheme: dark) {
    #navbar a:nth-of-type(1) {
        color: #FFFFFF;
    }
}
*/


Platform

Enfuce

Payment API

Release Notes

Contact

Sign in

This is not an endpoint. This is the description of a request that is sent to issuers' decision-making systems

Outgoing authorisation control webhook endpoint

Data of the account linked to the card with which the transaction is done with. Enables the issuer to identify to which account the authorisation is related to.


Unique ID of the account that is linked to the card that is used.

Available amount of the account that is linked to the card that is used.
This amount does not consider possible spend controls.
Note that this amount is only valid for setups where ledger is managed by Enfuce.
If ledger is held by issuer, the amount in this field will be zero (0).

The available amount is fetched mid-authorisation process.
As the end to end authorisation process takes 0,5-3 sec, there can occur situations where another authorisation, API transaction or financial transaction is processed in parallel which is not reflected in the available.
This is however extremely rare.

The amount provided in this field can have a minus sign if the account is overlimit.


Response to the authorisation. Indicates to the merchant if the authorisation was approved or declined.


Data of the card with which the transaction is done with. Enables the issuer to identify to which card the authorisation is related to.


Describes how the card credentials were captured. Possible values:
  * `UNKNOWN` - the message from the merchant did not include a distinct method.
  * `MANUAL_ENTRY` - the card credentials were manually entered by the merchant.
  * `MAGNETIC_STRIPE_READ` - the magnetic stripe of the card was read by a terminal.
  * `CHIP_READ` - the EMV chip of the card was read by a terminal
  * `CONTACTLESS` - contactless transactions, i.e. the card credentials were read with near field communication (NFC) either from chip or digital wallet.
  * `ELECTRONIC_COMMERCE` - the cardholder entered the card credentials as an e-com merchant.


A valid ISO 3166-1 alpha-3 country code, except for QZZ (UNMIK in Kosovo) and ROM for Romania.

Data of the customer linked to the card with which the transaction is done with. Enables the issuer to identify to which customer the authorisation is related to.


Unique ID of the customer that is linked to the card that is used.

expiration

* `MARKUP_FEE` - fee for transactions done in non-domestic currency. * `ATM_FEE` - fee for ATM withdrawals. * `CASH_FEE` - fee for cash transactions. * `UNKNOWN` - is a fallback value that is not expected but in case present represents another transaction based fee not covered by the above options.


Merchant category code as per card scheme classification. Merchants classification is done based on the type of business or service they sell.


Merchant specific data including acquirer data, merchant data and merchant category.

The country of the merchants acquirer as a ISO-3166-1 alpha-3 country code. This can be used to identify if transaction is in scope of PSD2 regulation.


This code identifies the financial institution acting as the acquirer for the merchant.

This information can be used as one variable to match the authorisation message to purchase receipt data.

While merchantIds are not globally unique, they are expected to be unique per acquirer, so combining merchantId with acquirerId creates a unique identifier of a specific merchant.


The city where the transaction or withdrawal occurs.

The country where the transaction or withdrawal occurs as a ISO-3166-1 alpha-3 country code.

A code that uniquely identifies a particular card acceptor, i.e. a merchant or a bank.  This information can be used as one variable to match the authorisation message to purchase receipt data. While merchantIds are not globally unique, they are expected to be unique per acquirer, so combining merchantId with acquirerId creates a unique identifier of a specific merchant.


Merchant name as conveyed from the card scheme (max 25 characters long). For ATMs this can be a street address or bank branch number. For money transfer transactions there can be the sender name or other transaction related data.


Indicates if merchant will accept partial approval of amount.
E.g. at a fuel pump the initial authorisation might be a predefined flat amount to which the issuer can respond an available amount smaller than the actual authorisation request.

Note that this functionality is only available when card account balance resides at issuer.


The sub-merchant ID is used when merchant ID is not sufficient to identify the merchant.  When a merchant uses a payment facilitator, the payment facilitator´s merchant id is transmitted and the merchant can be identified by the sub-merchant ID.  This field is only required when merchant uses a payment facilitator.


A code that uniquely identifies a particular terminal at the merchant.

This information can be used as one variable to match the authorisation message to purchase receipt data.


Identifies the type of authorisation message:
  * `REQUEST` - requires a decision in the form of an approval or decline. The transaction type indicates if it is a crediting or debiting transaction.
  * `REVERSAL_ADVICE` - requires a previously done authorisation to be reversed either fully or partially. Does not require a response from the issuer. The linkId can be used to identify the original authorisation request to be reversed.  replacementAmount indicates relevant amounts for partial reversals.
  * `SCHEME_ADVICE` - authorisation has been processed and approved by the card scheme. Requires the issuer to block funds as per card scheme advice. Does not require a response from the issuer.
  * `ADJUSTMENT` - adjustment of the settlementAmount of a previously made authorisation. Mainly used by automated fuel dispensers and EV chargiong stations to adjust the amount after fueling/charging has ended. Issuer is expected to adjust the settlementAmount of the initial authorisation request, to the settlementAmount of the adjustment. Does not require a response from the issuer.
  * `DECLINED_AUTH_ADVICE` - this message category is only available for issuers that do fraud monitoring. It indicates that authorisation has been declined during a validation step at Enfuce. For issuers that do fraud monitoring themselves, these messages could e.g. be authorisation attempts with incorrect PAN (card number) which could indicate an ongoing BIN attack.
  * `APPROVED_AUTH_ADVICE` - this message category is only available for issuers that do fraud monitoring. It indicates that authorisation has been approved. For issuers that do fraud monitoring themselves, these messages might be interesting.


Response to the authorisation.
Indicates to the merchant if the authorisation was approved or declined.
Issuer can use the following response codes:
  * `00` - Approved
  * `05` - Do not honor (**Note**: Card schemes recommend to use this only when other options do not apply)
  * `10` - Approved for partial amount (can only be used if `partialApprovalCapable` is `true` and ledger resides at issuer). Requires that issuer includes the `partialApprovalAmount`
  * `51` - Not sufficient funds
  * `57` - Transaction not permitted to cardholder
  * `61` - Exceeds approval amount limit
  * `62` - Restricted card (card invalid in region or country)
  * `65` - Exceeds withdrawal frequency limit
  * `91` - Issuer unresponsive


Used when issuer does a partial approval. When the available balance is not sufficient considering the transaction amount, the issuer is expected to block whatever available balance there is and return the amount that can be authorised in the `partialApprovalAmount` field. Can only be used when `partialApprovalCapable` is `true` , i.e. the merchant approves that a smaller amount than the full transaction amount is authorised.


Data of the token with which the transaction is done with. Enables the issuer to identify if a token was used and what kind.


Used to convey information about the kind of device that has been used for the transaction. For instance: Phone, watch, tablet, wearable.


Indicates which of the mobile digital wallet has been used. `UNKNOWN` can indicate that the card is tokenised at a merchant or another wallet.


Indicates which digital wallet has been used or if it is an ecom token.

Transaction specific data including amounts and fees, transaction type as well as information about the purchase conditions.

Issuer generated code (6-digits) that is returned to the merchant if authorisation is approved.
Commonly used as the one of the main variables, in addition to cardId, to uniquely identify a transaction.

This information can be used as one variable to match the authorisation message to purchase receipt data.


Response to the authorisation. Indicates to the merchant if the authorisation was approved or declined


Some merchants are allowed to request for a longer authorisation validity period than the default 7 days.
When merchant has requested a longer validity period, this field indicates the amount of days the authorisation should be considered valid.

This field is not present if no deviation from default has been requested.


Indicates if cardholder has been physically present during transaction.

Describes what method was used to verify the cardholder. The verification methods are limited to verification methods that are considered as valid verification methods according to strong customer authentication principles. 
Possible values:
* `WALLET` - cardholder has been verified with the digital wallet device. 
* `PIN` - cardholder has entered the correct PIN of the card to the payment terminal.
* `BIO` - cardholder has successfully been verified through a biometric method (e.g. fingerprint reader on card).
* `THREE_DS` - cardholder has successfully been verified through 3DS.


Indicates that transaction is recurring or merchant initiated.  This implies that the cardholder has approved that the merchant initiates the transaction on a regular or frequent basis.


The amount **(in the settlement currency)** that the authorisation should be adjusted to in case a merchant makes a reversal.  If a merchant makes a full reversal this field can be either missing or have a value of zero.  If a merchant makes a partial reversal, this should be considered the actual amount that should be blocked.  When a value is provided in this field, it is always positive.


Merchant/acquiring generated reference number for a purchase.
Commonly used as the one of the main variables, in addition to cardId, to uniquely identify a transaction.
Reference number is expected to remain the same for all messages during the transaction lifecycle (authorisation, clearing, reversals).

This information can be used as one variable to match the authorisation message to purchase receipt data.


Transaction amount converted to card account currency (excluding mark-up). The value provided in the amount field is always non-negative.


Transaction amount in the original transaction currency. The value provided in the amount field is always non-negative.


The local date (and time) when the transaction was made. I.e. the date/time in the time zone in which the payment terminal/merchant is. In date-time format YYYY-MM-DDThh:mm:ss. Please note that the authorisation formats used by card schemes do not support conveying the time zone in which the transaction has been done. The card scheme may also just include the date and no specific time. Enfuce relays the date and time as received from the card scheme.


Transaction based fees that are additional fees charged on top of the transaction.
Standard options are `MARKUP_FEE` for transactions done in non-domestic currency, `ATM_FEE` for ATM withdrawals and `CASH_FEE` for cash transactions.
Fees are always presented with positive values in the amount field.

`UNKNOWN` is a fallback value that is not expected but in case present represents another transaction based fee not covered by the above options.


Get to know Enfuce's award-winning payments solution by catching up on all our documentation and guides. Welcome to the land of absolute transparency.

Enfuce Documentation

First of all, nice to meet you! Here’s a short introduction to get to know us better

Quick guide to Enfuce

Congratulations on taking the first step to building flexible, modern payment cards! You are probably eager to get going and start creating your card product.

Start developing with Enfuce

Enfuce License Services (ELS) is the licensed Enfuce group entity offering BIN sponsorship and card issuance in the EEA area under our EMI authorisation from the FIN-FSA, passported to the EEA.

BIN sponsorship

Enfuce offers several options for the interest calculation.

Revolving credit product – Interest accrual

Enfuce credit product has also an instalment feature, which can be separately configured.

Revolving credit product – Instalments

The Enfuce credit account product has several technical accounts that enable the segregation of balances. This, in turn, allows you to keep track of the age of overdue amounts and a variety of interest calculation models.

Revolving credit product – Segregation of balances

Enfuce provides the issuer invoice data (“statement”) on account level once per month. You can use the provided data for creating and sending invoices to your customers.

Revolving credit product – Invoicing process

Revolving credit product – Customer Payments

Revolving credit product – Reminder and collection process

Our customer portal, known also as MyEnfuce, gives you access to your cardholder information.

MyEnfuce customer portal – your access to cardholder data

Registration and login

All transactions have one common characteristic. They are designed to either increase or decrease the account balance. The term ‘transaction’ includes all transaction-related communication between the merchant, an issuing processor and the issuer.

Introduction to transactions

Transaction conditions describe the particular conditions in which a card transaction was made, for example, was the chip read or was it contactless, how was the cardholder authenticated and was it e-commerce or a card present transaction.

Transaction conditions

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.

Authorisation and authentication of payments

Discounts enable issuers to offer discounts for single transactions or linked line items. You can offer your customers a rewards program with transaction-specific cash backs and discounts – making your payment product highly attractive to a range of end users. You have full control over how much discount each customer gets and for which transactions.

Discounts

A financial transaction is defined as a transaction that either increases or decreases the account balance. This section will describe both card scheme transactions that are posted when cards are used at merchants and API triggered transactions that can be posted via Enfuce APIs.

Financial transaction

There may be situations when you need to be able to link authorisations or notifications of authorisations with financial transactions. For example, some issuers send a notification to their customer after an authorisation, requesting the customer to take an action based on it (like take a picture of the receipt or assign it to a cost category).

Linking authorisation with transaction

This API allows you to do peer-to-peer transfers between accounts and cards residing in Enfuce.

Transfer API

This solution enables enriching transactional data with, for example, receipt line items, quantity of items or travel details. While normal card transactions have a lot of information, it lacks detailed data about what was bought.

Purchase details

A card serves as the actual payment instrument. Cards can take many forms: They can be plastic, virtual or tokenised elements that work though a variety of devices, like smart watches, mobile phones and rings. 

Card

Disposable cards can have many use cases for private and corporate customers.

Disposable card – time-based closing

A card as a payment instrument can take many forms nowadays, virtual, tokenised, and physical one. A modern issuer needs to be able to support these multiple representations of cards, as well as manage the varying preferences of their end users.

Digital card – creating the omnichannel payment card experience

A customer is the entity to which a card and/or an account is issued to. A customer can be a private person, a corporate customer, or even an item, like a vehicle.

Customer

The All-in-One card combines multiple card applications (PANs) into one physical card.

All-in-One card

The account entity’s main functionality is to hold the balance. It also functions as the link in case several cards share the same balance. For credit products, the account also represents the invoice level from which invoices are generated.

Account

Depending on your needs and the agreed setup between Enfuce and yourself, there are different types of account products.

Account product types

Account hierarchies allow you to create a hierarchical structure of your corporate customer accounts.

Account hierarchy

Balance types are used to improve the financial information that is provided in the data export files.

Balance types

A great cardholder experience is at the centre of what Enfuce does. This includes giving cardholders the ability to manage their cards themselves.

Introduction to our APIs

The Enfuce data approach is based on a generic solution that is designed to fit different types of payment products (credit, debit, consumer, corporate, fleet cards, etc.).

Enfuce interfaces and data sharing

‘View card data’ allows the cardholder to safely and conveniently access the data required for making an e-commerce purchase, without having access to a digital wallet or a physical card.

View card data

The ‘view PIN’ functionality allows your customer to safely and conveniently access their card’s PIN via a mobile or web app when needed.

View PIN

Set PIN allows the customer to choose the PIN (Personal Identification Number) of the card. This can be done safely and conveniently through mobile or web app.

Allowing the cardholder to choose a PIN of their choice improves the end-user experience as it reduces the burden of remembering multiple PINs and decreases the amount of failed transactions as well as requests for resetting the PIN attempts.

Change PIN

Authorisation control gives you the flexibility to create sophisticated rules for approving and declining transactions in real time.

Authorisation control

Have full control over where your cards can be used, in what way, how much, and when.

Advanced spend controls

Enfuce supports a range of spend controls that are used to provide the customer with the possibility to control the use of the card and improve trust and a sense of safety.

Spend controls

Data export files are a set of files which are exported from the Enfuce data warehouse for the issuer.

Enfuce data export files

Token file description

Account file description

Customer file descriptions

Card file description

Transaction file description

Lead the charge towards a sustainable future. Transform your digital banking services with cutting-edge carbon data and engaging experiences with Deedster.

Carbon footprint tracking: Enfuce x Deedster

To comply with EU Cross Border Payment regulation (EU 2021/1230) and to enable improved end user experience, Enfuce provides a solution to disclose to the end user the exchange rates used for card payments.

Cross-border payment regulation (CBPR)

The EU Payment Service Directive includes multiple requirements that have to be considered by payment issuers.

Payment Service Directive (PSD)

We develop and maintain all our services keeping in mind best practices for security and data protection.

The European Union’s General Data Protection Regulation (Regulation (EU) 2016/679) regulates the processing of personal data, which applies to financial data processed by Issuers of payment instruments.

Privacy and data protection

Transaction-specific strong customer authentication (SCA) data

3-D Secure is designed to increase consumer confidence in online payments by providing additional authentication of the customer during the purchase process.

3DS – authentication of online payments

The card schemes’ address verification service allows card-not-present merchants to check the cardholder’s billing address with the card issuer to increase security and protect against fraud.

Address verification service

Dispute management includes the initiation and management of your customers’ payment disputes.

Dispute management

Managing fraud is essential in ensuring continuous customer trust in any payment solution.

Fraud prevention

We value collaboration with several trusted partners from both commercial and product perspectives.

Partnerships

Enfuce offers comprehensive support throughout your lifecycle as a customer.

Customer success

Enfuce’s MyApp is a ready-to-launch mobile application (app) that lets you launch your card products with a branded card management app without binding internal development resources.

MyApp – Cardholder app

If you wish to issue physical cards with your own design, it usually takes months with time-consuming steps like:"

MyCard – Embedded card bureau

Here you'll find documentation about Payment API.

Overview

Endpoint for doing various actions connected to a account

Account Details

Create an account

This operation will create a credit account

Create credit account

This operation will create a debit account

Create debit account

This operation will create a prepaid account

Create prepaid account

This operation will create a fleet account

Create fleet account

This operation will create a multicurrency account

Create a multi-currency account

Create account

This operation will update given fields given an account id

Update a credit account

This operation will update given reminder data fields given an account id

Update a credit account reminder data

Update a debit account

Update a prepaid account

Update a fleet account

Update a multicurrency account

Update an account

Basic operation for updating an account. Check parameter updateProperty for possible parameters to update

Update account

Get account information

This operation will respond with an account given account id

Get account

This operation will respond with an account given account number

Get account by accountNumber

This operation will respond with a list of accounts given the customer id

Get accounts given customerId

This operation will respond with a list of accounts given the account id

Get accounts lower in the hierarchy

Authorisation control gives the issuer the flexibility to create sophisticated rules for approving and declining transactions in real time.

Authorisation Control

Authorisation Control Webhook

Authorisation Forwarding

Forward authorisation webhook

This is not an endpoint. This is the description of request the which is being sent to customers decision making system if provided

Request which is being send to customers decision making systems

Card API have different endpoints for creating, editing and updating a card via different methods.

Payment API

Account Details

Authorisation Control

Authorisation Forwarding

Card details

Customer

Exchange Rates API

ID

Instalment

Invoice

Notification

PIN

PIN Control

Purchase Details

RBA Forwarding

Repricing

Transaction

Transfer API

Wallet

Test API

Hierarchy API

Spend Control API

Outgoing authorisation control webhook endpoint

Body

Response