How to Perform Zero-Downtime Maintenance on a Remittance Platform

A money transfer business cannot simply put a "System Under Maintenance" message on the screen and assume the work is done. Behind that screen, money may already be moving.

A customer may have created a transfer and initiated payment. A payment provider may be processing the transaction asynchronously. Another customer's payout may already have been submitted to a payout partner. A provider response may be waiting to reach the platform. At the same time, scheduled processes may be checking payment status, updating exchange rates, closing expired transfers, or handling other operational work.

This is what makes maintenance particularly challenging for a cross-border money transfer platform.

The technical objective is not simply to keep the website online. The real objective is to change or upgrade the platform without losing control of transactions that are already in motion.

That distinction matters as cross-border payment infrastructure becomes increasingly dependent on interconnected providers, payment systems, APIs, and other third parties. The Financial Stability Board's December 2024 recommendations on payment service providers offering cross-border payment services name operational risks (including fraud, cyber and third-party risks), resilience and financial-crime risks among the risks that regulation and supervision of these providers should address.

So, how should a money transfer business approach zero-downtime maintenance?

A conventional SaaS application may have a relatively straightforward request flow:

User → Application → Database → Response

A remittance platform is considerably more interconnected.

Figure 1: A single cross-border transfer involves multiple systems — each operating independently and asynchronously.

There may also be authentication services, KYC providers, fraud or screening systems, exchange-rate sources, notification services, banking partners, wallet infrastructure, and internal background processes involved around that flow.

And unlike an ordinary web request, a money transfer does not necessarily finish while the customer is looking at the screen. The customer could initiate a payment now and receive the provider's final response several minutes later.

A payout might be submitted before maintenance and confirmed by the payout partner afterward. A provider webhook could arrive while an application deployment is taking place.

That means a maintenance event has to account for work that started before the maintenance window and finishes after it.

Imagine a customer in the United Kingdom sending money to India. The customer has received a quote, confirmed the transfer and started making the payment.

At that exact moment, the money transfer platform begins its scheduled upgrade. The website may still be accessible. But what happens to the payment?

Figure 2: For a money transfer business, these questions are much more important than whether a server responds with HTTP 200 during a deployment.

If the payment provider confirms the transaction during the upgrade, the platform needs to receive and process that information correctly. If the payment was already accepted but the platform has not yet updated the transaction state, the system needs to preserve that state.

If the transfer subsequently becomes eligible for payout, the payout workflow needs to continue without accidentally treating the transaction as new.

One of the common mistakes in financial software is thinking about maintenance as a front-end problem. The customer sees "We'll be back shortly." But the backend continues doing things.

That can be dangerous.

A better approach is to have a controlled maintenance state that the platform itself understands.

When maintenance begins, the platform knows that it is operating in a restricted state. Customer-facing behaviour, background processing, provider communication and operational workflows can then respond according to defined rules.

That is very different from manually stopping a few servers and hoping everything comes back correctly afterward.

Customers rarely think about background jobs. They simply expect their transfer to move from one state to another. But background processing is often responsible for making that happen.

Figure 3: These routines must pause during maintenance and resume exactly where they left off — not simply disappear.

During maintenance, some of these jobs may need to pause. The important word is pause, not disappear.

If a job stops, the platform needs to know what work was unfinished and where processing should continue afterward.

Consider a payment polling process. If it had checked a provider at 10:00, maintenance began at 10:02, and the provider changed the payment status at 10:03, the platform should not lose track of that transaction simply because a worker was unavailable at 10:03.

When processing resumes, the platform should be able to determine the latest known state and continue safely.

A transfer often has multiple financial stages, and each stage can have its own external dependency.

Figure 4: Confusing these states during maintenance can lead to duplicate actions, lost payouts, or financial discrepancies.

Maintenance should not cause the system to confuse "Payment received, payout pending" with "Payment not received."

A resilient money transfer platform therefore needs transaction states that survive maintenance without losing their meaning.

Cross-border money movement depends heavily on communication between systems. A payment provider may send a status update. A payout partner may confirm a transaction. An external service may send a webhook.

The platform needs to know what happens to those messages when maintenance is underway. The important principle is that the message should remain recoverable and traceable until it has been safely applied.

Figure 5: Every provider message must be fully traceable — the worst outcome is not knowing whether it was applied.

This is where durable message handling, idempotent processing and reconciliation become important design considerations.

Suppose a money transfer business schedules maintenance for 2:00 AM to 3:00 AM. The one-hour window is useful. But what happens if the database migration takes longer than expected?

At 3:00 AM, should the platform automatically resume everything? Not necessarily.

Figure 6: The operator remains in control of the final transition — readiness determines the release, not the clock.

A maintenance schedule should be treated as a planned operating window, not a command to resume financial processing regardless of system readiness.

Before changing a production money transfer platform, the operations team needs to know what is already happening. This is particularly important when transfers are processed asynchronously.

Imagine that, immediately before maintenance begins, the platform has several payments waiting for provider responses, payouts already submitted to partners, provider messages waiting to be applied, transfers approaching payment deadlines, and background processes currently running.

Those are not just technical metrics. They represent financial activity in progress.

Knowing the state of that activity allows the team to understand what the platform needs to preserve while the upgrade takes place. It also gives operators a reference point for post-maintenance validation.

Before maintenance: 14 provider responses outstanding.
After maintenance: 14 responses accounted for, with no unexplained increase in outstanding work.

That is much more meaningful than simply seeing a green server-health indicator.

A maintenance process estimated at 30 minutes may take 45 minutes. A database migration may encounter an unexpected issue. A deployment may require rollback. A third-party service may become unavailable during the upgrade.

The platform therefore needs to behave safely when the maintenance window runs longer than planned. This is another reason not to make the end time an automatic resume trigger.

Rather than promising "Everything will be back at exactly 3:00 AM," the business can communicate an expected maintenance period while retaining operational control if the upgrade needs more time.

A platform may remain technically available while certain actions are temporarily restricted. The objective should be to minimise unnecessary disruption while protecting transaction integrity.

Customer communication also needs to reflect the realities of payment processing. If a payment instruction has a limited validity period, customers may need to know how long they have to complete it and what terms apply to the payment provider.

Good maintenance therefore sits at the intersection of Technology + Operations + Customer Experience rather than belonging exclusively to the engineering team.

Modern money transfer businesses rarely operate as completely self-contained systems. They may depend on payment providers, banking partners, payout providers, identity and verification services, exchange-rate sources, cloud infrastructure, messaging services, and other financial technology providers.

The Financial Stability Board's recommendations list third-party risks among the operational risks that authorities should make sure payment service providers manage, which is why a dependency on a provider needs the same care as the platform's own code.

That means maintenance planning should ask not only "Is our platform ready?" but also "What happens to the external systems connected to our platform while we are changing it?"

The strongest approach is to design maintenance around the actual lifecycle of a transfer.

Figure 7: Thinking about maintenance at every lifecycle stage produces a more resilient architecture than simply asking whether the application remains online.

RemitSo treats maintenance as a platform-level operational state, not a maintenance page.

• Most releases need no customer stop. Customers keep sending while the platform is updated; a window is used only when the work needs one.
• Booked ahead, stopping only what it needs. A window is booked with a start, an expected finish and a customer message, and names what it holds: new transfers, payments, payouts, scheduled work such as payment and payout follow-up and exchange-rate feeds, and wallet loads where wallets (an optional add-on) are licensed. It never takes the platform down, and money already in flight carries on.
• In-flight work visible first. Scout, measured every five minutes, shows payments where the provider has not answered, payouts needing action and provider messages never applied, so the team can see in-flight work before an upgrade.
• A business note with every release. Each release, numbered by date, says what changed and its service impact: whether it needs downtime and what to do afterwards. Operations can plan from the note rather than asking engineering.
• Every environment shows which release it runs, and releases reach the operator's staging first, so nobody has to guess whether production has the change that was tested.

The window itself stays under operator control. The scheduled time guides planning and customer communication, but the operator lifts the window: normal processing resumes because the system is ready, not because the scheduled hour has passed.

Cross-border payment infrastructure is moving toward faster and more interconnected payment experiences. As payment systems become faster and increasingly available around the clock, the traditional idea of a convenient overnight maintenance window becomes less useful.

A money transfer business serving customers across multiple countries may have customers active at almost any hour. That makes controlled maintenance increasingly important.

The question is no longer simply "When can we take the platform offline?" It becomes: "How can we change the platform safely while money is continuously moving through it?"

That is the real challenge behind zero-downtime maintenance.

A reliable remittance platform is not defined only by how quickly it can process a new transfer. It is also defined by how safely it handles change.

Software will be upgraded. Databases will be migrated. Infrastructure will be changed. Providers will evolve. New payment methods will be introduced.

The platform therefore needs to treat maintenance as part of the money movement architecture itself.

For a money transfer business, successful maintenance means knowing what is happening before the change, controlling what happens during the change, preserving work that is still in flight, and verifying that normal processing can safely resume afterward.

The goal of zero-downtime maintenance isn't simply to keep the lights on. It's to make sure the money keeps moving safely — even while the infrastructure underneath it is changing.

• Financial Stability Board: Recommendations for Regulating and Supervising Bank and Non-bank Payment Service Providers Offering Cross-border Payment Services: Final report (12 December 2024)

Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.

Frequently Asked Questions

• Every outbound API call logged with status, duration and correlation ID; every webhook saved before processingFaults are diagnosed from the record, not from guesswork
• The Client API documented live inside the console and kept in step with each releaseYour developers integrate against what is actually deployed
• A software bill of materials and an infrastructure overview, hosted in a dedicated AWS account in your regionBank and partner security reviews go faster
• Maintenance windows that pause only what the work needs, and the source code available to buyUpgrades without downtime, and a path to owning the platform

Book a demo Admin features →