Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Card fee auditor series ~6 min read

A card fee auditor on AWS for a few dollars a month

The merchant services bill is about nine hundred pounds a month. It arrives as a fourteen-page PDF with roughly forty distinct fee types on it. It is coded to one nominal ledger line and approved by somebody who has never read past page two. Nobody in the business can tell you what percentage of turnover it represents.

A person inserting a credit card into a payment terminal held by another person
Photo by Clay Banks on Unsplash

Key takeaways

  • The effective rate is total fees over total turnover. Compute it, never quote it.
  • Interchange is not negotiable. The acquirer margin is. Separate them.
  • Downgrades have causes, and most causes are fixable at the terminal.
  • A blended quote hides which transactions are expensive. IC++ shows you.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: statement, transactions and contract joined into an effective rateThree boxes across the top sit outside the AWS account. On the left, The statement, monthly, fourteen pages, unread. In the middle, The transactions, from the till or the gateway. On the right, The contract, a rate and what it applies to. Each connects by an arrow to the AWS account container below, monthly, daily and once respectively. Inside the AWS account are three components in a row. On the left, Fees itemised: forty types, each with a basis. In the middle, Rate per sale: cost joined to the transaction. On the right, The three answers: effective rate, margin and downgrades. A note says the statement says what you were charged and the transactions say what you sold, almost nobody joins the two, and the join is the entire system.AWS ACCOUNTThe statementmonthly, fourteenpages, unreadThe transactionsfrom the till orthe gatewayThe contracta rate, and whatit applies toFees, itemisedforty types, eachwith a basisRate per salecost joined tothe transactionThe three answerseffective rate, margin,downgradesmonthlydailyonceThe statement says what you were charged. The transactions say what you sold. Almost nobody joins the two, and the join is the entire system.
Fig 1. Three things outside the account, three pieces inside it. The information all exists; it has never been put in the same place.
  • Compute
  • Security & identity
  • Analytics

Why nobody notices

A card fee is never large enough to query on its own. Eleven pence on a nine pound sale is beneath anybody’s threshold for an argument, and the aggregate of those elevenpences is the second or third largest controllable cost in a lot of retail businesses.

The statement is also genuinely hard to read, and not by accident. Fees appear as abbreviations, some are per transaction and some are percentages, some are charged monthly and some annually, and the total at the bottom reconciles to the bank without explaining itself. Reading it takes an afternoon, so it happens once, at the point of switching, and then never again.

What runs (the inside)

  • Fees, itemised. The statement broken into individual fees, each with what it was charged on. Part 2.
  • Rate per sale. Fees joined to the transactions that caused them, which is what makes an average meaningful. Part 3.
  • The three answers. The effective rate, the part of it your provider controls, and the transactions that cost more than they should. Parts 4 and 5.

One month, one account

One merchant account over one month, from turnover to downgradesA horizontal row of five boxes joined by arrows. Thirty-eight thousand nine hundred pounds taken across two thousand one hundred and forty card transactions. Eight hundred and ninety-nine pounds in fees across forty-one distinct fee types. An effective rate of 2.31 percent against 1.4 percent quoted. Of that, 0.79 percent is acquirer margin, the negotiable part. And one hundred and sixteen downgraded transactions costing seventy-one pounds, mostly keyed-in. A note says the third box is the number nobody has, and the fourth and fifth are the only two you can do anything about.ONE MONTH, ONE MERCHANT ACCOUNT£38,900 taken2,140 cardtransactions£899 in fees41 distinct feetypes2.31% effectiveagainst 1.4%quoted0.79% is marginthe negotiablepart116 downgrades£71, mostlykeyed-inThe third box is the number nobody has. The fourth and fifth are the only two you can do anything about.
Fig 2. The same system as one line. The effective rate is the diagnosis; the margin and the downgrades are the two things that respond to action.
  • Compute
  • Management
  • Analytics

In plain words

The contract is read once into a quoted rate and, crucially, a description of what that rate applies to. Almost every quote in this industry is a floor rather than an average: it is the price of a UK consumer debit card, inserted into a terminal, with the cardholder present. Every departure from that costs more.

Each month the statement is read into individual fees. There are usually between thirty and fifty, and each one is tagged with what it was charged on — a count of transactions, a percentage of value, or a flat monthly amount — and with which of three categories it belongs to.

Those three categories are the whole point. Interchange goes to the bank that issued the customer’s card and is set by Visa and Mastercard; it is identical whoever processes your payments. Scheme fees go to Visa and Mastercard themselves. The acquirer margin is what your provider keeps, and it is the only part anybody can negotiate.

Then the transaction export is joined to the fees, which turns a monthly average into a cost per sale, and makes it possible to say that the eleven percent of transactions taken over the phone are carrying twenty-six percent of the fees.

Design rules that shaped every decision

  • The effective rate is computed from totals, never quoted from a contract.
  • Interchange, scheme fees and acquirer margin are separated before anything is compared.
  • Authorisation fees on declined transactions count. They are real and they are invisible.
  • The card number is dropped at ingest. Card type and entry mode are what matter.
  • A fee the system cannot categorise is a question for a human, not a guess.
  • No rate is reported on a partial month.

What it does not do

It does not switch your provider, it does not talk to your acquirer, and it does not touch the payment flow — there is nothing in this system that could decline a sale. It reads two files and one contract and produces three numbers.

It also does not tell you that your provider is overcharging you. Quite often they are not, and the gap between the quoted rate and the effective rate is almost entirely interchange on a card mix nobody chose. Knowing that is worth as much as finding an overcharge, and it stops you switching to an identical deal.

The next four posts walk through each piece: how a statement becomes forty itemised fees, how the effective rate is actually computed, why some transactions cost four times what others do, and how to compare two providers without being lied to. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts