Escrow-Style Payment Holding for Marketplaces in the Philippines

2026-10-05 10:00:00

When we started mapping out the payment flow for the marketplace we're building for the Philippines, the first design decision that nearly tripped us up had nothing to do with which wallet or channel to integrate. It was more basic: the moment a buyer pays, does the seller get that money right away, or does something else happen first? For a single-merchant store the answer is obvious. For a marketplace, where we're not the one selling anything and the seller is someone we've never met, it's a lot less obvious. This article is about the pattern we ended up building: holding a buyer's payment after it's collected, and only releasing it to the seller once a condition is satisfied, rather than paying out the moment the purchase clears.

Why "Pay the Seller the Moment the Buyer Pays" Breaks Down on a Marketplace

On a single-merchant site, the payment and the delivery obligation sit with the same party, and that business has every incentive to make it right if something goes wrong. A marketplace is structurally different: we're the platform sitting in the middle, connecting a buyer to a seller we don't fully control. If we hand the buyer's money straight to the seller the second the order is placed, the buyer has paid in full before anything has been delivered or confirmed — and once that money sits in the seller's own account, our platform has very little leverage left if the seller doesn't follow through.

That's the core reason marketplaces don't treat payment collection and seller payout as the same event. Where a single merchant can justify getting funds the same day it processes a sale — covered in our piece on D0 same-day settlement — a marketplace needs a different mechanism: assurance for the buyer that their money isn't gone the moment they click "buy," and leverage for the platform to resolve problems before the seller has walked away with the funds.

It's worth being precise about what this is and isn't. We're not describing a regulated escrow product, and we don't present it as one to sellers or buyers. It's an operational pattern: the platform collects the buyer's payment into its own collection account and holds it there internally, under its own ledger logic, until a release condition is met. It behaves like escrow from the user's point of view — money sits in a neutral place until something happens — but it's a feature we design on top of our payment infrastructure, not a separate licensed escrow service.

The Hold-Then-Release Pattern, End to End

Once we accepted that immediate payout wasn't the right default, the mechanics turned out to be fairly linear. There are three states a marketplace order's funds move through:

Collected — the buyer's payment has cleared and the money sits in the platform's collection account, not the seller's.
Held / pending release — the order is confirmed and paid, but the release condition hasn't fired yet. This is the state that does all the work, and it needs its own status in your order and ledger models, not a boolean flag bolted onto an existing payment record.
Released — the release condition fired, and the funds move from the collection account to the seller's payout queue, following whatever payout schedule and rails you already use for disbursements.

What's easy to underestimate is that "held / pending release" needs to behave like a real, queryable state, not a note in a support ticket. Your seller dashboard needs to show held funds separately from available balance, support needs to see at a glance whether an order's money has moved, and reconciliation needs collection-account balances tracked separately from seller-payable balances.

We built this as its own ledger entity — a "hold" record tied to an order, with its own id, status, and event history — rather than overloading the payment record itself. That mattered once disputes entered the picture, which we'll get to.

Picking a Release Trigger: Manual Approval, Timer, or Delivery Confirmation

The release condition is the part you actually have to design, and there's no single right answer — it depends on what you're selling and how verifiable "the order was fulfilled" actually is. We ended up supporting three trigger types side by side, because different seller categories on our marketplace genuinely needed different ones.

Manual approval puts the decision in the buyer's hands. After the seller marks the order delivered or completed, the buyer gets a prompt — "did you receive this, was the service completed as described" — and tapping confirm fires the release. This fits services and higher-value goods well, since it puts human judgment in the loop where it matters most.

Auto-release timer is a fallback more than a primary mechanism in most setups. A window opens once the order is marked delivered, and if the buyer hasn't disputed it by the time that window closes, the system releases the funds on its own — keeping high-volume categories moving without a tap from every buyer.

Delivery confirmation ties the release to an external signal, typically a proof-of-delivery event from a logistics integration, rather than anything the buyer or seller does directly. It's attractive because it's automatic, but worth being honest about its limits: a courier marking something "delivered" tells you a package arrived at an address, not that the contents were correct or the buyer is satisfied.

Most mature marketplaces layer these rather than picking one: delivery confirmation starts the clock, an auto-release timer closes it out, and manual approval or a dispute can interrupt that clock before it fires.

Release Trigger	Who / What Initiates It	Typical Mechanics	Main Risk
Manual approval	Buyer	Buyer taps "confirm received / completed" in-app or via a notification link; that action fires the release call directly	Buyer goes inactive and never confirms, leaving the hold open indefinitely without a fallback
Auto-release timer	System clock, counted from a delivery or completion event	A fixed window opens when the order is marked fulfilled; if no dispute is raised before it closes, release fires automatically	The window may close before a buyer who travels, is away, or inspects slowly has had a real chance to object
Delivery confirmation	Courier / logistics webhook	A proof-of-delivery or "completed" status from an external integration moves the hold into a release-eligible state, often with a short grace period	Confirms the package arrived, not that its contents matched the order or the service was actually performed correctly

None is inherently safer — each trades buyer protection against operational friction differently, and the right choice is usually per category, not platform-wide.

What Happens When Nobody Confirms Anything

This is the scenario that exposes whether your hold design is complete: the seller marks the order fulfilled, and then nothing. The buyer doesn't confirm, doesn't dispute, doesn't respond. If your only release path is manual approval, funds sit in limbo with no exit condition, and a seller who rightfully earned that money is stuck waiting indefinitely.

That's exactly why an auto-release timer shouldn't be optional, even on marketplaces that lead with manual approval as the primary trigger. Every hold needs a default resolution path that doesn't depend on a human acting. Our rule of thumb: every hold record gets an auto-release timestamp from the moment it's created, regardless of the intended primary trigger — the timer is just the backstop. The window length is a business decision specific to category and order size, not something to standardize across a whole catalog.

The other half of "nobody acts" is the seller side: what if the seller never marks the order fulfilled at all? That shouldn't resolve toward auto-release — a hold with no fulfillment signal should escalate toward a refund path or manual review, not toward paying a seller who never delivered. Screening these cases overlaps with the fraud and anomaly checks you'd run elsewhere in your payment stack, which we cover in our breakdown of fraud detection rules for Philippines payment processing.

When a Dispute Opens While Funds Are Still Held

One advantage of the hold-then-release pattern that's easy to undersell: when a buyer disputes an order, you're not clawing money back out of a seller's account after the fact — you're freezing a transfer that hasn't happened yet. A dispute event should do one specific thing to a hold record: pause its clock. Whatever trigger was about to fire — the auto-release timer, a pending manual approval — gets suspended the moment a dispute opens, and the hold sits in a distinct "disputed" sub-state until your resolution process closes it.

Resolution typically lands in one of three places: release to the seller in full if the dispute resolves in their favor, refund to the buyer from the held funds if it resolves the other way, or a partial split under your dispute policy. The mechanics — evidence windows, who adjudicates, how refunds get issued — closely relate to standard chargeback handling, covered in our guide to payment disputes and chargebacks. What's specific to marketplaces is the timing: the funds never left your collection account, so you're resolving a dispute against money you still control.

This is also where release notifications matter operationally. If a delivery-confirmation webhook or auto-release timer is about to fire, your system needs to check for an open dispute before executing — a release that fires moments after a dispute opens generates real support tickets and real seller trust problems. We lean on the same reliable-delivery thinking covered in our piece on webhook retry design: making sure an event is processed, in order, exactly once.

Where This Sits in Your Compliance Conversation

It's worth repeating the framing point from earlier, since it matters for how you talk about this feature to sellers, buyers, and your payment partner. Holding a buyer's funds before paying a seller is a pattern a marketplace implements on top of its payment infrastructure — not, on its own, a regulated escrow license.

SMARTPAY operates under BSP's OPS and EMI licensing frameworks, which govern how regulated payment flows move through our rails — but the hold-then-release logic a marketplace builds on top of that, deciding when and under what condition a seller actually gets paid, is designed and owned by the platform itself, not a separate licensed escrow product.

Practically, holding customer funds for later release to a third party has its own compliance considerations worth working through with your licensed payment partner — how collection accounts are structured, how held balances get reconciled and reported, and how long funds can reasonably sit before release.

Because the underlying infrastructure already sits on BSP OPS and EMI licensing, the rails themselves are built for regulated fund movement — what's genuinely yours to design is the hold duration, the release conditions, and how you document that logic for your own compliance record.

We'd rather be explicit about this than let a seller or regulator assume we're claiming something we're not. If your marketplace is still deciding whether to build this pattern, that conversation is worth having before you write a single line of hold logic.

Representing the Hold in Your API and Ledger

This comes down to giving a hold its own object and lifecycle in your API, separate from the underlying payment charge. Below is a simplified, representative example — creating a hold tied to an order, then firing the release once the condition is met.

## Step 1: create a hold when the buyer's payment clears
curl -X POST https://api.yourplatform.ph/v1/holds \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk_live_xxxxx" \
  -d '{
    "order_id": "ORD-88213",
    "seller_id": "SEL-5571",
    "amount": "4200.00",
    "release_condition": "delivery_confirmation",
    "fallback_trigger": "auto_release_timer",
    "auto_release_days": 7
  }'

## Response: hold created, funds sitting in the collection account
{
  "hold_id": "HLD-903214",
  "status": "held_pending_release",
  "release_condition": "delivery_confirmation",
  "dispute_open": false,
  "auto_release_at": "2026-10-12T10:00:00+08:00"
}

## Step 2: release trigger fires (e.g. courier webhook, buyer approval, or timer)
curl -X POST https://api.yourplatform.ph/v1/holds/HLD-903214/release \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk_live_xxxxx" \
  -d '{
    "triggered_by": "delivery_confirmation",
    "evidence_ref": "COURIER-EVT-55102"
  }'

## Response: funds move from the collection account to the seller payout queue
{
  "hold_id": "HLD-903214",
  "status": "released",
  "released_to": "SEL-5571",
  "released_at": "2026-10-06T14:32:11+08:00"
}

Notice the dispute_open field and the separate fallback_trigger. Any release call should check dispute state before executing, and every hold should carry a fallback path from creation — not bolted on later once you hit the first order nobody ever confirmed.

Common Questions

Is this the same thing as splitting a payment between multiple sellers?

No — keep these two problems separate even though both show up in marketplace design. Splitting a payment is about dividing one buyer payment across several recipients the moment it settles. A payment hold is about timing — when a seller gets paid at all, regardless of how many parties the payment is eventually divided between. The two patterns are independent and can be combined.

How long should an auto-release timer be set to?

There's no single correct window, and we'd avoid treating any fixed number as a hard promise to buyers or sellers. It depends on how long it realistically takes a buyer to notice a problem — a physical good that arrives quickly needs a different window than a multi-week service engagement. We set this per category rather than platform-wide.

What happens if a seller never marks an order as fulfilled?

That shouldn't drift toward an automatic release. A hold with no fulfillment signal from the seller should escalate toward manual review or a refund path, since releasing funds to a seller who never delivered undermines the point of holding the payment.

Can a buyer still dispute an order after the funds have already been released?

Yes — release closes the hold, but it doesn't close the door on a dispute. At that point you're handling it the way any post-settlement dispute or chargeback gets handled, a different path than pausing a pending hold.

Does the platform need a separate account structure to hold funds for sellers?

Functionally, yes — held funds need to be tracked distinctly from both the platform's own revenue and funds already payable to sellers, so reconciliation doesn't blur money held on someone else's behalf with your own. How that's structured underneath depends on how your licensed payment partner sets up collection accounts.

Should every order type on the marketplace use the same release trigger?

We don't think so. A trigger that fits a physical good with trackable courier delivery doesn't fit a service booking with no shipment event at all. Letting sellers or categories map to different trigger types, with a consistent fallback timer underneath, has worked better than forcing one rule across the whole catalog.

Is a payment hold the same as an escrow license?

No. What we've described here is a hold-then-release pattern the platform implements in its own collection account and ledger logic, sitting on top of licensed payment rails — not a separate, formally licensed escrow product.

If you're mapping this onto a marketplace you're building in the Philippines — where collection accounts should sit, how release logic should talk to your payment partner's rails, or how disputes should interrupt a pending hold — reach out directly. You can message @LouisSMARTPAY on Telegram or write to [email protected].