Afribit Wi-Fi.

Owning community Wi-Fi means owning the customer journey

Bitcoin Wi-Fi Kenya is not just a payment idea for Afribit. It is a practical attempt to own the full path from connection to payment to access. A customer should be able to join the network, choose a package, pay, and get online without losing time or money because two systems disagree.

Afribit currently uses third-party hotspot software where it makes sense. The builder goal is to create an operator-owned platform that Afribit can understand, test, improve, and connect deeply to Bitcoin payments while keeping package prices familiar in Kenyan shillings.

The business case is bigger than reducing a subscription bill. It is about data ownership, support visibility, local technical capacity, and a payment architecture that can grow with community needs.

A clear split between wireless access, routing, and business logic

The Afribit Wi-Fi pilot separates the system into practical layers. The access point provides the wireless connection. The MikroTik router enforces access rules. The Afribit cloud platform creates payment orders, decides who should receive access, and queues the router work.

That separation matters. The public website should not expose the router management interface. The access point should not become a billing system. The cloud should make business decisions, while the local network agent carries approved changes to the router from inside the network.

• A mobile captive portal for package selection.
• BTCPay Server invoices for Bitcoin payments.
• Voucher support for operator-issued access.
• Passkey-protected operator access.
• Router jobs that can be queued, reviewed, retried, and audited.
• Readiness checks that show configuration health without exposing secrets.

Bitcoin first, with prices people recognize

A Wi-Fi package advertised at KES 20 should remain KES 20, even when the Bitcoin exchange rate moves. Afribit's target model keeps package prices stable in Kenyan shillings while BTCPay calculates the satoshi amount when the invoice is created.

That quote can then be stored with the order for support and reconciliation. The user sees a familiar local price. Afribit receives Bitcoin through infrastructure it controls. The operator has a record that connects payment, device, package, expiry, and router action.

M-Pesa support is also part of the public direction, but it belongs behind careful testing. If a mobile money transaction succeeds while a Lightning settlement or access job is delayed, the user should not be charged again while systems reconcile the event.

The system has to pass real outage and recovery tests

Afribit Wi-Fi will be ready when reliability is proven by repeated tests, not when the dashboard has the most screens. A settled payment should create exactly one access grant. Expired access should be removed promptly. Duplicate or replayed payment events should never activate a device twice.

Operators also need evidence. They should know whether a router is online, whether the local agent is healthy, whether a job failed, and what recovery step is safe. That level of visibility protects the customer and the operator at the same time.

The first milestone is a reliable single-site Bitcoin pilot. From there, Afribit can add deeper network monitoring, M-Pesa-to-Lightning testing, multiple sites, and community access features on top of a dependable core.