Subscription billing is broader than collecting the renewal payment
A subscription product has to keep the commercial relationship coherent before, during and after payment. Plans, trials, upgrades, billing periods, invoices, customer access and cancellations all exist whether the customer pays by card, M-PESA or another approved method.
That makes subscription billing different from a simple recurring-payment request. The billing system owns the subscription lifecycle; the payment method is one route for settling each invoice.
Start with the subscription model
For a Kenyan SaaS or digital product, define the commercial rules independently from the payment rail.
- Plan and price: what the customer receives and what it costs.
- Billing interval: monthly, annual or another schedule.
- Trial: whether access starts before the first paid invoice.
- Renewal date: when the next invoice becomes due.
- Upgrade and downgrade rules: when a plan change takes effect.
- Cancellation: when billing stops and when access ends.
- Grace policy: what happens if an invoice is not paid on time.
Those rules should not change because a customer chooses M-PESA instead of a card.
Use local-currency pricing deliberately
If the product sells to Kenyan customers, showing a clear KES price can reduce ambiguity around what will be charged. The billing system should store the invoice currency explicitly rather than infer it from the payment provider.
A card-first product can still keep global pricing logic, but its Kenyan offer should answer a practical question: is the customer buying a KES-priced plan, or is the customer buying a foreign-currency plan that their bank or card network converts? That choice affects product copy, support and reconciliation.
Trials should end in an invoice, not a provider-specific charge
Suppose a 14-day trial ends on 20 November. The billing system should decide what becomes due at that point. If the customer must actively authorize an M-PESA payment, the product can prepare the renewal and payment path before the trial expires instead of pretending the wallet will behave like a stored card.
A useful trial-to-paid sequence is:
- Create the first paid invoice before the trial ends.
- Tell the customer when access will become paid.
- Show the enabled payment methods.
- Let the customer authorize the chosen method.
- Change subscription state only after reliable payment evidence or according to the product's grace policy.
Upgrades and downgrades need a billing rule before they need a payment call
A product may apply a plan change immediately, at the next renewal, or using proration. The important point is that the product decides the invoice amount first.
For example, if a customer upgrades halfway through a month and the product uses proration, calculate the adjustment in the billing layer. The payment system should receive the resulting amount; it should not invent the proration policy.
M-PESA changes the renewal experience, not the subscription model
Safaricom's Daraja platform exposes M-PESA Express for merchant-initiated payment prompts. The request returns a CheckoutRequestID and the final outcome arrives asynchronously. If the callback is delayed, the M-PESA Express Query API checks that request using its CheckoutRequestID.
For a SaaS product, the useful separation is:
- Subscription renews according to the commercial schedule.
- Invoice becomes due.
- Customer chooses M-PESA or another enabled method.
- A payment attempt is created.
- The provider reports the result.
- The invoice becomes paid once sufficient evidence exists.
This lets the product support local payment behavior without rebuilding the subscription engine around one wallet.
Plan for failed renewals as a product state
A failed or expired payment should not immediately collapse the subscription into a generic error. Decide what the account becomes: active in grace, read-only, limited, suspended or queued for review.
The payment layer should supply reliable invoice and attempt state. The product layer should own entitlement policy.
Reconciliation should still look like subscription revenue
Finance should be able to connect every successful mobile-money payment to the same objects used for cards: customer, subscription, invoice, amount, payment attempt and reconciliation state.
Payment success and provider settlement should remain separate states. The customer can be paid while finance is still matching downstream settlement evidence.
What to decide before launching subscription billing in Kenya
- Which plans are priced in KES and which are not.
- Whether trials require payment details before access begins.
- When upgrades and downgrades take effect.
- Whether proration is used, and how the amount is calculated.
- Which local payment methods are genuinely enabled for the merchant.
- How customer-authorized renewals are presented.
- What happens during grace, suspension and reactivation.
- How invoices and provider transactions are reconciled.
For the broader Kenya category picture, see the recurring payments in Kenya guide. For the product-engineering implementation of M-PESA inside an existing SaaS system, see the SaaS subscription payments with M-PESA guide.
Sources
- Safaricom Daraja API catalogue: https://developer.safaricom.co.ke/apis
- Safaricom M-PESA Express API: https://developer.safaricom.co.ke/apis/MpesaExpressSimulate
- Safaricom M-PESA Express Query API: https://developer.safaricom.co.ke/apis/MpesaExpressQuery
