Outgoing authorisation control webhook endpoint

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.

Unique ID of the card.

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

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.

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 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.

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.

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.

Unique id for authorisation message, but DECLINED_AUTH_ADVICE and APPROVED_AUTH_ADVICE has id of authorisation which they associated with but not unique.

The link ID is a number linking all messages connected to the same purchase (authorisation, financial transaction, reversal)

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.

Unique random-generated id per http message. Can be used by receiver to confirm that no messages has been processed twice.

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.

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.

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

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.

The transaction type.

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.

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.

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.

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.

Enfuce assigned unique id for token.

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.