Recurring-payment products often blur three different concepts. Keeping them separate prevents misleading autopay claims.
Consent
Consent is the customer's agreement to the commercial arrangement or to a defined use of their information or payment process.
A customer can consent to a monthly membership without giving the merchant authority to debit a wallet silently every month.
Payment authorization
Authorization is the approval required for a specific payment attempt under the chosen rail.
For example, an M-PESA Express request is presented to the customer's phone and the customer approves it in the provider-controlled flow.
Mandate or standing instruction
A mandate or standing instruction can authorize future payment actions according to the rules of that specific rail.
Some payment methods support this. Others require fresh customer action for each payment. The product should describe the actual enabled capability rather than apply one model to every wallet.
Why the distinction matters
- It keeps customer expectations accurate.
- It prevents a billing rule from being mistaken for debit authority.
- It lets the same recurring invoice model work across customer-authorized and mandate-based methods.
A safe product model
Store the commercial recurring rule separately from the payment authorization or mandate evidence used by each payment method.
Then the billing engine can know that money is due without pretending it always has permission to collect it automatically.
What the product should store
A recurring billing system benefits from keeping the commercial agreement, payment authorization evidence and any reusable mandate reference as separate fields or records.
That lets support answer different questions: what did the customer agree to buy, what did they authorize for this payment, and does any provider-approved instruction exist for future collections?
Avoid consent dark patterns
Do not hide a future-payment permission inside a generic checkout acceptance. If a rail supports a standing instruction or reusable mandate, the customer-facing flow should explain the scope, frequency or conditions in the form required by that provider and applicable rules.
Cancellation should update both layers where necessary
Cancelling a subscription can stop future commercial obligations. Cancelling a payment mandate can remove payment authority. Those actions may need to happen together, but they are not conceptually identical.
The product should therefore know whether the customer has cancelled the service, the payment instruction, or both, and should not keep attempting payment simply because one record remained active.
A useful implementation checklist
- Show the merchant, amount and purpose before a customer-authorized payment.
- Keep provider authorization evidence linked to the payment attempt.
- Keep recurring commercial consent linked to the subscription or obligation rule.
- Do not infer a reusable mandate from one successful wallet payment.
- Provide a clear path to stop future commercial renewals and any applicable mandate.
Source
Safaricom Daraja API catalogue: https://developer.safaricom.co.ke/apis
