Revolving credit product – Customer Payments
Incoming payments to a revolving credit account
Incoming payments will be credited to the account in the Enfuce system. These payments are the result of your customer paying their invoice or increasing their balance or available amount on the account.
Customer payment process in revolving credit
A customer payment refers to the process when an end user makes a payment transaction in order to pay off credit debt or a top-up for the account.
The usual process is that the end-user initiates the payment from their bank by making a bank transfer to the issuer’s bank account. The bank will generate an account statement for the accounts which the issuer will send to the Enfuce system. The bank transfer is then recorded in the system managing the credit account and the credit debt is decreased according to the payment amount.
Posting payments with Transaction API
The Transaction API allows you to post predefined account and card-level transactions, including customer payments. The customer payment transaction type is an account-level transaction and therefore the API call “Post transactions to given account” should be used.
The API requires the accountID into which the payment should be posted. The accountID is generated by Enfuce when the account is created and is sent to you in the account creation process.
In addition to the accountID, the transaction type, amount, and currency are required:
- The transaction type for customer payments is “PT”.
- The amount must be equal to the amount that the customer has paid to the issuer.
- The currency must match the currency the account is set up in. Currency conversion is not supported and transactions in any other currency will be declined.
Batch payments processing in a revolving credit product
Enfuce processes the account’s statement file and searches for the correct target account based on the reference number of each payment. Enfuce supports the processing of payment files received from the bank. The file format supported is camt.054.
Suspense account for a revolving credit product
If a payment cannot be posted to an end-user account, it will be posted to an institution suspense account for further processing by your team. This can happen if the payment reference number is incorrect or when there is a transaction received on a closed account. Transactions in the suspense account are controlled manually and moved to the correct end-user account when it has been found.
You can find transactions from the daily transactions files with the suspense account set as the target. You can also get the details for suspended transactions through the get transaction data API for suspended payments. Once the correct end-user account is known, you can post the payment through the update account API. This operation will reverse the transaction from the dispute account and post it to the correct customer account.
This feature is available only when using batch payment processing.
Incoming payment priorities in a revolving credit product
Enfuce has a predefined payment priority that determines the order in which to allocate payments. Balances with higher priority are paid before balances with lower priority. The priority is set based on regulatory requirements, for example, overdue debt is paid before debt that is not yet due. The payment priority is a product-level setup that is common for all accounts and cannot be changed via the API.
How payments are allocated in a revolving credit product:
- Overdue invoice balance, from the oldest overdue invoice to the newest.
- If the customer fails to pay the minimum-to-pay amount it is overdue.
- Open invoice balance, from the oldest open invoice to the newest
- Balance that has been invoiced but the first due date has not yet passed
- Current un-invoiced balance, if there are no open invoices payment will cover the un-invoiced balance
- Balance for which the invoice cycle has not closed. No invoice has yet been sent to the customer of debt accrued this cycle, no minimum to pay has been calculated and no due date is set.
- And finally, if there are no un-invoiced balance, the payment ends up as a positive balance on the account.
| Balance | Priority |
|---|---|
| Overdue balance – Overdue interest balance | 1 |
| Overdue balance – Revolving interest balance | 2 |
| Overdue balance – Fee balance | 3 |
| Overdue balance – Cash balance | 4 |
| Overdue balance – Retail balance | 5 |
| Invoiced, not yet due – Overdue interest balance (MTP*) | 6 |
| Invoiced, not yet due – Revolving interest balance (MTP*) | 7 |
| Credit balance – Fee balance (MTP*) | 8 |
| Credit balance – Cash balance (MTP*) | 9 |
| Credit balance – Retail balance (MTP*) | 10 |
| Invoiced, not yet due – Fee balance (MTP*) | 11 |
| Invoiced, not yet due – Retail balance (MTP*) | 12 |
| Invoiced, not yet due – Cash balance (MTP*) | 13 |
| Credit balance – Fee balance (not part of the MTP*) | 14 |
| Credit balance – Cash balance (not part of the MTP*) | 15 |
| Credit balance – Retail balance (not part of the MTP*) | 16 |
| Invoiced, not yet due – Fee balance (not part of the MTP*) | 17 |
| Invoiced, not yet due – Cash balance (not part of the MTP*) | 18 |
| Invoiced, not yet due – Retail balance (not part of the MTP*) | 19 |
| Current cycle – Fee balance | 20 |
| Current cycle – Cash balance | 21 |
| Current cycle – Retail balance | 22 |
- MTP = Minimum to Pay
An example of allocation of payment according to priority:
- A credit account has a total debt of £900
- How the balance is divided shows up in the ‘Balance’ column
- The customer makes a £500 payment
- How the payment is allocated is described in the ‘Payment £500’ column
- Credit account debt after payment
- Balance after payment is posted is described in the ‘Remaining balance’ column
| FIELD1 | Balance | Balance | Payment £500 | Remaining balance |
|---|---|---|---|---|
| 1 | Overdue balance – Overdue interest balance | 0 | 0 | |
| 2 | Overdue balance – Revolving interest balance | 0 | 0 | |
| 3 | Overdue balance – Fee balance | 0 | 0 | |
| 4 | Overdue balance – Cash balance | 100 | -100 | 0 |
| 5 | Overdue balance – Retail balance | 300 | -300 | 0 |
| 6 | Invoiced, not yet due – Overdue interest balance (MTP*) | 5 | -5 | 0 |
| 7 | Invoiced, not yet due – Revolving interest balance (MTP*) | 10 | -10 | 0 |
| 8 | Credit balance – Fee balance (MTP*) | 50 | -50 | 0 |
| 9 | Credit balance – Cash balance (MTP*) | 60 | -35 | 25 |
| 10 | Credit balance – Retail balance (MTP*) | 100 | 100 | |
| 11 | Invoiced, not yet due – Fee balance (MTP*) | 200 | 200 | |
| 12 | Invoiced, not yet due – Retail balance (MTP*) | 5 | 5 | |
| 13 | Invoiced, not yet due – Cash balance (MTP*) | 50 | 50 | |
| 14 | Credit balance – Fee balance (not part of the MTP*) | 20 | 20 |
In addition to the predefined payment priority, other priorities can be configured to meet local laws and regulatory requirements. For example, in the UK, the repayment must be allocated to the debt subject to the highest rate of interest (and then to the next highest rate of interest, and so on).
Compared to the standard, the common UK requirement can be met by switching around the fee and cash account priorities. On top of this, cash fees will be posted on the cash balances instead of fee balances.
Outgoing payments for a revolving credit product
Outgoing payments occur when you are giving your account holders their money back. A common reason for this type of payment is that the cardholder has overpaid an invoice, or gets a refund, for instance. To reflect the return of funds to the customer, you need to correct the positive balance in the credit account management system.
To support situations where the customer requests a refund, there is a separate transaction type that will debit the account. The outgoing payments from the end-user’s account are handled via Transaction API with transaction type “Refund positive balance”. This transaction decreases the available amount on the account immediately.
The process of posting such a transaction is identical to posting a customer payment except it is for a different transaction type.
The Transaction API allows you to post predefined account and card level transactions, including ‘Refund positive balance’. The customer payment transaction type is an account-level transaction and therefore the ‘Post transactions to given account’ needs to be used.
The API requires the accountId to which the payment should be posted. The accountId is generated by Enfuce when the account is created and has been sent to you in the account creation process.
In addition to the accountId, the transaction type, amount, and currency are required.
The transaction type for customer payments is “RE”.
- The amount must be equal to the amount that the customer has paid to the issuer.
- The currency must be the same as the account is set up. Currency conversion is not supported and transactions in any other currency will be declined.