Where an infrastructure bill actually ends up
Most engineering teams measure infrastructure in the units their cloud provider bills them in. Instances. Storage. Bandwidth. Then they look at utilisation, feel briefly guilty, and move on.
In a payments company, none of those numbers mean anything on their own. There is exactly one that does, and it is the one nobody puts on a dashboard:
Cost per transaction. It is the only infrastructure metric a merchant ever feels.
The logic is uncomfortable but simple. A payments company's infrastructure cost does not disappear into an operating expense line where nobody looks. It sits inside the rate the merchant pays. A processor that needs three times the compute to authorise the same card has to recover that money, and there is only one place it can come from. It comes from the merchant, in pricing — which means it ultimately comes out of the margin of an Indian exporter trying to compete on a shelf in London.
So when we optimise our cloud spend, we are not doing housekeeping. We are doing pricing.
Make the metric visible, or nothing changes
The first thing we did was not a technical change. It was to put cost per transaction on the same dashboard as latency and error rate, in front of the engineers making the decisions.
This sounds trivial. It is the highest-leverage thing on this list. An engineer who can see that a change doubled the cost of authorising a payment will not ship that change. An engineer who cannot see it has no reason not to. Cost, when it is invisible, is nobody's job — and it quietly becomes everybody's problem.
What gets measured gets optimised. What gets measured in the wrong units gets optimised in the wrong direction.
The levers that actually moved the number
1. Pay for the traffic you have, not the traffic you feared
The most common and most expensive mistake in payments infrastructure is provisioning permanently for a peak that happens rarely. It feels prudent. It is enormously wasteful, and the merchant pays for it every single day of the year, including the days nothing happens.
Our systems scale out when load arrives and — the harder discipline — scale back in when it leaves. Giving capacity back is the part teams forget, because nothing breaks if you don't. Nothing breaks. You simply pay for a fortress you occupy once a quarter.
2. Capacity follows the sun
Cross-border traffic has a shape that domestic traffic does not. Our merchants' buyers are in New York, London, Dubai and Singapore, and those corridors wake up and go to sleep at different times. There is no single global peak; there is a rolling one.
A statically sized platform has to be large enough for all of those peaks, all of the time. An elastic one can be large where the traffic is and small where it is not. At three in the morning in a corridor that is not selling anything, we are not paying to keep servers awake in case someone in that timezone changes their mind.
3. The cheapest work is work that never reaches your origin
We have written before about why we run so much at the edge, and the argument there was about speed and security. The financial argument is just as strong. Traffic that is validated, filtered or served at an edge node never consumes origin compute, never crosses a bandwidth meter, and never occupies a database connection. The security screening that protects a merchant's checkout costs us less precisely because it happens close to the buyer rather than close to the ledger — which is also why Dynamic Checkout is served from the edge rather than from India.
A request you never had to process is cheaper than a request you processed efficiently.
4. The invisible line item: moving data
Every engineer knows what compute costs. Almost nobody watches what it costs to move bytes — between regions, out to the internet, through the network appliances sitting quietly in the middle of everything.
For a platform serving buyers in 180+ countries, data movement is not a rounding error at the bottom of the bill. It is a first-class cost, and it is the one we found the most waste in: chatty services talking across regions when they did not need to, traffic taking expensive paths out of habit, logs shipped in full when a sample would have told us the same thing. None of it was visible until someone went looking, because nobody bills you in units of regret.
5. Choose the right runtime per workload — measured in the right units
Serverless is cheaper than containers, except when it isn't. Modern ARM-based processors offer materially better price-performance for most of what a payments platform does, except for the parts where they don't. There is no universal answer, and any team that tells you there is has not measured.
The discipline is to evaluate each workload in cost per transaction rather than cost per server, and to accept that the answer will be different for the authorisation path, the risk engine, the reconciliation batch and the reporting layer. Uniformity is comfortable. It is also expensive.
6. Commit to the predictable, rent the unpredictable
Our baseline volume is steady and forecastable — it is the floor beneath every corridor's daily rhythm. Predictable capacity should never be bought at on-demand prices; committing to it in advance is simply cheaper, and there is no engineering risk in committing to a floor you have never once fallen below.
The unpredictable layer above it is rented, elastically. And the work that is genuinely interruptible — overnight reconciliation, reporting aggregation, archival — runs on the cheapest, least reliable capacity available, because it does not matter if it is evicted and restarted. It matters enormously for a live authorisation. It matters not at all for a batch job that has until morning.
Live payments never touch that cheap capacity. That is not a cost decision. It is the line we do not cross.
7. Keep compliance data, cheaply
Regulators require us to retain transaction records and audit trails for years, and we do — but there is a large difference between data that must be retrievable and data that must be instantly available. The vast majority of our compliance archive has not been read since the day it was written, and the appropriate place for it is the cheapest storage tier that still satisfies the obligation. Paying premium rates to keep years of audit logs one millisecond away from a query nobody is going to run is a very expensive way to feel prepared.
What we will not do to save money
It is worth being explicit, because this is where cost optimisation goes wrong in fintech and where it does real damage.
We do not buy savings with reliability. We do not buy them with security. We do not thin out our redundancy, skip our screening, or run live authorisation on capacity that can be taken away from us mid-transaction. Every one of those would show up on the bill as a saving and on the merchant's account as a failure.
The cheapest payment platform in the world is one that is switched off. Cost optimisation only counts if reliability is held constant while you do it.
The engineering is not in spending less. Anyone can spend less. It is in spending less while the platform gets faster, safer and more available — which is a much narrower path, and the only one worth walking.
Why this matters more in cross-border than anywhere else
A domestic payment is a short journey. A cross-border payment is a long one, and there are people standing along the route with their hands out.
The most expensive of them is currency. Money that goes out through one provider and comes back through another gets converted twice, and pays a markup in both directions — and because that markup never appears on a single invoice, it is invisible to the finance team quietly losing money to it. Running inbound collections and outbound payouts on one authorised stack is what allows currency to be netted rather than round-tripped: a business earning dollars and spending dollars should not be paying to convert them into rupees and back again for the privilege.
That is a structural saving, not a discount. It is the same argument as the infrastructure one, at a different layer — and it is why our multi-currency accounts exist at all.
What this returns to the merchant
Payment gateway charges are not conjured out of nothing. They are a processor's cost base, plus its margin, plus whatever inefficiency it has decided the merchant should carry. Every provider is passing on the cost of running their platform. The only question is how much of it there is.
Every rupee we take out of our cost per transaction is a rupee we can return to the merchant in pricing. That is not a slogan — it is the arithmetic. There is nowhere else for infrastructure cost to go.
An efficient platform is not an engineering vanity. It is the reason an Indian exporter can collect from a customer in London at a price a bank cannot match, on infrastructure that is faster and better protected than the bank's — and it is why we treat a cloud bill as a merchant-facing document, because in the end that is exactly what it is.
Frequently asked questions
What is cost per transaction in payments?
Cost per transaction is the total infrastructure and processing cost a payment provider incurs to complete a single payment. It is the most important infrastructure metric in payments because, unlike server counts or utilisation figures, it is the one the merchant ultimately feels — a provider's cost base sits inside the rate it charges, so an inefficient platform is necessarily a more expensive one for its merchants.
How do payment gateways decide their charges?
A payment gateway's charges are built from its cost base, its margin, and any inefficiency it chooses to pass on. That cost base includes infrastructure, network and acquirer fees, compliance, fraud losses and support. Providers with a lower cost per transaction have more room to price competitively, which is why infrastructure efficiency and merchant pricing are directly linked.
What is forex markup, and can it be avoided?
Forex markup is the margin a provider adds on top of the mid-market exchange rate when converting currency. In cross-border payments it is often charged twice — once when money is collected and again when it is paid out — because inbound and outbound flows sit with different providers. Running both directions on a single stack allows currency to be netted rather than converted twice, which removes one side of that markup entirely.
Does cheaper infrastructure mean a less reliable payment gateway?
It should not, and if it does, the optimisation was done wrong. Legitimate cost optimisation reduces waste — idle capacity, unnecessary data movement, work processed at origin that could have been handled at the edge — while holding reliability and security constant. Savings that come from thinner redundancy, weaker screening, or running live authorisation on interruptible capacity are not savings; they are deferred failures.
Why does cloud cost optimisation matter to a merchant?
Because a payment provider's infrastructure cost does not vanish — it is recovered through pricing. Every inefficiency in a processor's platform is eventually paid for by the businesses using it. Cost optimisation is therefore not an internal housekeeping exercise; it is what determines how competitively a provider can price cross-border payments.
What is FinOps?
FinOps is the practice of making cloud cost a shared, visible engineering responsibility rather than a finance department problem discovered at the end of the month. In payments it means putting cost per transaction alongside latency and error rate on the dashboards engineers actually look at, so that the cost consequences of a design decision are visible at the moment the decision is made.
Ready to see what you should be paying?
PayGlocal runs international and domestic payments on one RBI-authorised stack, across 180+ countries, with payment success rates up to 96%. We build efficiently because efficiency is the only honest source of competitive pricing. Talk to our team, or read the APIs at docs.payglocal.in
