Skip to content

Financial transaction

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.

Card scheme transactions

A financial transaction is generated by the merchant after a successful authorisation. Financial transactions are used to settle the debt between the merchant and the issuer. The parties in the financial transaction flow are the same as in the authorisation flow. The merchant generates a batch of transactions 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 issuer’s processor.

Card scheme transaction

The issuer will process the transactions and post them to the card accounts. In order to settle the debt, the issuer pays the needed funds to the card schemes that route the funds to the acquirer who in turns distributes them to the merchants.

Card scheme transaction processing at Enfuce

The card scheme transaction processing is a batch process that happens 0-6 times/day, depending on the card scheme. Visa sends files 1-2 times per day (depending on region) and Mastercard sends files 4-6 times per day (excluding Sundays). The card schemes have indicative schedules for the delivery but the exact times are unknown. As soon as the card scheme sends the file, Enfuce automatically starts processing the file. The processing includes:

  • Routing and posting each transaction to the correct card account
  • Posting transaction-related fees (when applicable)
  • Adjusting the available balance on the account

As soon as the processing is completed, all transactions will be visible through the Transaction API. Transactions will also be reflected in the Data export file the following day.

Card scheme transaction types

There are eight different transaction types from the card scheme:

Transaction type Description Code in API (original/reversal) Code Data Export Transaction file (original/reversal/adjustment)
Retail Retail transaction R1 R1-P / R1-R / R1-J
Credit 1. Purchase returns K1 K1-P / K1-R / K1-J
2. Original credit type transactions. A transaction that is crediting the cardholder’s card but there is no corresponding debiting amount.
Unique Purchase (Unique MCC)
– 4829 (Money Transfer)
– 6050 (Quasi Cash Financial Institution)
– 6051 (Quasi Cash–Merchant)
– 7801 (Internet Gambling)
– 7802 (Government Licensed Horse/Dog Racing)
– 7995 (Gambling Transactions)
U1 U1-P / U1-R / U1-J
Cardholder Payment Used in person to person money transfers – this is the crediting transaction, i.e. cardholder receives money. T0 T0-P / T0-R / T0-J
Cardholder Debit Used in person-to-person money transfers – this is the debiting transaction, i.e. cardholder sends money.
For Visa, it is called Account Founding. (Proc Code = 10).
For Mastercard, is called Funding Transaction (Proc Code = 00 (like Retail) but with specific MCC)
TA TA-P / TA-R / TA-J
ATM ATM withdrawal A1 A1-P / A1-R / A1-J
Cash Other type of cash withdrawal except ATM C1 C1-P / C1-R / C1-J
Retail with cashback Retail transaction with embedded cashback B1 B1-P / B1-R / B1-J
Balance Inquiry Balance inquiry from an ATM. BQ n/a

Transaction-based fees

Enfuce supports three different transaction-related fees that the issuer can choose to charge. If set up, these fees are posted automatically by the system at the same time as the financial transaction is posted.

Fee Description Code in API (original/reversal) Code Data Export Transaction file (original/reversal/adjustment)
Mark-up Mark-up is a fee that is charged when the transaction currency is not the same as the card currency, a type of currency exchange fee. The fee is defined as a percentage of the transaction amount. Mark-up can be calculated for the following transaction types: Retail, ATM, Cash, Unique, CH Debit, Retail with Cashback. Mark-up is not calculated for CH Payment or Credit transaction types as those are crediting in nature. MUP MUP
ATM fee ATM fee is a fee that is charged for each ATM transaction. The fee is a percentage and/or fixed fee. A1F A1F
Cash fee Cash fee is a fee that is charged for each Cash transaction. The fee is a percentage and/or fixed fee. C1F C1F

Dispute transactions

During the dispute process, there are transaction types that are used to reimburse and re-charge transactions to your customer.

Transaction type Description Direction Code in API Code Data Export Transaction file (original/reversal)
Retail Reimbursement Reimbursement is completed for the cardholder. It’s done as soon as the claim has been received and deemed valid. Each card scheme transaction type has a corresponding reimbursement transaction type. These transaction types are not used for any other type of reimbursement. Reimbursement is reversed if:
– The cardholder revokes their claim.
– If the cardholder is deemed responsible during the investigation.
– The merchant credits the purchase after the reimbursement has been posted.
Credit W1 W1-P / W1-R
Credit Reimbursement Debit W5 W5-P / W5-R
Unique Reimbursement Credit W4 W4-P / W4-R
Cardholder Payment Reimbursement Debit W0 W0-P / W0-R
Cardholder Debit Reimbursement Credit WC WC-P / WC-R
ATM Reimbursement Credit W3 W3-P / W3-R
Cash Reimbursement Credit W2 W2-P / W2-R
Retail with cashback Reimbursement Credit WD WD-P / WD-R
Write-off Used when the customer claim is deemed valid, but initiating a card scheme dispute case is not economical or there is no chargeback right according to scheme rules.
For example, disputes with low-value transactions where the chargeback costs more than the purchase amount to be reimbursed or if regulation like PSD2 deems the issuer responsible and there is no justification to request the merchant to reimburse.
Credit WO WO-P / WO-R

API-triggered transactions

In addition to transactions from card schemes, Enfuce also supports triggering predefined transactions via the API. The transaction types available via API are:

 

 

Transaction Description Code in API (original/reversal) Code Data Export Transaction file (original/reversal)
Top-Up The top-up transaction is used to pre-load balance to the account. The API will first trigger an authorisation and then a financial transaction. Spend controls can prevent posting. Reversing a top-up is not allowed via the API. Erroneous transactions should be fixed by posting a Refund positive balance transaction. TP TP-P / TP-R
Refund positive balance The Refund positive balance transaction can be used when balance is returned to the customer e.g. in cases when there is excess prepaid balance. The API will first trigger an authorisation and then a financial transaction. Transaction posting will be rejected if available balance is not sufficient. Reversal of Refund positive balance is not allowed via API, rather erroneous transactions should be fixed by posting a Top-up transaction. RE RE-P / RE-R
Payment to account This transaction is used for customer payments done to a credit card account. PT PT-P / PT-R
Account to account transfer Debit transaction, used as the first step while transferring money from account to account. Transaction is always authorised to check account status and availability. A2AD A2AD-P / A2AD-R
Account to account transfer Credit transaction, used as the second and the last step while transferring money from account to account. Transaction is always authorised to check account status and availability. A2AC A2AC-P / A2AC-R
Card to card transfer Debit transaction, used as the first step while transferring money from card to card. Transaction is always authorised to check card status and availability. C2CD C2CD-P / C2CD-R
Card to card transfer Credit transaction, used as the second and the last step while transferring money from card to card. Transaction is always authorised to check card status and availability. C2CC C2CC-P / C2CC-R
Lending debit Charging transaction type utilised in a lending setup where the customer is charged for a witdrawn loan. Transaction is always authorised to check card status and availability. CLD CLD-P
Lending credit Refunding transaction type utilised in a lending setup when a loan is revoked. Transaction is always authorised to check card status and availability. CLC CLC-P

 

Fee Description Code in API (original/reversal) Code Data Export Transaction file (original/reversal)
Account Fees Enfuce offers 5 separate Account level fees that the issuer can freely use:
– Account Fee 1
– Account Fee 2
– Account Fee 3
– Account Fee 4
– Account Fee 5Fees are not authorised and will be posted even if there is no available balance.
AF1
AF2
AF3
AF4
AF5
AF1-P / AF1-R
AF2-P / AF2-R
AF3-P / AF3-R
AF4-P / AF4-R
AF5-P / AF5-R
Card Fees Enfuce offers 5 separate Card level fees that the issuer can freely use:

– Card Fee 1 (“CF1”)
– Card Fee 2 (“CF2”)
– Card Fee 3 (“CF3”)
– Card Fee 4 (“CF4”)
– Card Fee 5 (“CF5”)
Fees are not authorised and will be posted even if there is no available balance.

CF1
CF2
CF3
CF4
CF5
CF1-P / CF1-R
CF2-P / CF2-R
CF3-P / CF3-R
CF4-P / CF4-R
CF5-P / CF5-R
Reimburse account fee Crediting transaction that can be used to reimburse account fees. AR AR-P / AR-R
Reimburse card fee Crediting transaction that can be used to reimburse card fees. RR RR-P / RR-R
Reimburse revolving interest Crediting transaction that can be used to reimburse revolving interest (credit products only). IR IR-P / IR-R
Reimburse overdue interest Crediting transaction that can be used to reimburse overdue interest (credit products only) . OR OR-P / OR-R

 

API-triggered transactions are posted immediately to the account/card and will impact the balance of the account by default. Transactions will also be reflected in the data export file the following day.

Event-triggered fees

Event-triggered fees are fees that are automatically triggered when a predefined event is triggered.

 

Fee Description Code in API (original/reversal) Code Data Export Transaction file (original/reversal)
Fee for card lost This optional fee can be automatically triggered when card is replaced due to it being lost (API: Update card → REPLACE_CARD) M7 / m7 M7-P / M7-R
Reminder 1 Reminder 1 fee is triggered when reminder 1 is sent. You can define the amount of the fee during your implementation project. See the reminder and collection guide for further details on the reminder logic. REM1 / rem1 REM1-P / REM1-R
Reminder 2 Reminder 2 fee is triggered when reminder 2 is sent. You can define the amount of the fee during your implementation project. See the reminder and collection guide for further details on the reminder logic. REM2 / rem2 REM2-P / REM2-R