Routegate Reserve: selling when your lines run dry

Lines run dry. It happens to every business that sells from its own SIMs: a line's data runs low in the middle of the evening rush, a carrier bars a line for a check, a batch of top-ups lands later than it should. The customer waiting for their bundle does not care which of those it was. They care that it arrives.

Routegate Reserve is our answer to that gap. It is a pool of lines Routegate runs itself, which you can let serve your sales when your own lines cannot, or ahead of them if you prefer. It is off until you turn it on, and you pay for it only when it delivers.

Off, fallback or first

The Reserve is chosen per network, because a business usually has one network well covered by its own lines and another it is still building. For each of MTN, Glo, Airtel and T2 Mobile there are three settings:

• Off, the default. The Reserve is never offered your sales on that network.
• Fallback. Your own lines come first. When none of them can serve the sale, a Reserve line can.
• First. A Reserve line is offered the sale ahead of your own lines, and yours take over when the Reserve cannot.

It lives in the same routing rules as everything else:

 curl -X PUT "https://api.useroutegate.com/v1/routing/rules?mode=live" \
  -H "Authorization: Bearer $DASHBOARD_SESSION" \
  -H "Content-Type: application/json" \
  -d '{
    "networks": {
      "mtn": { "platform_sims": "fallback" },
      "airtel": { "platform_sims": "first" }
    }
  }'

The API kept its working names, so the setting is platform_sims with the values off, fallback and first. It cannot be set per service or per plan: a network is the unit, which keeps the question of where a sale may go short enough to answer at a glance.

The Reserve sits alongside your supply order rather than replacing it. With lines then vendors and the Reserve on fallback, a sale goes to your lines, then the Reserve, then your vendors in the plan's fallback order.

What it costs, and when

Each plan the Reserve can sell has a Reserve price, set by us and published to you. It is added on top of the plan's charges; it never replaces them. A plan with no Reserve price is simply never sold from the Reserve.

 curl https://api.useroutegate.com/v1/pricing/platform-prices \
  -H "Authorization: Bearer $DASHBOARD_SESSION"

 {
  "success": true,
  "code": "OK",
  "message": "OK",
  "data": {
    "items": [
      {
        "product_code": "MTN-SME-1GB",
        "product_name": "MTN SME 1GB",
        "network": "mtn",
        "price": 250.00,
        "updated_at": "2026-10-24T09:00:00Z"
      }
    ]
  }
}

The amount there is only an example; your dashboard shows the real list.

The charging rule is the part we cared most about getting right. When a sale is accepted and the Reserve might serve it, because it is on for that network, the plan has a Reserve price and a Reserve line can take it now, the Reserve price is held in your wallet beside the plan's charges. It is not spent. If a Reserve line delivers the sale, the price is taken. If your own line or a vendor delivers it instead, or the sale fails, the hold is released and you have paid nothing for the Reserve.

You pay for the Reserve when it saves a sale, and at no other time.

There is one honest edge. If a Reserve line takes a sale and the carrier's answer is unclear, the sale is treated the way every unclear answer on Routegate is: it stays pending, is never sent anywhere else, and is settled from the line's balances or a status check. The Reserve price stays held with it until then: taken if the line delivered, released if it did not.

How it shows up

Every transaction carries platform_fee, in naira. It is the Reserve price on a sale a Reserve line delivered and 0.00 on every other sale, so the field is always there and always means one thing. The route that served the sale reads stock in channel:

 {
  "reference": "RG-01JB7C",
  "status": "successful",
  "network": "mtn",
  "product_code": "MTN-SME-1GB",
  "price": 265.00,
  "platform_fee": 250.00,
  "channel": "stock",
  "sold_as": "plan"
}

Webhooks carry both fields, the transaction list filters on ?channel=stock, and the CSV export has a Platform Fee column at the end. In the dashboard's route trace a Reserve hop is labelled Reserve, and the routing simulator shows Reserve lines as candidates when your rules would offer them a sale, so you can see where they sit before you turn anything on.

What you do not see is the Reserve's own lines: their numbers, their balances, their health. Those are ours to keep full, and the only thing a Reserve line owes you is a delivered sale.

When to use it

Fallback is the setting most businesses will want. It changes nothing about how your own lines are used, it costs nothing on the days they cope, and on the evening they do not, the sale still lands.

First suits a network where your own lines are thin, new, or being moved, and you would rather the Reserve carried the load while they settle.

Off is right when your margins on a network cannot carry the Reserve price, or when you would genuinely prefer a sale to fail over to a vendor than to pay for a line. It is your call, network by network, and it can change whenever you change it.

In test mode

Test mode never uses the Reserve. Test sales run on the mock, so channel there is always test and platform_fee is always zero. Turn the Reserve on in live mode only when you have seen its prices and decided which networks it should cover.