How to Configure Automated M-Pesa and Stripe Payment Gateways for ISP Billing Platforms
Internet service providers need payment systems that do more than accept money. A good payment integration should identify the customer, match the transaction to an invoice or package, confirm the result, renew or activate service, and record the transaction for reconciliation.
This is especially important for ISPs that serve prepaid WiFi customers, PPPoE subscribers, fixed-line businesses, apartment networks, and mobile-first markets. M-Pesa can provide a convenient mobile-money route, while Stripe can support eligible online card and subscription workflows. When both channels are connected to an ISP billing platform, customers can choose a convenient payment method without forcing staff to verify every transaction manually.
This guide explains how to design and configure automated M-Pesa and Stripe payment gateways for ISP billing platforms, including customer references, callbacks, webhooks, invoices, MikroTik, RADIUS, PPPoE, HotSpot, renewals, security, and reconciliation.
Internet providers can evaluate
Important: M-Pesa products, Stripe availability, currencies, merchant approvals, recurring-payment capabilities, and gateway connectors vary by country and account. Confirm the current requirements shown by your payment provider and ISP billing platform before going live.
What automated payment integration means for an ISP
Automated payment integration connects a payment gateway to the ISP’s billing and access systems.
The customer chooses a plan or invoice and starts payment. The gateway processes the transaction. A callback or webhook reports the result to the billing platform. The billing platform validates the event and updates the customer account. If the payment is successful, the system can renew the service, issue a voucher, update a RADIUS record, or apply the correct MikroTik policy.
A typical workflow is:
1.The customer selects a plan or opens an invoice.
2.The billing platform creates an internal order or payment reference.
3.The customer selects M-Pesa or Stripe.
4.The gateway processes the payment.
5.The provider sends a server-to-server callback or webhook.
6.The billing platform verifies the event.
7.The payment is matched to the customer and invoice.
8.The invoice is marked paid only once.
9.The subscriber account is renewed or activated.
10.The customer receives a confirmation.
11.The transaction appears in reports and reconciliation.
Providers can
M-Pesa and Stripe: what each gateway does
M-Pesa for mobile-money payments
M-Pesa integrations vary by country and product. In a common Daraja M-Pesa Express flow, the merchant initiates a payment prompt to the customer’s registered phone. The customer confirms with a mobile PIN, and the result is sent to a callback URL.
The callback may include a merchant request identifier, checkout request identifier, result code, description, amount, receipt number, transaction date, and phone number. A billing system should store the gateway references and match them to the internal order or invoice.
Other M-Pesa products may use a paybill, till, customer-to-business flow, or a different approved connector. Do not assume that the STK Push process is identical across all countries or products.
Stripe for online and subscription payments
Stripe can support eligible online payment and subscription workflows. Depending on the account and integration, an ISP may use one-time payments, invoices, payment links, Checkout, subscriptions, saved payment methods, refunds, or dispute handling.
Stripe’s official documentation recommends using HTTPS webhook endpoints to receive asynchronous events. Webhooks can report events such as successful payments, subscription renewals, failed invoice payments, disputes, and actions requiring customer authentication.
The customer’s browser redirect is not enough to confirm a payment. The server should verify the Stripe event and apply an internal billing action only after the correct event is received and validated.
Before configuration: prepare the ISP billing platform
Do not begin with gateway credentials. Start by defining the billing model and customer workflow.
Define service plans
Create packages with clear names, prices, currencies, billing periods, speeds, data limits, device limits, and expiry rules.
Examples include:
•One-hour WiFi pass
•Daily hotspot voucher
•Weekly prepaid package
•Monthly PPPoE subscription
•Residential broadband plan
•Business internet plan
•Premium speed package
•Installation charge
•Static IP add-on
Create customer and invoice references
Every purchase should have a unique internal reference. It may be an invoice number, order ID, subscription ID, voucher purchase ID, or customer account reference.
Use this value when creating the payment request. The same reference should be available when the callback or webhook arrives.
Define payment statuses
Use clear internal statuses such as:
•Created
•Pending
•Paid
•Failed
•Cancelled
•Expired
•Refunded
•Reversed
•Disputed
•Unmatched
Do not treat every gateway response as a successful payment. A request accepted for processing is not necessarily a completed payment.
For an ISP that wants to centralize these records,
Step 1: Configure M-Pesa credentials and environment
The exact M-Pesa setup depends on the country and product. For a Daraja-style integration, the provider generally needs a developer or merchant account, sandbox credentials for testing, and approved production credentials for live payments.
Typical requirements may include:
•Consumer key
•Consumer secret
•Shortcode or till information
•Passkey or signing material
•Supported transaction type
•Customer phone format
•Callback URL
•Account reference rules
•Transaction description
•Production approval
Keep sandbox and production credentials separate. Never place live secrets in front-end code, public repositories, screenshots, or ordinary support messages.
Configure the M-Pesa payment request
The billing platform should send the payment request with the correct merchant information, amount, phone number, account reference, transaction description, and callback URL.
Validate:
•Currency and amount
•Phone-number format
•Maximum and minimum amounts
•Account-reference length
•Transaction type
•Customer’s selected invoice or package
•Callback URL accessibility
The internal reference should be short enough for the selected M-Pesa product while remaining unique. If the gateway imposes a character limit, store the full internal order ID separately and use a compact external reference.
Configure the M-Pesa callback
The callback endpoint receives the result after the customer completes, cancels, or fails the payment.
The handler should:
1.Receive the request over HTTPS.
2.Validate the expected structure.
3.Read the merchant and checkout identifiers.
4.Check the result code.
5.Extract the receipt, amount, date, and phone where available.
6.Match the event to the internal payment reference.
7.Confirm amount and currency.
8.Prevent duplicate processing.
9.Mark the payment status.
10.Queue account renewal or provisioning.
11.Return the expected response quickly.
A successful callback does not mean that the customer should receive unlimited or duplicate value. Check that the payment has not already been applied and that the invoice is still eligible for settlement.
Handle missing or delayed callbacks
Mobile-money callbacks can be delayed or may require reconciliation when network or gateway conditions change. Build a reconciliation process that lets staff search by checkout request, merchant request, phone, amount, date, or receipt number.
If the provider offers a transaction-status query, use it according to the product’s documented rules. Do not ask the customer to pay repeatedly while the first transaction remains unresolved.
Step 2: Configure Stripe for ISP payments
Stripe setup normally begins with an eligible Stripe account, a connected business profile, supported country and currency, and an approved payment method.
Decide which Stripe model the ISP needs:
•One-time package checkout
•Invoice payment
•Payment link
•Monthly subscription
•Subscription with trial
•Customer portal
•Saved payment method
•Refund and dispute workflow
For prepaid hotspot access, a one-time checkout may be appropriate. For monthly PPPoE or fixed-line plans, a subscription or recurring invoice may be useful where supported.
Configure Stripe products and prices
Map each ISP service plan to a Stripe product or price as appropriate. The internal billing platform should remain the source of truth for the customer’s network package and access rules.
Store references such as:
•Internal customer ID
•Internal invoice ID
•Package ID
•Stripe customer ID
•Stripe checkout session ID
•Stripe payment intent ID
•Stripe subscription ID
Never rely only on an email address to match a payment to an ISP account. Use an internal customer or invoice reference in metadata where supported.
Create a secure Stripe webhook endpoint
Stripe’s official documentation describes publicly accessible HTTPS webhook endpoints for receiving event data. The endpoint should accept the raw request body and verify the Stripe-Signature header using the endpoint signing secret.
The handler should:
1.Receive the raw request body.
2.Verify the Stripe signature.
3.Reject invalid signatures.
4.Check the event ID for duplicate processing.
5.Read the event type.
6.Match the Stripe object to the ISP customer or invoice.
7.Confirm amount and currency where relevant.
8.Apply the internal payment status.
9.Queue service renewal or provisioning.
10.Return a successful response promptly.
Stripe recommends returning a successful status quickly before complex processing. Put longer billing or network actions into a queue so that a slow MikroTik or RADIUS operation does not cause unnecessary webhook retries.
For a platform comparison,
Stripe events for recurring ISP subscriptions
Recurring internet service requires careful event handling. Important event types can include:
•invoice.paid
•invoice.payment_failed
•invoice.payment_action_required
•invoice.upcoming
•payment_intent.succeeded
•Subscription status changes
•Refund and dispute events
A successful recurring invoice can renew the subscriber. A failed invoice should notify the customer and start the provider’s recovery or grace-period workflow. An event requiring additional customer authentication should send the customer to the required action rather than suspending immediately.
If the subscription becomes past due, unpaid, or cancelled according to the configured policy, the ISP may restrict or suspend network access. Document the rule and apply it consistently.
Do not use the browser redirect as the only source of subscription status. Use verified server-side events and reconcile the Stripe dashboard with the ISP billing ledger.
Step 3: Connect payment status to MikroTik and RADIUS
A payment gateway should not directly change a router without passing through the billing and authorization layer.
The recommended sequence is:
1.Gateway confirms payment.
2.Billing platform marks invoice or order paid.
3.Billing platform changes the subscriber status.
4.RADIUS or provisioning service updates authorization.
5.MikroTik applies the profile on login or reauthorization.
6.Active sessions are handled according to policy.
7.Customer receives confirmation.
For PPPoE, the provider may renew the customer’s subscription and return the correct speed, IP pool, session, or expiry attributes through RADIUS.
For HotSpot, the provider may activate a voucher, extend a package, apply a data or time limit, or permit captive-portal access.
The customer may need to reconnect before a profile change applies. Test upgrades, downgrades, suspension, and restoration with active sessions.
Providers can
Step 4: Build payment reconciliation
Automated payment processing still needs reconciliation. The billing system should compare internal invoices with gateway events, receipts, settlement records, refunds, and disputes.
Review:
•Successful payments
•Pending payments
•Failed transactions
•Reversed transactions
•Refunds
•Disputes
•Duplicate callbacks
•Unmatched payments
•Amount differences
•Currency differences
•Gateway fees
•Settlement timing
Create an exception queue for transactions that cannot be matched automatically. Staff should be able to search by internal reference, M-Pesa receipt, Stripe payment intent, checkout session, phone number, amount, or date.
Do not manually mark a payment as paid without an audit note and permission. Incorrect manual settlement can grant service without payment or create an inaccurate customer balance.
Step 5: Add idempotency and duplicate protection
Payment providers may retry callbacks or webhooks. Networks may time out even though a request succeeded. Customers may refresh a payment page or click a button twice.
Use idempotency at multiple levels:
•Gateway request ID
•Callback or webhook event ID
•Internal invoice ID
•Provisioning job ID
•Voucher issue ID
•Renewal period
Before applying a payment, check whether the reference has already been processed. Before renewing service, check whether the current period was already extended.
This prevents duplicate vouchers, double renewal, duplicate credits, and repeated service activation.
Security checklist for M-Pesa and Stripe gateways
Protect gateway credentials, API keys, webhook secrets, signing keys, router credentials, RADIUS shared secrets, and database access.
Use HTTPS for customer pages, callbacks, webhooks, and administration. Validate signatures and reject malformed or replayed requests.
Never trust a payment status supplied by a customer’s browser. Never ask customers to send PINs, passwords, API keys, or full card details through support chat.
Use role-based permissions. Finance staff may reconcile transactions, while network staff may manage access profiles. Agents should see only assigned customers or voucher stock.
Log account, payment, refund, plan, and provisioning changes. Monitor repeated failures, unusual transaction volumes, duplicate events, and unexpected mass status changes.
Back up the billing database, gateway configuration, invoices, customer records, voucher batches, RADIUS data, and router configuration. Test restoration regularly.
Testing before production
M-Pesa test cases
•Successful customer approval
•Customer cancellation
•Wrong PIN or failed authorization
•Timeout or delayed callback
•Duplicate callback
•Incorrect amount
•Incorrect account reference
•Reversed transaction
•Unmatched receipt
•Customer retries payment
Stripe test cases
•Successful one-time payment
•Failed payment
•Payment requiring customer action
•Duplicate webhook
•Subscription renewal
•Failed renewal
•Refund
•Dispute
•Cancelled subscription
•Webhook signature failure
•Delayed event
Network test cases
•New subscriber activation
•PPPoE login
•HotSpot voucher login
•Plan upgrade
•Plan downgrade
•Expiry
•Grace period
•Suspension
•Active-session termination
•Restoration after payment
•RADIUS or router outage
Run the tests with a small set of internal or pilot customers before opening the gateways to the full subscriber base.
Common mistakes to avoid
Do not treat a payment request accepted by the gateway as a completed payment. Wait for the final result.
Do not grant access based only on a browser redirect or customer screenshot.
Do not use the same callback logic for every M-Pesa product or country. Confirm the documented request and result format.
Do not process Stripe webhooks without verifying the signature and raw request body.
Do not perform slow router operations before acknowledging a webhook. Queue the work and make it retry-safe.
Do not allow the same invoice or renewal period to be applied twice.
Do not suspend customers immediately after one failed recurring payment without a documented grace and recovery policy.
Do not store payment secrets in front-end code, public repositories, spreadsheets, or ordinary support messages.
Choosing an ISP billing platform
When evaluating SopraEnt, Xenfi, or another ISP billing platform, ask for a demonstration of the complete workflow:
1.Customer registration
2.Plan selection
3.M-Pesa payment
4.Stripe payment
5.Callback or webhook confirmation
6.Invoice settlement
7.PPPoE or HotSpot activation
8.Renewal
9.Failed payment recovery
10.Refund or dispute handling
11.Reconciliation
12.Reports and export
Also confirm current country coverage, currencies, payment gateways, supported router models, RouterOS versions, RADIUS integration, customer portal, support, pricing, and terms.
To begin an evaluation,
Conclusion
Automated M-Pesa and Stripe payment gateways can make ISP billing faster, more convenient, and more reliable. The value comes from connecting payments to accurate invoices, customer references, account status, MikroTik, RADIUS, PPPoE, HotSpot, notifications, and reconciliation.
The technical priorities are clear: use verified callbacks and webhooks, protect secrets, match payments with unique references, prevent duplicate processing, handle pending and failed states, queue network actions, and test the complete customer lifecycle.
Start with one plan, one router, one payment flow, and a small pilot group. Expand only after successful payments, failures, refunds, renewals, expiry, and restoration work as expected.
Frequently asked questions
Can M-Pesa payments be connected to ISP billing automatically?
Yes, when the ISP has an approved M-Pesa product or gateway and a billing integration that can receive and verify payment results. The system should match the transaction to an invoice or package and handle delayed or failed callbacks.
Can Stripe handle recurring ISP subscriptions?
Stripe supports subscription and recurring-payment workflows for eligible accounts and countries. The ISP should use verified server-side events to renew service and handle failed or action-required invoices.
What is an M-Pesa callback?
It is a server-to-server notification that reports the result of a payment request. The callback may include transaction identifiers, result codes, receipt information, amount, date, and phone details depending on the product.
What is a Stripe webhook?
A Stripe webhook is an HTTPS endpoint that receives event notifications from Stripe. It can report successful payments, failed invoices, subscription changes, refunds, disputes, and other asynchronous events.
Should the ISP trust a payment redirect?
No. A redirect only shows that the customer returned to a page. Confirm payment through a verified M-Pesa callback, Stripe webhook, provider API, or controlled reconciliation process.
How does successful payment activate internet service?
The billing platform marks the invoice or order paid, changes the customer status, and triggers a voucher, PPPoE, RADIUS, MikroTik, or HotSpot update according to the configured integration.
What happens when payment is pending?
The account should remain pending until the gateway confirms the result. Do not issue duplicate vouchers or renew the same subscription while the transaction is unresolved.
How do I prevent duplicate payment processing?
Store and check gateway event IDs, internal invoice IDs, transaction references, provisioning job IDs, and renewal periods. Make payment and access operations idempotent.
Where can I evaluate ISP billing systems?
You can
