A money transfer platform cannot be upgraded like an ordinary website. When the work starts, money is already moving: a customer has just paid, a provider is about to confirm, a payout is with a partner, and scheduled jobs are chasing all three. Putting up a "back soon" page does nothing for any of them. The real test of maintenance is not whether the site stayed up. It is whether every payment and payout that was in flight before the work is accounted for after it. This guide is for operations, technology and support leads who run upgrades on a live remittance platform.
It gives a runbook for before, during and after a window, and a worked example of a 02:00 upgrade. Figures in the example are illustrative.
Four rules for maintenance with money in flight
- Hold only what the work needs. If the work touches payouts, hold payouts. Do not stop customers sending because a database index is being rebuilt.
- Let work already under way finish. A transfer that was paid before the window should not be treated as new, lost or failed because of it.
- Never lose a provider message. A confirmation that arrives mid-upgrade must be kept and applied once, not dropped and not applied twice.
- A person ends the window, not the clock. The scheduled finish is for planning and customer messages. Processing resumes when someone has checked it is safe.
Regulators expect this kind of control. The Financial Stability Board's 2024 recommendations for payment service providers offering cross-border services list operational risks, including third-party risks, and resilience among the risks supervision should address (see sources below).
Doing it with RemitSo
RemitSo, a white label remittance platform, treats maintenance as a state of the platform, not a page on the website.
- Most releases need no window. Every release says plainly whether it needs downtime and what to do afterwards. None of the releases from 2026.10.1 to 2026.10.11 needed downtime.
- Booked ahead, holding only what it needs. A window has a start, an expected finish and a customer message, and names what it holds: new transfers, payments, payouts, scheduled work, and wallet loads where wallets, an optional add-on, are licensed. You can book a quiet hour ahead or pause now.
- Money in flight carries on. A window never takes the platform down, and transfers already under way carry on.
- It holds until someone lifts it. An upgrade that overruns does not resume service underneath it.
- In-flight work is visible. Scout measures every five minutes, or on demand with Measure now: payments where the provider has not answered, payouts needing action, provider messages never applied, partners failing calls and maintenance windows.
- Nothing incoming is lost. Every incoming partner message is saved before it is processed; the raw message and the reason it failed are one click away, and it can be retried in one click.
- Tested first. Releases reach your staging environment first, and every environment shows which release it runs.
Customer apps can ask whether the service is available, so customers see the window's message instead of an error.
The maintenance runbook
| Stage | What to do | Who | Done when |
|---|---|---|---|
| Days before | Read the release note: does it need a window, and what does it hold? Run it on staging. | Technology lead | Staging runs the release; the window's scope is written down |
| Days before | Book the window: start, expected finish, what it holds, customer message | Operations lead | The window is booked and the support team has the message |
| 30 minutes before | Measure Scout and write down the in-flight count: payments awaiting a provider, payouts awaiting a partner, messages not yet applied | Operations on shift | One number, split by type, recorded with the time |
| 30 minutes before | Check no partner is already failing calls. If one is, decide whether to go ahead | Operations on shift | Go or no-go recorded |
| During | Run the upgrade. Do not lift the window to "just check" something | Technology | Technology confirms the work is complete |
| During | Answer customer contacts with the booked message and the expected finish | Support | No promises beyond the message |
| Before lifting | Measure Scout again. Account for every item in the earlier count: answered and applied, or still waiting with a reason | Operations on shift | Every item placed; no messages left unapplied; no new failing partner |
| Lifting | Lift the window. Watch the first new transfer through payment and payout | Operations on shift | First transfer clears normally |
| Next morning | Write a three-line note: planned and actual times, in-flight count before and after, anything left open | Operations lead | Note filed with the release |
A 02:00 window, with 14 responses accounted for
A release needs a database change that holds new transfers and payouts for up to 40 minutes. The window is booked for Tuesday 02:00, expected finish 02:40. New transfers, payments and payouts are held. The customer message reads: "We are upgrading our service. Transfers you have already paid for are safe and will continue. You should be able to send again from about 02:40."
01:30, before. Operations presses Measure now on Scout. 14 responses are outstanding: 9 payments waiting for a provider to confirm and 5 payouts waiting for a partner to confirm. No provider messages are waiting to be applied. No partner is failing calls. The count is written into the shift log.
02:00 to 02:51, during. The window starts. Customers opening the app see the message. Provider and partner confirmations keep arriving, and each is saved before it is processed. At 02:38 the database change is taking longer than planned. Nothing resumes at 02:40, because the window holds until someone lifts it. Technology confirms the work is complete at 02:51.
| Outstanding at 01:30 | Answered and applied | Still waiting | Next step for those still waiting |
|---|---|---|---|
| 9 payments awaiting a provider | 7 (6 cleared, 1 refused by the customer's bank) | 2 | Stay on Scout under payments needing action; no payout until they clear |
| 5 payouts awaiting a partner | 4 completed | 1 | Stays on Scout under payouts needing action; chased on its normal schedule, never resent without an operator confirming with the partner |
| Total: 14 | 11 | 3 | All 14 placed; nothing unexplained |
02:55, lifting. Scout shows no provider messages left unapplied, no failing partner, and the three waiting items are the same three from the earlier count, not new ones. Operations lifts the window at 02:56 and watches the first new transfer clear. The morning note reads: "Planned 02:00 to 02:40; actual 02:00 to 02:56. 14 in flight; 11 resolved during the window; 3 still waiting at lift, all pre-existing, all on Scout."
Useful test: if the count after the window is higher than before and you cannot name the new items, do not lift. Something started or stopped during the work that nobody planned for.
Watch out: a payout that a partner may already hold is the one thing never to "just retry" after a window. Confirm with the partner first. Paying twice is far harder to undo than waiting.
Deciding what a window should hold
| The work touches | Hold | Leave running |
|---|---|---|
| Payout partner connection | Payouts | New transfers and payments; transfers queue for payout |
| Payment provider connection | Payments | Payouts for transfers already paid |
| Database changes on transfers | New transfers, payments and payouts | Saving incoming messages |
| Rate feed or pricing | Scheduled work for rates; consider new transfers | Payouts for transfers already quoted and paid |
| Customer app release only | Nothing on the platform, usually | Everything |
The narrower the hold, the fewer customers notice. A window that holds payouts for twenty minutes at 02:00 is invisible to most senders. For the wider reliability picture, see infrastructure reliability for high-volume money transfer, and for safe retries after a window, a reliable payment retry system.
See the admin features, every release's downtime in the release notes, or book a demo.
Sources
Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.
Frequently asked questions
What does zero-downtime maintenance mean for a remittance platform?
Upgrading the platform without taking it down and without losing track of transfers already in progress. Some actions may be held for a short time; nothing in flight is lost or processed twice.
What happens to a payment that is in progress when the window starts?
In RemitSo, transfers already under way carry on, and every incoming provider message is saved before it is processed. Before lifting the window, the team checks that each payment outstanding beforehand has been answered or is still visible on Scout.
Should a window end automatically at its scheduled time?
No. The scheduled finish is for planning and customer messages. In RemitSo the window holds until someone lifts it, so an overrunning upgrade does not resume service underneath it.
Do customers see an error during maintenance?
Customer apps can ask whether the service is available, so customers see the window's message rather than a failure.
How often does RemitSo need a maintenance window?
Most releases need none. Each release says whether it needs downtime; none of the releases from 2026.10.1 to 2026.10.11 did.