This guide is for buyers who already know they need more than a payment link
The Kenya buyer checklist explains the capabilities to look for. This scorecard is for a later stage: comparing actual vendors and forcing the demo to prove the claims.
Score the vendor in eight areas
| Category | Suggested weight | What strong evidence looks like |
|---|---|---|
| Payment access | 15% | Methods needed for the actual merchant and markets are production-enabled |
| Billing model | 15% | Invoice/obligation state is provider-independent |
| Payment state | 15% | Pending, unknown, failed, expired and paid are distinct |
| Recovery | 15% | Failure-reason rules, safe retry, wallet fallback and stop conditions |
| Reconciliation | 15% | Invoice-to-provider matching, exception handling and settlement separation |
| Operations | 10% | Useful exception queues and low manual-touch workflow |
| Engineering | 10% | Idempotency, stable attempt IDs, append-only event history, callback dedupe and stable API |
| Expansion/portability | 5% | Provider and market changes do not require a billing rewrite |
Use a 0–5 score for each area. For a total out of 100, sum (category score ÷ 5) × category weight. Adjust the suggested weights to reflect your merchant's needs, keeping their total at 100%. A regional SaaS business may weight provider portability heavily; a local gym may care more about recovery, matching and operations.
Demo script: make the vendor show failure, not just success
- Create one monthly invoice for a customer.
- Start an M-PESA attempt.
- Make the attempt unresolved. Show whether a second attempt is blocked.
- Resolve the first attempt as failed and switch to another enabled wallet.
- Complete the second attempt and show the invoice closing once.
- Test a delayed or contradictory success event after the second attempt has paid the invoice. Show whether the vendor preserves the evidence, raises a state-conflict or duplicate-success exception, and avoids reopening or charging the invoice.
- Show how finance finds the provider reference and reconciliation status.
- Show an external payment satisfying the invoice.
- Show how a second country/provider is configured without changing the merchant's billing API.
Questions for operations
- What does staff see first each morning?
- Can they distinguish failed, unknown and unmatched payments?
- How many cases still require provider-dashboard lookup?
- Can reminders be stopped immediately after an external payment?
Questions for finance
- How is a provider transaction matched to an invoice?
- Can finance see gross amount, provider reference and reconciliation state?
- How are duplicates and amount mismatches surfaced?
- How is settlement represented separately from customer payment status?
Questions for engineering
- Does each payment attempt have a stable ID and an append-only event history?
- How are callbacks deduplicated?
- How does the API represent UNKNOWN?
- What happens if a worker retries after a timeout?
- How are provider-specific statuses preserved?
Questions for regional expansion
- Which countries and currencies are genuinely enabled today?
- Which claims depend on merchant-specific approval?
- Can one market use a different PSP without rebuilding billing?
- What are the settlement and onboarding requirements per market?
Red flags in a sales demo
- “Supports M-PESA” is the answer to every workflow question.
- No explicit Unknown state.
- Retries create a new invoice.
- The vendor cannot show what happens after a late callback.
- All provider capability is treated as globally available to every merchant.
- Finance reconciliation is described as downloading a CSV and working it out manually.
Make the 0–5 rating evidence-based
Use the same scoring anchors for every shortlisted vendor. Scores describe your observed demonstration, not an external market ranking.
| Score | Evidence standard |
|---|---|
| 0 | Capability absent or contradicted by the demo |
| 1 | Claimed in a presentation; no working proof |
| 2 | Partial demonstration; key failure path untested |
| 3 | Working demonstration for the main case |
| 4 | Main and negative cases demonstrated with traceable records |
| 5 | Repeatable evidence, clear operations ownership and production eligibility confirmed for your account |
Some items should be gates, not just weighted preferences: legal merchant/provider eligibility, a valid customer authorization model, no second collection while the prior result is unknown, preservation of provider evidence, and a traceable settlement beneficiary. A vendor failing a mandatory gate should not win simply by compensating with a high marketing or UI score.
Retain a buyer evidence pack
For every vendor, keep the same anonymized test invoice, timestamps of each attempted action, screenshots or exports of system behavior (not fabricated payment confirmations), documented route/fee eligibility and the name of the person who demonstrated or verified the result. Then complete the scorecard from those observations.
The Kenya buyer checklist covers whether a merchant needs this kind of system. This scorecard should only be used after that first decision.
Downloadable scorecard
Companion Google Sheets vendor scorecard: https://docs.google.com/spreadsheets/d/1Rly7yYraLDSnTXckxNRQ5kVtU-juX3wwn-rViWFPL50/edit
The winner should be the system that removes the merchant's actual recurring-payment work with the fewest unproven assumptions, not the vendor with the longest payment-logo page.
