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.
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 |
| Change PIN at ATM | Change PIN request from an ATM | CHANGE_PIN | 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.
| ee | 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 |
| Paper invoice fee | This fee will be charged monthly if the invoice delivery is selected to be by paper (charge card product only) | PI | PI-P / PI-R |
| Revolving interest | Revolving interest is posted by the system at the end of the billing cycle (credit product). Reimbursements should be posted with the transaction type IR. | ILR3 | ILR3-P |
| Overdue interest | Overdue interest is posted by the system at the end of the billing cycle (credit and charge card product). Reimbursements should be posted with the transaction type OR. | ILR6 | ILR6-R |