Home / Guides / Recurring billing and subscriptions / developers and product teams
DASNET business guide · Kenya

Recurring billing and subscriptions for developers and product teams | DASNET

Recurring billing requires clear consent, correct schedules, visible amounts, retry controls and a process for cancellations and failed payments.

This guide explains the workflow, how to prepare, which checks matter and how to handle common exceptions for developers and product teams.

Explore DASNETDeveloper documentation
Business owner reviewing recurring billing records
In this guide

Understand the workflow, apply the checklist, and confirm which payment channels and features are enabled for your account before using them in production.

What Recurring billing and subscriptions means for developers and product teams

Recurring billing requires clear consent, correct schedules, visible amounts, retry controls and a process for cancellations and failed payments. For developers and product teams, the goal is to integrate payment workflows without exposing secrets or creating duplicate effects. A reliable workflow makes the request, responsible person, reference and final outcome visible rather than leaving the process in disconnected messages.

The operational challenge

A common challenge is that asynchronous callbacks, retries and timeouts complicate the user experience. When the source request, payment status and business record do not line up, staff can repeat work or act on an assumption. A consistent process separates initiation from completion and records the evidence used to make a decision.

A practical end-to-end workflow

  1. Explain frequency, amount, renewal date, cancellation terms and payment method before enrolment.
  2. Store only the payment and consent data required by the configured flow.
  3. Monitor each renewal separately and distinguish retries from new billing periods.
  4. Provide a clear cancellation and support path and reconcile refunds or charge disputes.

A workflow shaped around this use case

  1. Keep provider credentials server-side and persist correlation IDs.
  2. Implement idempotent callback handling and explicit transaction states.
  3. Test delayed, duplicate, failed and malformed events before production.

How DASNET fits

DASNET is a business workspace for supported payment workflows and everyday business operations. Depending on account configuration, teams may use it to manage payment requests and collections, review transaction records, handle supported wallet and payout activity, organise invoices or bills, and keep customer and operational information together. The precise menu, channel and automation available to a business should be confirmed in its account. DASNET is not a promise that every payment rail, bank destination or provider feature is automatically enabled.

Controls and measures to review

  1. Track the number of unresolved items and how long they remain open.
  2. Separate pending, successful, failed, reversed and disputed outcomes in reports.
  3. Keep a clear owner for exceptions and a reference for every consequential action.
  4. Review access permissions and avoid storing credentials or sensitive authentication data in notes.
  5. Compare material payment totals with trusted provider or bank records.

Frequently asked questions

Does a scheduled charge always succeed?

No. Each attempt can fail, require action or remain pending; check the final result.

How should failed renewals be handled?

Follow a documented retry policy, notify the customer appropriately and avoid uncontrolled repeated attempts.

Can a customer cancel?

Offer the cancellation method and timing required by the applicable terms and laws.

Does DASNET support every subscription model?

Feature availability depends on the account and enabled billing workflows; verify before promising automation.

How does this apply to developers and product teams?

The main objective is to integrate payment workflows without exposing secrets or creating duplicate effects. Start with the workflow and controls on this page, then verify the exact features enabled for your DASNET account.

What should we do if a payment or record looks wrong?

Pause any consequential action, keep the non-sensitive reference and timestamp, check the trusted source record, and follow your documented support or reconciliation process. Never share PINs, OTPs, passwords or API secrets.

Does DASNET guarantee that every feature is enabled?

No. Product availability depends on account setup, permissions, provider approvals and enabled services. Confirm the live configuration before making operational commitments.

Related DASNET guides

Continue with these related workflows:

M-Pesa STK Push for developers and product teams · STK Push integration guide for developers and product teams · Safaricom Daraja API workflows for developers and product teams · Online payment links for developers and product teams · Customer payment requests for developers and product teams · Merchant payment collections for developers and product teams

Get started with DASNET