Escrow-Style Flows on Paystack and Their Limits

True escrow involves a licensed intermediary that holds funds in a neutral account with legal obligations to both the buyer and the seller. The escrow agent releases funds only when predefined conditions are met, and both parties have legal recourse if the agent acts improperly. Banks and licensed escrow companies provide this service.

Delayed settlement on Paystack is a payment processing feature that lets you control when a subaccount's share of a split transaction is paid out. The money is held by Paystack (not in a neutral escrow account), and the release decision is made by you (the platform operator, not a neutral third party). There is no legal framework protecting the parties in the way that formal escrow does.

The distinction matters because:

• Legal protection is different. In true escrow, both parties have recourse against the escrow agent. In delayed settlement, the vendor's recourse is against your platform, and the buyer's recourse is also against your platform. You are the decision-maker, not a neutral party.
• Holding duration is different. True escrow can hold funds for weeks, months, or until a legal condition is met. Delayed settlement on Paystack is subject to Paystack's policies on hold duration, which are not designed for long holds.
• Recovery is different. In true escrow, the agent can return funds to the buyer if conditions are not met. In delayed settlement, once you release to the vendor, you cannot reverse it through Paystack. And if the buyer needs a refund after release, it comes from your account.

Delayed settlement is a useful tool for short-duration holds in marketplace workflows. It is not a replacement for actual escrow services. If your product genuinely needs escrow (property transactions, high-value asset purchases, milestone-based contracts), use a licensed escrow provider.

Delayed settlement works by configuring a subaccount for manual settlement instead of automatic settlement. When a split transaction succeeds, Paystack holds the subaccount's share instead of settling it on the normal cycle. You release it when you are ready.

The flow:

1. Create the subaccount with a manual settlement schedule
2. Customer pays via a split transaction referencing the subaccount
3. Paystack holds the subaccount's share (your commission portion settles normally to your account)
4. Some condition is met on your platform (delivery confirmed, work approved, return window expired)
5. Your backend triggers settlement release for the subaccount
6. Paystack settles the held funds to the subaccount's bank account

During the hold period, the funds sit with Paystack. They are not in your account and they are not in the vendor's account. You control the release trigger, but you do not control the funds directly. You cannot move them, invest them, or use them for other purposes.

This is the key difference from the collect-then-transfer model, where you hold all the money in your own account and transfer to vendors when ready. In that model, the funds are in your account and you have full control (and full responsibility). With delayed settlement, Paystack holds the funds and you hold the release trigger.

Delayed settlement works well for short-duration holds where the condition for release is clear and the timeline is predictable.

Food delivery (hours): The customer pays, the restaurant prepares the food, the rider delivers it. The customer confirms receipt through the app. Hold: 1-3 hours. Release trigger: delivery confirmation or automatic release after a timeout. This works because the hold is short and the completion event is clear.

E-commerce shipping (days): The customer pays, the seller ships the product, the customer receives it. Hold: 2-7 days depending on shipping time. Release trigger: delivery confirmation from the courier or manual buyer confirmation. This works if you have reliable delivery tracking.

Service completion (hours to days): The customer books a service (house cleaning, car repair, photography), the service provider completes it, the customer confirms satisfaction. Hold: same day to a few days. Release trigger: customer confirmation or automatic release after the service date plus a review window.

Return window protection (days): Even without explicit buyer confirmation, you can hold settlement for the duration of your return policy. If the buyer does not raise an issue within 48 hours of delivery, release the funds automatically. Hold: 2-7 days after delivery. Release trigger: timeout with no dispute raised.

In all these cases, the hold is measured in hours or single-digit days. The release condition is either an explicit action (buyer confirms) or a timeout (no dispute within X hours). The vendor expects a short delay, and the platform can communicate the timeline clearly.

Delayed settlement breaks down when the hold is long, the release condition is ambiguous, or the amount at risk is high enough to require real escrow.

Milestone-based freelance contracts (weeks to months): A client hires a freelancer for a project with three milestones over eight weeks. You want to hold the full payment and release per milestone. Problems: the hold duration exceeds what Paystack allows, milestone completion is subjective ("Is this design really done?"), and partial releases on a single split transaction are not straightforward.

Property deposits (months): A tenant pays a deposit through your platform, and you want to hold it for the duration of the lease. This is a multi-month hold for a potentially large amount. Paystack is not designed for this. You need a licensed escrow or trust account arrangement.

Crowdfunding (weeks): Backers pledge money for a project that will ship in three months. You want to hold the pledges until the project reaches its goal. The hold is too long, the release condition (project funded and product shipped) is too far in the future, and the regulatory implications of holding pledged funds are significant.

High-value B2B transactions: A business pays 5 million NGN for custom equipment. You want to hold the payment until the equipment is delivered and inspected. The amount justifies real escrow with legal protections for both parties. A payment processing hold is not adequate for this level of risk.

Dispute-dependent releases: You want to hold funds until a dispute is resolved, but disputes can take weeks. The unpredictable timeline makes delayed settlement unsuitable. You need a system that can hold funds for as long as the dispute takes, which may exceed Paystack's allowed hold period.

The most dangerous aspect of escrow-like flows on Paystack is what happens when a refund is needed after the vendor has been settled. Once you release funds to the subaccount, Paystack settles them to the vendor's bank account. There is no "undo" button.

If the buyer then requests a refund (the product was defective, the service was not as described, the item never arrived despite the tracking showing delivered), the refund comes from your main Paystack account balance. You are paying the refund out of your own money while the vendor still has theirs.

Mitigation strategies:

• Extend the hold period. Do not release on delivery confirmation alone. Add a review window: release 48 hours after delivery if no dispute is raised. This catches the most common post-delivery issues.
• Build a vendor recovery process. When you refund a settled transaction, create a recovery record in your database. Deduct the amount from the vendor's next settlement or invoice them directly. Make this policy clear in your vendor terms.
• Maintain a reserve. For high-volume marketplaces, keep a cash reserve in your Paystack balance to cover refunds that happen after vendor settlement. Size the reserve based on your historical refund rate and average settlement amount.
• Limit refund eligibility. After the hold period expires and the vendor is settled, restrict refunds to cases you can verify (provably defective product, confirmed non-delivery). Open-ended refund policies become expensive when you cannot recover from the vendor.

The core issue: delayed settlement gives you a window, not a solution. It pushes the refund problem forward in time but does not eliminate it. Eventually, you will face a refund request on a settled transaction, and you need a process for handling it.

Building an escrow-like flow raises regulatory questions that technical documentation cannot answer definitively. Here is what you need to be aware of.

Holding funds on behalf of third parties. In many African jurisdictions, collecting and holding money on behalf of others requires specific financial licensing. When you use delayed settlement, Paystack holds the funds (not you), which reduces your direct regulatory exposure. But if your product is marketed as an "escrow service" to users, regulators may view you as providing a regulated financial service regardless of the technical implementation.

Nigeria: The CBN regulates escrow services. Operating an unlicensed escrow service can attract regulatory attention. If your product holds funds and releases them conditionally, consult with a fintech lawyer about whether your specific model requires licensing.

Kenya: The Central Bank of Kenya oversees payment service providers. Holding customer funds typically requires a license under the National Payment System Act. Again, Paystack holds the funds in delayed settlement, but your product's positioning and user agreements matter.

South Africa: The Financial Sector Conduct Authority (FSCA) regulates financial services. Escrow-like products may fall under financial services regulation depending on how they are structured.

The safe approach: do not call your product "escrow." Do not market it as an escrow service. Instead, describe it as a payment platform with a confirmation-based release process. Have a fintech lawyer review your specific implementation and terms of service before launch. The cost of legal review is much less than the cost of a regulatory enforcement action.

If your product genuinely needs escrow, here are the situations where you should look beyond Paystack's delayed settlement.

• Hold periods longer than a few days. If you need to hold funds for weeks or months, Paystack's delayed settlement is not designed for this. Use a licensed escrow service or a regulated trust account arrangement.
• High-value transactions. If individual transactions are large enough that a failed recovery would materially harm your business, the risk of using payment processing holds instead of real escrow is too high.
• Complex release conditions. If the release depends on third-party verification (inspections, legal review, regulatory approval), the process is too complex for a simple hold-and-release mechanism.
• Multi-party releases. If the release decision involves more than two parties (buyer agrees, inspector certifies, regulator approves), you need a more sophisticated system than a binary hold/release toggle.
• Legal enforceability. If the parties need legal recourse against the fund holder (not just your terms of service, but actual financial regulation), you need a licensed escrow provider.

Licensed escrow providers in Africa include banks that offer escrow accounts and specialized fintech companies. The cost is higher than building on Paystack, but the legal protection and hold flexibility justify it for the right use cases.

For the implementation details of delayed settlement where it does work, see delayed settlement patterns for marketplaces. For the broader split payments architecture, see the Paystack split payments and marketplaces complete guide.

Knowing the limits of a tool is just as important as knowing how to use it. The difference between a junior and senior payment engineer is understanding when Paystack is the right solution and when it is not.

The McTaba bootcamp teaches payment engineering with the depth you need to make these architectural decisions. You learn what to build, what to buy, and what to avoid.

Create a free McTaba account