Fee Calculation for Payment Environments

This article has been written to provide a brief introduction to fee calculation, the impact on transaction processing and of settlement handling. Often we work in environments where salesmen do not have access to developers (or do not understand the technicalities when they do); this typically means Sales will commit to delivering to a merchant a solution with a specific fees structure, the technical pre-sales will agree and the system architect will do their best to sort it out with the development team.

Ultimately in computing everything is possible given enough time and money however it’s not often advisable to alter your system architecture every time a new customer is signed up, therefore having an agreed charging model between sales and development is essential. This article covers some common charging models and provides advice on templates to be used.

Common Fee Charging Structures

This section provides an introduction to the most common forms of fees the authors have seen in payments systems. It’s important to note that a set of fee configuration is typically applied per “entity” and that might be on both the source and destination (e.g. terminal and acquirer) and fees need to be summed per billable entity (e.g. set of merchants or set of terminals).

Per Transaction

Charge a fee for every transaction that is processed; this is normally divided into a compound fee of any of the following:

• Calculate the fee charged by the network (i.e. downstream entities) to ensure you don’t make a loss on the transaction.
• Calculate a percentage fee.
• Add a flat fee.
• If fee falls below a threshold then round up to a particular value.
• Make up to the lowest denomination of the fees currency from an agreed rounding algorithm.

It’s normally not quite that simple though, typically we see different thresholds based around:

• The value of the transaction.
• The number of transactions performed so far in the fee period (e.g. month).
• The type of transaction (e.g. reversals nullify a fee, refunds negate part of the original fee).

Also there may be the need to apply FX rates to generate the fee. There have often been later debates over what is a transaction therefore we have generally advised that a definition of a transaction is “a single request message either a balance inquiry, authorization, funds transfer, authorize+transfer or management request”.

Per Fee Period

One (or a combination) of the following fees is charged per period (e.g. month) regardless of the number of transactions performed:

• Flat fee.
• Number of source entities (e.g. terminals, ATMs).
• Sometimes only where it’s used in a period (again “used” implies definition such as “connects to the switch” or “sends a financial request to the switch”).
• Number of transactions.

These are often based around predicted volumes and the amount of estate in use.

Outside Costs

This article only considers fees directly related to financial transaction processing, it does not consider fees from chargebacks or support calls or other outside processes since although these incur a great deal of cost to the supplier typically these are billed for separately.

When To Calculate Fees

Fee structures can become highly complex and therefore it’s often advisable not to leave it until the end of the fees period to calculate them all; equally it’s not possible to calculate fees up-front always because the downstream entity fee may not be known or calculable. So typically it’s recommended that fees are calculated in three steps:

1. In an overnight run on the day the transaction is processed calculate any fees for transactions sent for clearing that day.
2. In an overnight run receiving fees for cleared transactions as part of reconciliation apply any clearing fees.
3. In the fees generation process run every fees period applying any period fees and adding up per transaction fees.

Example Template For Fee Structure

Below is an example template for fee calculation which provides the ability for a salesperson to apply a flexible enough template to meet the customer requirement without requiring an architecture change.

Example Fee Table

Below is an example of a fee table:

Summary

Two most common forms of transaction fees in a payment industry were described and table templates were provided to demonstrate fee structure.

We hope this article has shed a little light on this problematic and the processes that are involved; for more information these please contact our team, who is always keen to share its knowledge. Also please let us know what fee structure is being used in your environment as EFTlab is being build on knowledge sharing and all comments are welcomed!