Mauritius software delivery: design for continuity and reconciliation

OutsourcingVN is operated by Netbase JSC, so this guide is written by a supplier that would like your project. It uses continuity features Netbase has built into two African platforms and official Mauritian references for the data and payment questions. The guides index lists the guides for other markets.

Contents

• Why start a Mauritius brief with continuity?
• Which continuity features have delivered platforms used?
• What is the safe state for each dependency?
• How do you test continuity before launch?
• Worked scenario: a payment timeout on a vendor order
• Which support hours can you expect?
• Which questions should you ask a supplier?
• What usually goes wrong?
• How this guide is sourced and where it stops
• Common questions
• Plan the first release

Why start a Mauritius brief with continuity?

Buyers serving Mauritius often run services where customers, merchants or partners expect money and records to be right the next morning: marketplaces with payouts, booking or subscription services, and back-office tools shared with partners. The features are ordinary; the operating promise is not.

• Data. The Data Protection Act 2017, published by the Data Protection Office, is the reference your advisers use to decide how personal data is collected, kept and corrected.
• Payments. The Bank of Mauritius publishes payment-system guidelines. Your commercial owner and advisers choose providers and arrangements; engineering implements the states and records they decide.
• Operations. Somebody has to answer customers and fix records when a dependency fails. That person, their hours and their tools belong in the scope.

Which continuity features have delivered platforms used?

Two Netbase records show continuity designed into the product rather than added later.

• Messaging with a fallback and offline field capture. For Dey Page, a multi-state business directory in Nigeria, Netbase built business messaging with SMS fallback and a field-verification process with offline sync and a head-office review queue. Field agents keep capturing when the connection drops, and nothing is published until head office reviews it. See the multi-state business directory record; no public launch or user numbers are claimed.
• Payouts, commission and post-launch support. For RB Marketplace, an English-first multi-vendor marketplace for West Africa, Netbase built vendor earnings, commission deductions and payout requests, with administrator controls for payouts and 90 days of post-launch support. See the RB Marketplace and shopping app record.

They are the published examples closest to the continuity features this guide recommends; the Mauritius-specific rules come from the official references above.

What is the safe state for each dependency?

Write one row per dependency. The safe state is where a record waits, visibly and without harm, until the dependency recovers.

A row without an owner is usually the row that fails first, so fill in the owner column before anything else.

Worked scenario: a payment timeout on a vendor order

A customer orders from a vendor on a marketplace serving Mauritius. The payment provider accepts the request, but no confirmation arrives.

1. Held. The order is marked "payment unconfirmed". The vendor is not asked to ship, and the customer sees a message that the payment is being confirmed.
2. Status check. A scheduled check queries the provider after the agreed window. The provider reports success.
3. Release. The order is released to the vendor, and the vendor's pending earnings are recorded net of the marketplace commission.
4. Late event. The provider's own notification arrives later. Processing is keyed to the provider reference, so the order is not released twice.
5. Reconciliation. Next morning, finance compares the provider report with orders and vendor balances. One payment, one order, one earnings entry.
6. Customer contact. If the customer writes in while the order is held, the support agent sees the held state and the next check time, and answers from an approved script.

If the check had reported failure, step 3 would close the order with a reason code and send the customer a retry link instead. Both paths should be demonstrated before launch.

Which support hours can you expect?

Decide your own support promise first, then check that the supplier's hours and the service's safe states cover it. For Netbase, the Hanoi office works Monday to Saturday, 9:00-18:15 Vietnam time (UTC+7), and support coverage follows those days. Mauritius runs on UTC+4, so that working day falls between 06:00 and 15:15 Mauritius time. Anything outside that window needs a safe state, an automatic acknowledgement or your own on-call arrangement. For ongoing operations after launch, Managed Operations sets out how monitoring, fixes and changes are organised.

Which questions should you ask a supplier?

• What is the safe state for each dependency? A good answer is a table like the one above, filled in for your service.
• How do you prevent double release? Look for idempotent processing keyed to provider references.
• How are payouts reconciled? Expect vendor balances, commission records and a returned-payout route.
• What happens outside your support hours? Expect a stated window and designed safe states, not "we are always available".
• Can you show a failure test? Ask to see a timeout and a duplicate event handled in staging.
• What is in the runbook at handover? Expect recovery steps your team can follow alone.
• How long is post-launch support? Look for a written period and scope.

What usually goes wrong?

• Fulfilment released on an unconfirmed payment. Signal: orders shipped and later reversed. Owner: the finance owner.
• Queued changes replayed out of order. Signal: partner records show an older value. Owner: engineering.
• Returned payouts lost. Signal: vendors chase money the system shows as paid. Owner: the finance owner.
• No owner outside support hours. Signal: weekend issues found on Monday by customers. Owner: the service owner.

How this guide is sourced and where it stops

This guide uses the Mauritius Data Protection Act 2017 and the Bank of Mauritius payment-system guidelines page, both accessed on 2026-09-27, and Netbase delivery records approved in the OutsourcingVN claim register. It is written for operations, finance and product leads preparing a brief. It does not decide licensing or legal roles; your advisers do. Netbase JSC's head office is in Hanoi, Vietnam, and it is the company's only office, so Mauritius projects are delivered remotely.

Plan the first release

Bring your essential journey, your providers, your support promise and the names of your finance, operations and service owners. The total software delivery cost worksheet helps compare proposals that include failure testing and runbooks, and the methodology explains how the records on this page are sourced. For other markets, the Nigeria guide covers two-provider payments and phone sign-in, and the UK guide covers supplier assurance and accessibility evidence.

Custom Product Engineering is the service for a bounded build, and global delivery explains how remote delivery is organised. OutsourcingVN is Netbase's own outsourcing-services platform: submit a project with your essential journey, and a person will reply with whether discovery or a bounded implementation is the right next step.

Related services and solutions

Sources

• Data Protection Office, Data Protection Act 2017
• Bank of Mauritius, Payment systems guidelines