Fee Calculation for Payment Environments


Transaction Fees

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.


Transaction Fees

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.

 

Customer:

 

Fees Charged Every (Period):

Year / Month / Week / Day

Fee Currency:

USD / GBP / AUD / CAD

Rounding:

Round Up / Down / To Nearest <Denomination> Overall / Per Transaction

Minimum Period Fee:

 

Maximum Period Fee:

 

Period Fee:

 

Fee Per Entity In Period:

<Amount> per Terminal / ATM / Merchant that's Configured / Does A Transaction /

Per Transaction Fee

 

Authorization

Clearing

Authorization And Clearing

Reversal

Refund

Network Fee

Any Message

Minimum Amount

Maximum Amount

First X transactions

 

 

 

 

 

 

 

 

 

Between X and Y transactions

 

 

 

 

 

 

 

 

 

More than Y transactions

 

 

 

 

 

 

 

 

 

Sent to Acquirer X

 

 

 

 

 

 

 

 

 

Sent to Acquirer Y

 

 

 

 

 

 

 

 

 

When transaction value below A

 

 

 

 

 

 

 

 

 

When transaction value between A and B

 

 

 

 

 

 

 

 

 

When transaction value above B

 

 

 

 

 

 

 

 

 

Example Fee Table

Below is an example of a fee table:

Customer:

EFTLab PTY

Fees Charged Every (Period):

Month

Fee Currency:

Pounds Sterling

Rounding:

Round Up In Pence Per Transaction

Minimum Period Fee:

£1000

Maximum Period Fee:

£20,000

Period Fee:

£500

Fee Per Entity In Period:

N/A

Per Transaction Fee

 

Authorization

Clearing

Authorization And Clearing

Reversal

Refund

Network Fee

Any Message

Minimum Amount

Maximum Amount

First 1000 transactions

3%

2%

4%

Negate original fee

Negate original fee

Yes

 

£0.25

£1

Between 1001 and 5000 transactions

2%

0%

2%

Negate original fee

Negate original fee

Yes

 

£0.15

£1

More than 5000 transactions

1%

0%

1%

Negate original fee

Negate original fee

Yes

 

£0.10

£1

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!

 

 

 

BP-Tools

BP-Tools is a set of freeware applications for EFT testing, benchmarking and transaction service development.

See more...

Download...

Download Flyer...

BP-Sim

The Babylon Payments Simulator (BP-Sim) is a family of highly efficient regression and stress testing tools, designed for deployment in development and pre-production environments. BP-Sim allows users to perform an extensive range of tests across the chain of payment services.

See more...

Download Flyer...

BP-Processing

The Babylon Payments Processing Suite(BP-Processing) is a suite of EFTlab's products for realtime payment transaction processing and authorisation.

See more...