A Nigerian marketplace does not need a custom wallet simply to share one customer payment with a seller. Paystack supports subaccounts and transaction splits. But when you hire a developer, the real cost depends on whether your platform merely divides a settlement or must manage sellers, commissions, refunds, disputes and payouts over time.
For a business comparing quotes in 2026, these are illustrative one-off engineering planning allowances, not surveyed Nigerian market averages, Paystack charges or fixed prices:
| What you are commissioning | Planning allowance | Main deliverable |
|---|---|---|
| Configure a fixed split on a Paystack payment page | ₦0–₦150,000 | Provider setup, bank details and a test transaction |
| Add one-vendor split checkout to an existing app | ₦450,000–₦1 million | Server-side checkout, verified payment state, subaccount mapping and basic reconciliation |
| Multi-vendor marketplace split integration | ₦1 million–₦2.5 million | Seller onboarding, commission rules, multiple recipients, admin visibility and refund handling |
| Custom delayed payouts or complex settlement operations | ₦2.5 million–₦6 million+ | Separately scoped ledger, approvals, transfers, exception recovery and deeper testing |
These ranges are my initial scoping allowances for development work. They exclude payment processing fees, third-party software, legal/compliance advice and ongoing support. A basic fixed split can be configured without a developer. The ₦450,000+ engagement becomes realistic when money movement must stay consistent with the application’s orders and seller records.
First decide: split settlement or control the payout later?
This is the decision that changes the project.
Paystack split settlement distributes the settlement from a transaction among your main payout account and one or more configured subaccounts. Paystack’s split-payment documentation describes creating a subaccount and initializing a transaction with its code. Its multi-split documentation supports multiple recipients and flat or percentage split configurations.
Delayed vendor payout is a different requirement. Suppose a customer pays today but your platform promises the seller payment only after a service is completed next week. You cannot assume a normal Paystack split gives you escrow, a reversible hold or the right to retain third-party funds. That requires a separate operational and provider-approval discussion, potentially involving transfers, permitted account arrangements and legal obligations.
If your marketplace promises buyer protection, delayed release or dispute-managed funds, confirm the permitted payment model with Paystack and a qualified adviser before approving a developer quote. Do not build an informal escrow system around a bank balance.
How a ₦100,000 order should be recorded
Imagine a marketplace booking a contractor for ₦100,000. The platform charges a 15% commission, so the intended allocation before gateway charges is ₦15,000 to the platform and ₦85,000 to the contractor.
That simple calculation does not yet answer:
- Which party bears the gateway processing fee?
- What happens when the contractor’s bank details are wrong?
- Can the customer request a partial refund after work starts?
- Does the order become confirmed when checkout redirects, or only after verified payment?
- Can a staff member trace the provider’s settlement reference back to the booking?
Paystack documents fee-bearer options for single splits and multi-splits. Your quote should specify the actual rule instead of silently subtracting gateway fees from the seller’s agreed amount.
I would model gross amount, gateway fee, platform commission, vendor entitlement, refund adjustment and settlement status as separate concepts. One paid flag on an order is not a sufficient financial record.
Three implementation routes
1. Configure a payment page and subaccount
Use this when the recipients and percentages are fixed, and you do not need custom order or vendor workflows. Paystack’s transaction-splits support guide describes using subaccounts or split groups on supported payment pages.
This can be the right low-cost purchase for a school allocating fee categories or a small business sharing proceeds with a partner. Test the recipient bank details and who bears fees. Do not commission a custom dashboard merely to reproduce a configuration the provider already supports.
2. Integrate splits into an existing marketplace
A marketplace needs to know which verified seller belongs to the purchased service, and which commission rule applied at the moment of purchase.
A responsible implementation should:
- Store the seller and verified payout-account reference under business control.
- Calculate the order total and commission on the server.
- Create a unique internal order and payment reference.
- Initialize the Paystack transaction with the appropriate subaccount or split configuration.
- Verify the successful charge server-side before confirming the order.
- Process signed gateway events idempotently, so duplicate notifications do not create duplicate commissions.
- Preserve the exact allocation used for that transaction even if the seller’s commission changes later.
- Make the order, gateway reference and recipient allocation visible to authorized support staff.
Paystack’s payment verification and webhook guidance support the trusted-payment side. The marketplace’s seller rules and order state remain your developer’s responsibility.
3. Commission a custom payout workflow only when the business needs it
A custom payout engine may be justified if the platform has approved delayed disbursements, multiple fulfilment milestones, manual reviews, vendor deductions or more complex reconciliation requirements.
This is not just an additional Paystack API call. It can require a transaction ledger, payout eligibility rules, authorization controls, retries, reversal handling, audit logs, staff tools and clear operational ownership. Check the available Paystack transfer documentation and provider eligibility before assuming transfers can be used for your exact business model.
If your actual need is to collect monthly fees from sellers, that is a different problem from splitting each sale. See the Paystack subscription integration cost guide.
Refunds and disputes are where cheap integrations become expensive
A refund can affect a buyer’s payment, the platform’s commission and the seller’s expected settlement. Those are related but not identical records.
Paystack supports partial and full refunds with asynchronous status updates. A developer should not mark a refund complete merely because the initial refund request was accepted.
Before accepting delivery, ask the team to demonstrate a full refund, a partial refund, a refund still processing, and a failed refund. Show which records change, who is notified, and how support resolves a mismatch between your application and the payment provider.
For an already-settled vendor share, the recovery procedure may require a separate business process; do not promise automatic clawback unless your provider and agreement actually support it.
What a serious developer quotation should include
| Area | What to demand |
|---|---|
| Seller onboarding | Bank-detail validation, account ownership, activation and deactivation rules |
| Commission rules | Fixed or percentage share, fee bearer, currency, rounding and rule history |
| Checkout | Server-calculated amounts, transaction reference and trusted payment verification |
| Payment reliability | Signed webhook processing, duplicate protection, pending and failed states |
| Refunds and disputes | Explicit responsibility, adjustments, exception states and support process |
| Reconciliation | Order-to-transaction-to-settlement references and discrepancy reporting |
| Security | Protected API secrets, authorized admin actions and least-privilege access |
| Handover | Repository, provider account ownership, test evidence, deployment and maintenance notes |
The business should own the Paystack account, repository, domain and production infrastructure. A developer can have appropriately scoped access without becoming the permanent owner of the money-moving system.
For general checkout pricing rather than marketplace settlement, use the broader payment gateway integration cost guide.
Seven tests I would require before launch
Use provider test mode where supported and agree how to validate real settlement safely.
- A correct purchase creates exactly one order and one intended allocation.
- A failed or abandoned payment does not create a paid order or seller entitlement.
- The same successful webhook delivered twice does not duplicate business effects.
- A seller with invalid or unverified payout details cannot silently receive an incorrect allocation.
- Changing the commission percentage tomorrow does not rewrite yesterday’s sale.
- A partial refund leaves a traceable adjustment and correct outstanding business obligations.
- Support can reconcile a transaction even if the customer closed the browser before the success page loaded.
Paystack warns businesses to verify recipient account details carefully. Its support guidance also explains that disabling a subaccount with pending payouts can affect processing. Treat these as operational risks, not cosmetic admin settings.
When does a custom marketplace build make financial sense?
If you have ten vendors and one fixed split, a hosted configuration may be enough. If you have hundreds of sellers, changing commission tiers, partial fulfilment, refunds and disputes, you are buying a marketplace operations system—not a payment button.
Start with the smallest viable money flow. Write down who pays, who earns, who bears fees, who can refund, and what happens when an order is disputed. Then ask a developer to quote that exact workflow, including the unhappy paths.
If the scope includes seller accounts, bookings, permissions and a custom dashboard, compare the work against an MVP development engagement. If your existing product is already taking payments but settlement records do not agree, share the current workflow and problem. I can help scope the repair or implementation without rebuilding functioning parts.
