Skip to main content
Escrow is the payment model on Guild. Not optional. Not a setting. It’s how every job is paid. The moment you post a job, the full budget leaves your bank (or your wallet) and lands in an escrow balance tied to that job. It’s committed before any Job Seeker even sees the posting. As work happens and attendance is marked, per-shift wages release from escrow to Job Seeker wallets automatically. Unfilled headcount refunds to your wallet at the end of the job without you doing anything. You set this up once at job posting. After that, you check the dashboard occasionally. The money handles itself.

Why escrow-on-post

Three reasons, all important.

1. It eliminates the “wait, can the employer actually pay?” anxiety

A Job Seeker who applies to a Guild job knows the money is already in the system. If they show up and do the work, they get paid. No “the employer disappeared.” No “the cheque hasn’t cleared.” No “let me get back to you after I check my account.” This is the difference between Guild and informal hiring through middlemen, where ghost payments are a real risk for the Job Seeker.

2. It eliminates ghost workers for the employer

You only pay for shifts that actually happened. The foreman can’t mark a ghost worker present and pocket the difference, because the foreman doesn’t see the money — it auto-releases to a real Job Seeker’s verified wallet.

3. It makes the audit trail simple

One debit at the start (employer’s bank → escrow). One credit per completed shift (escrow → Job Seeker wallet). One refund at the end for unfilled headcount (escrow → employer wallet). Every motion is a row in the audit ledger.

Funding the escrow

When you submit a job posting, we calculate the budget — daily rate × duration × headcount — and immediately debit your funding source. The funding source is picked automatically based on what’s set up:
  • Direct debit from your bank, if your mandate is ready (the recommended path).
  • From your Guild wallet, if the wallet has enough balance.
  • From a saved card or one-time bank transfer, for one-off jobs that don’t need a mandate.
The debit happens in seconds. The escrow balance for your job is funded. The job goes live. If the debit fails (e.g., your bank has insufficient funds, your wallet is empty and there’s no mandate), the job doesn’t go live. You see a clear failure with a retry button.

How releases work

The release rule is simple: each time a Job Seeker’s attendance for a shift is marked present and their application is in APPROVED state, we release one day’s wage to their wallet. Automatically. No tap required. Per-shift release happens at the end of each shift day (default: 6 PM local time, configurable per job).
1

Foreman marks Musa present on day 1

Attendance row written.
2

6 PM rolls around

Our scheduler scans approved applications with day-1 attendance and no day-1 release yet.
3

Release transaction fires

Internal ledger move: escrow row debited ₦4,000, Musa’s wallet credited ₦4,000. Audit rows on both sides.
4

Musa's phone buzzes

SMS notification. WhatsApp message if active.
5

Repeat for each shift, each Job Seeker

Day 2 release fires next evening. Day 3 fires the evening after.
By Saturday evening, your escrow has paid out the right amount to the right people based on who actually showed up. Your dashboard shows the running spend and the remaining escrow balance.

Refunds

The good part. If the job’s budget assumed five Job Seekers and only four showed up across all three days, ₦12,000 of escrow never released. When the job hits COMPLETED status (either you mark it complete or it auto-completes the day after the end date), the unspent escrow refunds to your wallet. The refund is automatic. No request. No support ticket. You see it in your transaction history as ESCROW_REFUND with the job ID linked. The same applies if a Job Seeker partially attended:
  • Approved for 3 days but only showed for 2 → 1 day’s wage refunds.
  • Approved for 3 days and showed for all 3 but their application stays APPROVED (employer didn’t mark it COMPLETED) → release still happens because attendance is the trigger. The application later transitions to COMPLETED for record-keeping.

Boosting the escrow mid-job

If you decide mid-job that you want to add a sixth Job Seeker, or extend the job by a day, the dashboard shows you the new total budget and triggers a fresh debit for the additional amount. We hold this in the same escrow row. Releases continue under the same rule.

Cancelling a job

If you cancel a job, you’re charged for completed shifts (those have already released). The remainder refunds to your wallet within a minute. A cancelled job after approvals notifies the affected Job Seekers and pays them for any shifts they did work.

What happens to escrow at quarter-end and other accounting moments

Escrow balances sit on our payments schema, separate from wallet balances. For your accounting, they’re committed funds — you’ve sent the money, it’s earmarked for the job, and the worst case is it refunds to you. We do not pay interest on escrow. We do not co-mingle escrow with operating capital (it sits in a OPay-pooled account at the partner bank, segregated by job). If Guild ceased to operate, escrow funds for in-flight jobs would be released — to Job Seekers for completed shifts and to employers for the unspent remainder. This is in our terms of service and is part of why we keep the audit ledger structurally immutable.
Escrow is not a holding mechanism for general operating capital. It’s specifically tied to job budgets. Don’t fund ₦5M in escrow for a ₦100K job thinking it’ll sit there — we limit funding to 110% of the calculated budget (the 10% buffer covers small extensions).

The full lifecycle, in one diagram

One employer action at the top. Many automatic releases in the middle. One automatic refund at the end. Nothing in between requires you to tap anything.

Next

Workforce reports

Aggregate views across jobs. Spend over time, composition, repeat hires.

Link a bank

If you haven’t already — direct debit is the easiest way to fund escrow.