MikroTik Hotspot Billing with M-Pesa: A Kenya-Focused System Worth Scrutiny

What This System Actually Does

The repository, named miktrotik-hotspot-billing and branded as DenisTec, solves a specific problem: letting a WiFi hotspot customer pay for internet access with M-Pesa and then getting connected to a MikroTik router automatically. The target user is a small or medium hotspot operator in Kenya, where M-Pesa is the dominant mobile money service. The system pairs a customer-facing captive portal with an admin dashboard, a Node.js backend, and a PostgreSQL database. The README describes it as comprehensive, but the core loop is simple: customer picks a plan, pays via M-Pesa, the backend confirms the payment, and the router grants access. That loop is the whole point. If you do not need M-Pesa or MikroTik, this project has little to offer you.

How the Payment-to-Router Flow Works

The architecture diagram in the README shows three clients: the customer portal, the admin dashboard, and the MikroTik router, all talking to a central Node.js API. The data flow starts with the customer requesting plans from a public endpoint, then registering and logging in. Payment initiation is a POST to /api/public/payment, which presumably triggers an M-Pesa STK Push via the Daraja API. The backend then checks payment status through /api/public/payment/status/:id. Once confirmed, the customer hits /api/public/connect, and the backend talks to the MikroTik router to create a session. The README does not specify whether the router integration uses the MikroTik REST API or the older RouterOS API, nor does it describe how sessions are terminated. That is a gap. The session control feature exists on the admin side, but the mechanism for enforcing data limits and speed caps is not explained. The plan table lists data limits and speeds, so the system presumably pushes those to the router, but the exact command or configuration is absent from the material.

Getting It Running: Commands and Configuration

The quick start is straightforward. You need Node.js 18+, PostgreSQL 14+, a MikroTik router with API access, M-Pesa Daraja credentials, and optionally an Africa's Talking SMS API key. After cloning, you go into the backend directory, run npm install, copy .env.example to .env, and edit the file. The database setup uses Prisma: npm run db:generate, then npm run db:push, then npm run db:seed. Then npm run dev starts the backend. The frontend is a separate React app in the frontend directory, where you run npm install and npm run dev. The customer portal runs on localhost:3000, the admin dashboard at localhost:3000/admin, and the API health check at localhost:5000/health. The environment variables include DATABASE_URL, JWT_SECRET, M-Pesa keys, MPESA_SHORTCODE, MPESA_CALLBACK_URL, MIKROTIK_HOST, MIKROTIK_USERNAME, MIKROTIK_PASSWORD, and Africa's Talking credentials. The README also gives default admin credentials: [email protected] with password admin123. That is a red flag for production use, but it is common for local development.

The Plan Structure and Its Pricing Realism

The system ships with five pre-configured plans, all priced in Kenyan shillings. Basic 1 Hour costs KES 20 for 500MB at 5Mbps. Standard 6 Hours is KES 100 for 2GB at 10Mbps. Premium 24 Hours is KES 300 for 10GB at 20Mbps. Weekly is KES 1,500 for 50GB at 25Mbps, and Monthly Unlimited is KES 5,000 with no data cap at 50Mbps. These prices look plausible for the Kenyan market, but the README does not say whether they are editable through the admin dashboard or only via the seed script. The Prisma schema includes a Plan model, and the admin API has a /api/admin/plans endpoint, so plan management is implied. The data limits and speed values suggest the system can enforce them, but again, the enforcement mechanism is not documented. A hotspot operator should verify that the MikroTik integration actually applies these limits, because a plan that sells 5Mbps but delivers 50Mbps is a revenue leak.

Security and Operational Gaps

The README lists security features: HTTPS enforcement, JWT authentication, rate limiting, input validation, SQL injection protection via Prisma, and CORS configuration. Those are good claims, but they are claims. There is no evidence in the material that these are implemented correctly. The default admin password is a known credential, and if an operator forgets to change it, the whole system is exposed. The M-Pesa callback URL is a public endpoint that receives payment notifications; the README does not mention how the system verifies the authenticity of that callback. In practice, Daraja callbacks can be spoofed if not validated. The repository also has no license listed, which is a legal problem. You cannot legally use or modify code without a license, so an operator must contact the author or find another project. The README mentions a Voucher model as optional, which could be a fallback for customers without M-Pesa, but it is not described further.

What the Repository Does Not Tell You

The material is thin on several critical points. There is no release history, no last push date, and no information about the number of contributors or the project's age. The README says the system is cloud-ready with Docker support, and there is a docker-compose up -d command, but there is no docker-compose.yml content shown. The manual deployment steps mention Nginx and SSL, but no configuration files. The mobile app section is marked as optional and describes a future possibility, not an existing feature. There are no screenshots, no API documentation beyond endpoint lists, and no test instructions. The README is also truncated, so monitoring and analytics sections are cut off. For an engineer evaluating this for adoption, the missing information is as important as what is present. You cannot assess code quality, test coverage, or real-world reliability from this material alone.

Alternatives and How They Differ

The most direct alternative is a purpose-built hotspot billing platform like Spotipo or MikroTik's own User Manager. User Manager is a RADIUS-based solution that handles authentication, authorization, and accounting for MikroTik routers. It does not integrate with M-Pesa out of the box, so you would need a separate payment gateway and a custom script to link payments to user accounts. That is a different approach: instead of a monolithic web app, you get a router-native service that is proven and tightly integrated with RouterOS, but you must build the billing layer yourself. Another alternative is a generic payment gateway like Flutterwave or Paystack, which can handle M-Pesa payments, paired with a simple script that calls the MikroTik API to add a user. That approach is more modular but requires more glue code. The DenisTec project bundles everything into one stack, which is convenient but also means you depend on the project's own implementation of both payment and router control. If that implementation has bugs, you have no easy fallback.

Maintenance and Upgrade Costs

Because the repository has no license and no release history, estimating maintenance cost is difficult. The code uses Prisma, which means schema changes require running npm run db:generate and npm run db:push. That is a clear upgrade path for database changes, but the README does not describe a migration strategy for existing deployments. The frontend and backend are separate, so you must update both. The Docker support suggests a containerized deployment, but without a published image, you build from source. The lack of a license means you cannot legally fork and maintain it yourself unless the author grants permission. The default admin credentials and the absence of a documented password-change flow suggest that an operator must manually update the database or the seed script to change credentials. For a small operator, the cost of maintaining this system might be acceptable, but for a larger one, the unknowns are a serious risk. You should verify the repository's commit history and license before committing any resources.

Editorial conclusion

Adopt this system if you are a Kenyan hotspot operator who needs a single web-based tool that turns M-Pesa STK Push payments into MikroTik session grants, and you are comfortable running a young codebase with a default admin password and unverified security hardening. Do not adopt it if you require proven production reliability, formal licensing, or a mature community. Before deploying, verify the actual MikroTik API integration in the code, change the default admin credentials immediately, review the .env.example for all required variables, and test the M-Pesa callback flow end-to-end in a sandbox. The project shows a clear architecture, but its real-world behavior depends on details that only a code audit and a pilot deployment can confirm.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. README
4. Releases