Before an ISP opens a payment journey to subscribers, the team should be able to explain what happens from the customer's payment attempt to the intended service outcome. That explanation needs evidence from the configured collection method, the billing record and the subscriber-side test. A successful demonstration of only one step is not a complete launch check.
This guide recommends a test-planning process for an ISP preparing an M-PESA billing workflow. It does not assume that CENTRANET supplies sandbox credentials, a simulator, specific webhook controls or a particular retry policy. Confirm the supported capabilities with the actual payment provider and the current platform configuration before planning tests around them.
Identify the collection product and responsible parties
Record the merchant or collection product being used and the integration responsible for bringing the payment into the billing workflow. Identify the account owner and the staff authorized to configure, test and review it. Keep credentials in the approved secure location rather than including them in a test document.
Use the provider's current instructions for that product. Safaricom describes several business channels and payment capabilities in its M-PESA business guidance. Do not assume that instructions for one collection flow apply unchanged to another.
List the people responsible for provider setup, billing configuration, network service and customer support. Confirm how a test failure will be escalated and who can authorize a correction. A test plan is incomplete when it depends on an external account or approval that nobody involved can access.
Define a supported and authorized test method
Ask the integration owner which test facilities are available and what limitations they have. If the provider supports a non-production environment for the configured flow, follow its documented procedure. If a controlled live test is necessary, agree on the authorization, account and handling of the resulting transaction before carrying it out.
Do not invent a universal test amount, phone-number format or expected response time. Those details depend on the actual product and procedure. Record the method being used so that a reviewer can distinguish a simulated result from a real collection.
Limit the test scope. Use designated accounts and devices where appropriate, and protect existing subscribers from unintended package or service changes. Explain how test records will be identified and retained under the operator's normal process, including who is responsible for reviewing and closing any exception.
Establish the intended subscriber outcome
Select the test subscriber and confirm the intended package and service period. Document the relationship between that account and the payment attempt using the identifiers supported by the configured flow. Avoid relying solely on a phone number or display name when those values could refer to more than one service.
Describe the expected observations at each stage. These can include a provider transaction result, a corresponding billing record, the intended account state and successful subscriber access. Mark any stage that is outside the current test scope.
Separate recommendations from verified platform behavior. The CENTRANET features overview provides public product context, but the test plan should use the integration and workflow actually available in the workspace. Resolve an unsupported assumption before asking customers to depend on it.
Verify the network service independently
Before using a payment test to evaluate service activation, establish that the intended subscriber path can be tested under the operator's supported procedure. Confirm the relevant router or site, connection type and test device. Record the baseline result and any known limitation.
If the access path is not ready, keep that work separate from payment configuration. A failed browsing test should not automatically be described as a missing payment, and a recorded payment should not be treated as proof that the device has authenticated.
Use the current onboarding and support instructions for the installation. Preserve management access and recovery arrangements before making a live network change. The payment test should provide evidence about the agreed end-to-end journey, not become an excuse for speculative router adjustments that affect unrelated subscribers.
Observe one complete payment attempt
Carry out the authorized test and record its time and timezone. Capture the provider reference and result through the approved merchant or integration channel. Match the observed billing entry to the intended test account and package using the available supported identifiers.
Then check the intended service outcome. Record the account state and the subscriber-side result as separate observations. If the test involves a login or reconnect, describe what was performed and what happened. Avoid claiming that an untested lifecycle event was verified merely because the initial payment was recorded.
Keep screenshots and logs focused on the test. Remove credentials, tokens and unnecessary personal information before sharing them with another team. Retain the detailed evidence in the authorized record so that an exception can be investigated without repeating the transaction unnecessarily.
Investigate failures at the stage where they occur
When the result differs from the plan, describe the observation precisely. Examples of useful categories include an incomplete payment attempt, a provider result not yet matched in billing, an ambiguous subscriber match, an account-state discrepancy or an access failure after authentication.
Ask the responsible team to investigate the relevant stage. Do not assume that a router fault controls provider settlement or that an account correction will resolve an unavailable external payment service. Preserve the original transaction and test references so the teams can correlate their records.
Avoid repeated live payments as a diagnostic shortcut. Follow the approved process for investigating the existing attempt and for any subsequent retest. Record what changed between attempts so that a later successful result can be explained rather than attributed to an unrelated action.
Cover exceptions that the integration can actually test
Agree on a proportionate set of additional tests with the integration owner. Depending on supported facilities, these may concern an interrupted customer journey, an unresolved status, an ambiguous account match or a renewal after a service period ends. Do not simulate events by inventing callbacks or altering live records outside the documented process.
For each test, write the expected observation and the evidence needed to confirm it. If a case cannot be reproduced safely in the available environment, record the limitation and the provider guidance or engineering review used instead.
Keep load and retry testing within an approved plan. Do not generate a burst of real payment requests simply because an online article suggests a number. The objective is useful evidence about the deployed workflow, with clear authorization and a controlled effect on customers and provider systems.
Reconcile the test records and handle exceptions
Review the resulting provider and billing records for the same period and accounts. Match each authorized test attempt to its outcome, and explain any unresolved difference. Keep completed collections, failed attempts and any approved adjustments distinguishable in the test record.
Use the provider's supported merchant review process when additional transaction evidence is needed. Safaricom's business guidance describes available channels, but the specific permissions and actions must be confirmed for the account in use.
Do not erase an inconvenient test record to make the review appear complete. Give each exception an owner and a next action. Any reversal, refund or entitlement correction should follow the normal business and provider approval process, with its reason and observed outcome retained for the people responsible for the launch.
Make a documented launch decision
Summarize the tests completed, their results and the limitations that remain. Identify which collection method, account configuration and subscriber service were covered. A successful test of one flow does not establish that another provider or payment product has also been verified.
Give customer support the approved payment instructions and the escalation route for unresolved cases. Ensure staff can distinguish a payment investigation from a network-access problem and can locate the relevant evidence without asking customers to disclose secrets.
Expand the rollout only when the responsible team accepts the recorded scope and any remaining limitations. Contact CENTRANET to review the workflow available for your workspace and the evidence needed for a controlled billing launch.