Automation does not have to mean silent debit
A recurring collection system can automate most of the operating workflow even when the customer still has to authorize a particular mobile-money payment.
The useful question is not “Can every renewal happen without the customer?” It is “Which steps can the system perform reliably without guessing or bypassing the payment method's authorization rules?”
What can usually be automated
Invoice creation
If the commercial rule is known, the next invoice can be created automatically with the correct customer, amount, currency, billing period and due date.
Due-date and grace calculations
The system can calculate when the invoice becomes due, when grace begins and when a merchant-defined consequence becomes eligible.
Pre-due and overdue reminders
Messages can be scheduled automatically, but each message should re-check current invoice state before it is sent. A reminder that was valid yesterday may be wrong today if the customer already paid.
Payment-request preparation
The system can prepare the merchant, amount, reference, billing period and enabled payment methods. If the chosen method requires customer authorization, the customer still performs that step.
Provider callback processing
Callbacks and status-query responses can be matched to the correct attempt, stored, normalized and used to update the invoice.
Retry eligibility
A rules engine can decide whether another attempt is eligible. A confirmed final failure may allow retry. An unresolved attempt should normally block another collection until it is checked.
Reminder suppression after payment
Once the invoice is reliably paid, pending reminders and retry jobs should be cancelled automatically.
Reconciliation matching
Where references are strong enough, the system can automatically match provider transactions to invoices and send only exceptions to staff.
What depends on the payment rail
Customer authorization is not one universal behavior.
A rail may require approval for each payment, may support a standing instruction or mandate under specific conditions, or may expose a different recurring mechanism. The merchant should describe the actual capability available to that merchant account.
Do not advertise “automatic debit” merely because the rest of the billing workflow is automated.
What should stay human-visible
Automation should stop when evidence or policy is ambiguous.
- Two successful payments against one invoice.
- An amount mismatch.
- An unmatched payment with an unclear reference.
- A refund or dispute.
- A persistent unknown provider state.
- An exception to the merchant's normal grace or service policy.
The mature behavior is escalation, not guessing.
An automated month can still include customer approval
- Create the invoice automatically.
- Send the pre-due reminder automatically.
- Present an invoice-linked payment path.
- Let the customer authorize the chosen payment method where required.
- Process callback or status-query evidence automatically.
- Close the invoice automatically after reliable success.
- Cancel reminders automatically.
- Run reconciliation matching automatically.
- Send only exceptions to staff.
A useful automation boundary
Automate deterministic state transitions. Keep authorization boundaries honest. Escalate ambiguous evidence.
That combination produces a recurring collection operation that can scale without promising a payment capability the underlying rail does not provide.
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
