IT infrastructure for a payment gateway: TuPagoOnline

For a shop, ten minutes of downtime becomes an anecdote. For a payment gateway, those ten minutes are operations that never happened: customers who tried to pay and could not, merchants left waiting for a confirmation and a level of trust that takes months to rebuild.

TuPagoOnline is a payment gateway built in PHP and Laravel that moved to high-availability infrastructure on AWS: load balancing, replication with failover, queues for processing transactions, encryption, WAF and anti-DDoS, monitoring and backups. After the project the platform sustains 99.98% uptime and responds in 0.4 seconds.

The challenge: in payments, downtime is not an inconvenience

A payment platform has two demands that allow no nuance: it cannot lose operations and it cannot stop responding. And both are tested exactly when the system is busiest.

A minute down is counted in lost operations

When the gateway stops responding, the merchant does not see a technical error: they see a sale that did not close. And if the failure repeats, the consequence is not just the lost operation, it is that the merchant looks for another gateway, because collecting payments is the one thing that cannot fail in their business.

The peak gives no warning

Payments cluster: month ends, campaigns, key dates. A system sized for average traffic falls short precisely on the day that matters most, and that day is not a choice.

A gateway is a target

Moving money while sitting exposed to the internet is a combination that attracts attempts of every kind: from automated scans to volume attacks to knock it offline. Security is not a layer added afterwards, it is part of availability.

The solution: high availability on AWS

The platform was reorganised on AWS with redundancy at every level: several servers serving at once, a database that replicates, queues so transactions do not block the website and security layers in front of everything. The logic is simple: if something can fail, something else has to be doing its job.

Load balancing and several servers

Traffic is spread across servers instead of depending on one, and if a node stops responding the others keep serving. That is what turns a server failure into an internal event instead of a service interruption.

Replication with failover and transaction queues

The database keeps replicas and failover, so the place where the money lives is not a single machine. Transactions are processed through queues, so a peak of operations is queued and resolved in order without the website stopping responding.

Security, WAF and monitoring

Data is encrypted in transit and at rest, the WAF filters malicious requests and anti-DDoS absorbs volume attacks. All of it with monitoring and alerts, because in a gateway the warning has to arrive before the merchant's complaint.

How we did it in more than three months

The work was organised around two ideas: testing failure before it happens and watching what really matters. In high availability, what has not been tested cannot be considered solved.

Testing failure before it happens

Controlled failures were forced — shutting nodes down, cutting the connection to the primary database, simulating load — to check that the system keeps serving. Redundant infrastructure that has never been tested is an assumption, and in payments assumptions are expensive.

Watching what really matters

The metrics that anticipate a problem were defined: API response time, queue length, errors per transaction and replica status. Watching those makes it possible to act before the merchant notices anything, which is the only useful moment to do it.

Results

The project was delivered with the platform running on redundant infrastructure, queues and encryption in place and monitoring watching over it. These were the needs and how they were solved:

The measured results of the project: the platform sustains 99.98% uptime and responds in 0.4 seconds. Both figures describe the same thing from two angles: the system is almost always available and, when it is used, it answers fast, which is exactly what a merchant needs to collect payments without thinking about infrastructure.

What a payment platform needs

If your platform moves money and you cannot afford it going down, these are the points that decide whether it holds up:

• Redundancy at every level, because a single component is a single point of failure.
• Tested failover, since a replica that has never been used is of unknown reliability.
• Queues for transactions, which stop a peak from blocking normal service.
• Encryption and security controls, because third parties' payment data is being handled.
• WAF and anti-DDoS, which protect availability against attacks, not just information.
• Monitoring of what anticipates failure, so you act before the customer notices.

If your platform handles critical operations and you are not sure what would happen if a server failed, our IT infrastructure page explains how we work, and you can write to us to go through it together.

Frequently asked questions

What does high availability mean for a payment gateway?

That a server going down is not noticed. More than one is serving, the database replicates and traffic is spread across them, so a component can fail without stopping the payment. The goal is not never failing: it is making sure a failure never reaches the customer.

Why do transaction queues matter?

So a peak does not block the system. Operations are processed in order and asynchronously, so the website is not left waiting for each transaction to finish. In payments, a well-built queue is what separates 'it is slow' from 'it is not responding'.

What do the WAF and anti-DDoS protect in a gateway?

A payment gateway is an obvious target: it moves money and sits exposed to the internet. The WAF filters malicious requests and anti-DDoS stops a volume attack from pushing legitimate customers out. Without those two layers, availability depends on nobody deciding to attack you.

How long does it take to build high-availability infrastructure?

This project took more than three months. The schedule is set by load balancing and redundant servers, replication with failover, transaction queues, encryption, the WAF and anti-DDoS, monitoring and backups.