DusuPay documents mobile-money collections through its API, but a documented payment method is not confirmation that your Zambian business can open the required merchant account or withdraw to its bank. Establish merchant eligibility and the settlement route before building checkout. Then treat the initial API acknowledgement, completed collection and bank settlement as separate events.
For a business evaluating DusuPay, the useful question is whether the whole collection-to-bank workflow fits. A customer-facing payment option is only one part of that decision. The official funds collection guide explains request acknowledgements, optional payment instructions and later notifications. It does not establish the merchant approval or settlement terms for your particular business. Those details remain questions for the provider rather than promises an integration article can make.
What should you establish before choosing DusuPay mobile money?
Write down where the business is registered, where its customers pay, the payment networks it needs and the account into which it expects settlement. Keep customer geography separate from merchant geography: a supported customer payment route does not, by itself, establish that the receiving business qualifies.
Ask DusuPay to confirm the legal entity it will contract with, the collection methods enabled on that account, supported transaction and settlement currencies, required onboarding documents and the permitted settlement destination. Request the current contract and applicable product documentation. Do not treat a sales demonstration or another merchant’s checkout as approval for your business.
An unanswered item belongs in the procurement decision. For example, “mobile-money collection documented, bank settlement destination awaiting confirmation” is a useful status. “Works in Zambia” is too broad when the evidence only describes API behaviour. Keep the unresolved item visible before anyone approves development work.
How does a collection actually progress?
The official guide describes a payment-method-specific request payload. Parameter errors can be returned immediately; otherwise the API acknowledges the request. The important operational distinction is that acknowledgement can still be followed by failure. Your order system should therefore retain the reference and show a pending payment rather than immediately release goods.
Some flows return a payment URL. In those cases, DusuPay instructs the merchant to redirect the customer there so they can complete payment. Other flows send payment instructions while the transaction remains in progress. A page that says “request received” should not present itself as a payment receipt.
Later notifications communicate the transaction outcome. The same guide also documents circumstances in which a failed status can subsequently become completed, with another callback by default. This makes a simple “first notification wins” implementation unsuitable without a deliberate status-change policy. DusuPay collection lifecycle.
Which evidence belongs beside each order?
Use a collection-state ledger rather than a single paid checkbox. The following is an editorial design aid, not a description of a finished Spout integration.
| Evidence observed | Suggested order treatment | Next question |
|---|---|---|
| Request acknowledged | Await payment outcome | Is the merchant reference recorded? |
| Payment URL returned | Offer the documented redirect | Did the customer reach the correct transaction? |
| Instructions received | Show relevant instructions | Is further customer action required? |
| Failure notification | Hold fulfilment | Could a later status correction apply? |
| Completion notification | Evaluate the authorised payment record | Does it match this order? |
| Settlement record | Reconcile separately | Can it be traced to the bank receipt? |
Record the local order reference, provider reference, observed status and observation time. Keep a history of changes rather than overwriting the only evidence. Restrict access to logs containing customer information. The ledger should let an operator explain what happened without asking a customer to resend sensitive account details.
How should late success and customer retries be handled?
Imagine a customer sees a failure message and starts another payment. Later, the first collection changes to completed. This is a hypothetical failure case, not a reported DusuPay incident or a measured frequency. It is useful because the documented status-change behaviour makes it a scenario worth testing.
Ask the developer to demonstrate how both references attach to the same order, how duplicate fulfilment is prevented and how an operator recognises excess payment. Do not silently discard the later success merely because a local timeout expired. Equally, do not send a second shipment because a completion event arrived again.
DusuPay documents an allow_final_status_change parameter. Choosing its value is a business and reconciliation decision, not a generic optimisation. Establish how late customer payments will be investigated under the selected behaviour. The documentation describes the switch; it does not relieve the merchant of resolving a customer who actually paid.
DusuPay separately documents a dashboard settlement request: open Settlement Requests, choose New Settlement Request, then select the merchant account, currency and source wallet. Enter the requested amount, select the merchant account bank, create the request and submit it for processing. These are instructions for requesting finance-team handling, not confirmation that money has reached the bank. The guide ends by returning to the settlement-request report; retain that request reference alongside subsequent bank evidence. This procedure does not establish which bank a Zambia-based applicant can register, its approval outcome or a payout deadline. DusuPay funds settlement.
What must the settlement enquiry contain?
Copy this original enquiry sheet into your internal approval record:
- Merchant legal entity and registration jurisdiction: awaiting confirmation.
- Requested customer networks and payment methods: list explicitly.
- Collection currency and credited balance currency: confirm separately.
- Settlement bank account ownership and jurisdiction: provide through the approved onboarding route.
- Settlement initiation, deductions and exception process: request current written terms.
- Failed collection, reversal and refund handling: identify the applicable procedure.
- Statements or exports available for reconciliation: request a sample with personal data removed.
- Contact route for a disputed or unmatched transaction: record the provider’s response.
The collection guide describes cross-currency collection behaviour, including conversion between request and provider currencies. That is not a quoted settlement exchange rate, a guarantee of withdrawal eligibility or a settlement timetable. Ask for the specific terms that govern your account rather than inferring them from a sample API payload.
What should happen before checkout is enabled?
Prepare a test record covering an acknowledged request that fails, an abandoned redirect, an instruction requiring customer action and a later corrected status. Use the provider’s authorised testing route. Keep real customer messages, live collections and fulfilment actions outside that rehearsal unless separately authorised.
For each case, retain the expected order state, actual event history, customer-facing wording and unresolved defect. A successful request alone is insufficient evidence of a working commercial process. Approval should cover both the software behaviour and the merchant account arrangements.
Explore Spout’s online payments service or start a project enquiry with the outstanding questions and your intended checkout workflow. Provider eligibility and settlement commitments must come from the applicable provider agreement.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.