The challenge of a payment API + hotspot
A Cameroon payment API (initiation, callback, status, cancellation) is not enough on its own for a captive portal. You also need to: authenticate the WiFi customer, open the RADIUS session, manage quotas, disconnect remotely, and secure the walled garden during payment.
Many projects stop at "the MoMo debit worked" without properly linking payment success to opening Internet access — leading to disputes and ghost sessions.
What MobileOnNet industrializes
- A public portal per zone (
/portal/{slug}) with data plans. - Mobile Money collection via the DSS chain (including MMGate).
- Issuing credentials and the RADIUS session.
- Automatic cutoff (time / data) and admin tracking (revenue, sessions, payments).
As an Internet Zone operator, you don't need to integrate the payment API line by line: you configure the zone and the router. For an integrator, MobileOnNet is the "finished product" that avoids rebuilding payment + RADIUS + portal from scratch.
When to build it yourself vs. use MobileOnNet
Building it yourself makes sense if you're building a competing SaaS product or a very specific use case. MobileOnNet fits if your goal is to operate paid hotspots quickly, with local support (Douala / Yaoundé) and a subscription or commission model.
Next step
Contact DSS SAS for tenant access, a test on a pilot zone, and validation of your equipment (MikroTik by default). For the payment layer alone, mmgate.org documents the API / trust ecosystem around MMGate.
See also: Internet Zone Mobile Money · MikroTik captive portal