Scope a payment project by answering: 1) Which countries (each adds payment methods and compliance), 2) Which payment methods (card, M-Pesa, bank transfer, USSD, mobile money), 3) One-time or recurring, 4) Marketplace or direct, 5) Existing codebase or greenfield, 6) Who owns post-launch maintenance. Explicitly list exclusions in your proposal. Get written approval of the scope before starting.
Complete Discovery Checklist
Ask all of these before writing your quote:
Countries and currencies:
Which country or countries will customers pay from? (Nigeria? Kenya? Ghana? Multiple?)
Should the system handle multiple currencies or one primary currency?
✓Ask all discovery questions before writing a quote — missing one country or payment method changes the price significantly.
✓Explicitly list exclusions (what is NOT in scope) — this prevents scope creep.
✓Each additional country or payment method typically adds 30-50% to the project scope.
✓Get written approval of scope before starting work — email confirmation counts.
✓Use a change request process for anything outside the agreed scope.
Frequently Asked Questions
How do I handle a client who keeps adding requirements after we agreed on scope?
Use a formal change request process. When a new requirement comes in: stop, document it, estimate the additional time and cost, send a Change Request document, and wait for written approval before doing the work. "I'd love to add M-Pesa. That's a Change Request — additional KES 35,000 and 5 business days. I'll send the CR document now." Most clients accept this once they understand it is standard practice.
What should I do if I under-scoped a project and it is taking much longer than estimated?
Be transparent early, not late. As soon as you realize the scope was incorrect, send the client a note: "While building this, I discovered [X] is more complex than the initial scope estimated. This will take 5 additional days. I can absorb 2 of those days in goodwill, but the remaining 3 days will need a CR at our agreed rate." Clients respect early communication and resent last-minute surprises.
Should I scope payment testing into the project or is it assumed?
Always scope testing explicitly and describe what is included: "Unit tests for webhook handler (signature validation, idempotency, event routing). Integration test: full charge.success flow using Paystack test mode. Test coverage report included." This signals professionalism and prevents clients from asking "is there testing?" as a scope creep question later.
Learn Paystack Integration
KES 2,999
The definitive guide to building payment systems with Paystack — from your first transaction to production-grade payment infrastructure across Africa. 9 modules, 47 lessons. Free preview available.
