Paywatch Global: getting the wage-accrual ledger, the withdrawal events and the payday invoice into your own systems

Paywatch's value, from an integrator's seat, is that it already does the awkward middle of a wage-access flow: it sits between an employer's HRIS feed (which says "this person has worked 184 hours this cycle") and a bank disbursement rail (which sends MYR 300 to the user's account in roughly fifteen minutes). The Play Store listing positions the consumer flow as four steps — Work, Track, Withdraw, Settle — and that is the structure the data takes inside the app as well.

If you are reading this because you want that ledger in your own stack — a payroll dashboard, a corporate cash-flow view, a benefits aggregator, an HRIS reconciliation tool — the route is mapping the authenticated employee session and aligning it with the employer-side feed, with the consenting user's authorization. We do that work as a one-stop engagement, including the access negotiation, against a sponsor sandbox or a consenting employee account.

What the app actually holds, by surface

Three routes into the data, and the one we recommend here

The data Paywatch holds is dual-sided — there is an employer view and an employee view — and the cleanest integration depends on which side you sit on.

Route A — authorized interface integration against the employee app session

The most general path. The consenting employee authenticates on the app (phone plus OTP, then a session token), and we mirror that auth chain to read accrued earnings, withdrawal history and the settlement invoice for that user. Durable across markets (the app shares a base across Malaysia, Indonesia, the Philippines, South Korea and Hong Kong). We arrange this with you during onboarding using a consenting account; nothing about the route hinges on you having a pre-existing partner status with Paywatch.

Route B — employer-side payroll integration

If you are the employer (or an HRIS / payroll vendor acting on behalf of one), Paywatch already runs a payroll-integration surface — that is how the worked-hours feed reaches the app in the first place. Pulling the corporate settlement invoices and the per-employee accrual back out for finance is the natural reverse. We handle the commercial and access conversations as part of the build.

Route C — native export from the in-app screens

The app exposes the settlement invoice as a downloadable document at the end of each cycle and the withdrawal history as an on-screen list. For a small-scale or one-shot need, scripting that export under the user's authorization is the cheapest path. It is fragile to UI revisions and we treat it as a fallback rather than a long-lived spine.

For most callers we run Route A as the day-to-day data path and add Route B where you are positioned as the employer side and want clean reconciliation. Route C earns its keep when the requirement is one quarter of invoices, not a live ledger.

Concrete scenarios we have walked through for this app

1. Corporate cash-flow dashboard — an employer pulls live accrual and withdrawal data for its workforce, sees how much wage liability has already been advanced, and folds the settlement invoice straight into payroll close.
2. Personal-finance app side-panel — a consenting user lets a budgeting app read accrued-but-not-withdrawn earnings, so their "available now" balance includes wages they have already earned.
3. Lender pre-screen — with explicit user consent, a lender treats the steady accrual ledger and bank disbursement record as an income-verification signal, instead of asking for payslips.
4. HRIS reconciliation — an HRIS vendor cross-checks Paywatch's worked-hours feed against its own timesheet system, catches the cases where the two drift, and emits a correction back through payroll.

What lands at the end of the build

• An OpenAPI 3.1 spec covering the surfaces we map for this engagement — auth, accrued earnings, withdrawal history, bank-disbursement status, settlement invoice, employer binding.
• A protocol-and-auth-flow report: the phone+OTP-to-JWT chain the app uses, how the session is refreshed, where the bank-rail confirmation re-enters, and how Paywatch's per-employer plan rules (the 50% cap, fee schedule, market-specific tweaks) surface in the responses.
• Runnable source for the key endpoints — Python and Node.js — with idempotency keys on the withdrawal-request layer.
• Automated tests against a sponsor sandbox or a consenting test account, including the multi-binding edge case and a mid-cycle termination.
• Interface documentation written for the team that will run it next quarter, not the team that built it.
• A short data-handling guidance note — retention windows, what to discard, NDA-grade access logs.

What this looks like on the wire

Illustrative shapes — exact field names are confirmed against the live responses during the build. The point is the structure, not the literal keys.

# Step 1 — session (employee consents on-device; we mirror the
# same chain the app itself runs: phone + OTP -> JWT)
token = paywatch.login(phone="+60xxxxxxxxx", otp="...")

# Step 2 — accrued earnings for the current cycle
ledger = paywatch.get_accrued_earnings(
    employer_id="HLBK-EMP-00123",
    cycle="2026-05",
)
# {
#   "accrued_gross":   1842.50,
#   "accruable_now":    921.25,   # the in-cycle cap (~50% in MY)
#   "currency":        "MYR",
#   "hours_logged":      184,
#   "rate_source":    "employer_hris_sync",
#   "cap_policy":     "employer_plan/HLBK-A",
# }

# Step 3 — withdrawal request lands on the bank rail
#  (Hong Leong Bank in MY, Hana Bank in KR, etc.)
wd = paywatch.request_withdrawal(
    amount=300.00, currency="MYR",
    idempotency_key="user42-cycle202605-001",
)
# -> { "tx_id":"...", "fee":2.50, "bank_partner":"HLBK",
#       "status":"pending", "disbursement_eta_s": 900 }

# Step 4 — payday reconciliation: pull the signed-off invoice
#  once the cycle closes
invoice = paywatch.get_settlement_invoice(cycle="2026-05")
# line items: gross salary, sum withdrawn, fees, net payable

Authorization, regulation and data-minimization

Earned wage access does not yet sit under a dedicated regulatory instrument in Paywatch's markets. Bank Negara Malaysia has recognized the firm publicly for its financial-inclusion work, per the MIDA write-up, but BNM has not issued a specific EWA framework that an integrator must register against. Paywatch Malaysia's CEO has himself called publicly for the Malaysian government to consider one. The dependable basis for the integration is therefore the consenting user's authorization (or, on Route B, the employer's authorization), not a forward-looking rule.

The data-protection regimes that govern the underlying records are local: Malaysia's PDPA 2010, Indonesia's UU PDP (2022), the Philippines' Data Privacy Act, South Korea's PIPA, and Hong Kong's PDPO. In practice that means consent scope must be written for the surfaces you actually pull, the consent must be refreshable and revocable, and the retained data must be the smallest set that meets the use case. We bake that into the build — explicit consent text, an expiry window, a revocation path, and per-request logging — rather than leaving it to be retrofitted.

Things we account for so the integration does not bite later

Three patterns are worth flagging because they are specific to how Paywatch's flow is shaped — and all three are things we map during the build rather than asking you to pre-solve.

1. Two ledgers, not one. The Work → Track → Withdraw → Settle flow is two parallel ledgers under the hood: an accrual ledger driven by the employer HRIS sync, and a withdrawal-and-disbursement ledger driven by the bank rail. We design the integration so both sides reconcile against the settlement invoice at cycle close; otherwise a late HRIS correction or a reissued withdrawal silently desynchronizes the pulled balance, and finance teams notice in the worst possible way.
2. Per-employer plan rules. The 50% withdrawal cap is the public default in Malaysia, but the cap and fee schedule vary by employer plan and by market. We map those plan rules from the sandbox or consenting-account responses during the build, so the integration treats two employees on different employer plans correctly instead of assuming a single global ceiling.
3. 15-minute disbursement is fast enough to confuse a poller. Bank rail confirmations land quickly enough that naive polling either misses the transition or races the in-app status string, which lags by a few minutes. We attach idempotency keys at the withdrawal layer and treat the bank partner's confirmation as authoritative, with the in-app status as a secondary signal.

Freshness, drift and what we hand off for maintenance

The app's surfaces shift modestly over time — the consumer flow has been stable since the 2022 launch but the response payloads are versioned and have been re-shaped at least once around the Indonesia and Philippines rollouts. The handoff includes a small re-validation script that pings the mapped surfaces nightly and flags drift before it reaches your production pull. Where Paywatch publishes a webhook for a bank confirmation, we prefer that to polling; where it does not, we set a polling cadence sized to the per-employer plan, not a one-size cron.

The app, as it ships

Other wage-access and on-demand-pay apps we map the same way

The integration shape — accrual ledger plus bank-rail disbursement plus payday settlement — generalizes. We have walked through the surfaces of the following, which a unified wage-access view typically wants to cover alongside Paywatch.

• DailyPay — large US on-demand pay platform; per-transaction wage advances against an employer feed.
• PayActiv — US EWA with a financial-wellness wrapper; carries similar withdrawal + settlement records.
• Wagestream — UK and APAC; stronger emphasis on streamed pay and in-app savings.
• ZayZoon — North America; small-and-medium employer focus.
• Branch — US workforce-payments app spanning EWA, tips, and direct deposit.
• Tapcheck — US on-demand pay benefit, employer-deployed.
• Payd — Malaysia-and-Thailand EWA, the most direct local peer to Paywatch.
• Wagely — Indonesia and Bangladesh EWA platform, another regional peer.
• MyPay at Work (Chime) — US flexible pay built into a neobank.
• Payflow — Europe-and-LatAm EWA; salary-on-demand wrapper.

Questions teams ask before they kick this off

Does the app expose worked-hours data per employer, or only the consolidated accrual the user sees?

On the employee-facing app it surfaces the consolidated accrual for the active employer binding plus the running hours log behind it. Worked-hours per employer becomes meaningful when one user has more than one binding, which Paywatch supports through onboarding. We model both shapes during the build so a multi-binding case does not collapse into a single ledger by accident.

How does withdrawal status reach our side once the bank disburses?

The app itself updates the in-screen status string fairly quickly, but the authoritative timestamp is the bank rail's confirmation — Hong Leong Bank for Malaysia, Hana Bank for South Korea, and others for the other markets. We treat the bank confirmation (webhook where the partner exposes one, otherwise a poll on the rail) as the source of truth and the in-app string as a secondary signal, because the two can drift by a few minutes.

Can we reconcile against the payday invoice line items rather than the raw withdrawal log?

Yes — and you usually want to. The settlement invoice is the document the employer signs off on at payday and carries the line-item structure (gross, withdrawn amount, fees) that finance teams expect. The raw withdrawal log is useful for in-cycle monitoring; the invoice is what reconciles cleanly with payroll.

What changes when an employee leaves an employer mid-cycle?

The employer binding flips to a terminated state, the accrual freezes at the last sync, and the settlement invoice is cut early. We handle this explicitly in the integration so a stale binding does not keep emitting an accrual of zero forever, and so the early settlement is captured rather than dropped.

What was checked, and where

Primary sources opened for this mapping: the app's Play Store listing for the four-step description and operating-system constraint, the Paywatch Malaysia "about" page for the bank-partnership structure and the 50% cap, the MIDA write-up for the regional scale figures and the Bank Negara Malaysia recognition, and the Paywatch support center for the in-app workflow detail. Where a public number is not confirmed against an opened source, it is hedged in the text rather than asserted.

Mapped by the OpenBanking Studio integration desk · 2026-05-30.

Source-code delivery starts at $300, paid only after we hand over and you are satisfied with what we built. A hosted-API alternative charges per call with no upfront fee — useful if you would rather not run the integration in-house. Cycle is one to two weeks from kickoff. If a Paywatch Global build is what you need, the next step is tell us what you want to pull and from which market, and we handle the rest from there.