The problem GigPay Indonesia solves

GigPay

A Network Payout & Treasury Coordination Layer

1. Problem

Modern digital businesses operate in a world that legacy payout infrastructure was never designed to handle.

A. Cross-border settlement is slow and expensive

Traditional bank rails (SWIFT, correspondent banking, ACH) introduce:

• T+1 to T+5 settlement delays
• 3-7% total cost in cross-border corridors (FX spreads + intermediary fees)
• Weekday cutoffs and timezone friction
• Opaque FX spreads layered on top of transfer fees

According to the World Bank Remittance Prices Worldwide database, global average cross-border remittance costs remain around 6% (World Bank, 2023). While B2B flows differ from remittances, correspondent banking layers and FX spreads create comparable multi-percentage costs.

The Bank for International Settlements (BIS) and SWIFT documentation show that cross-border payments still rely heavily on multi-hop correspondent networks, where funds can take 1-5 business days depending on corridor complexity and compliance checks (BIS CPMI – Cross-border payments; SWIFT GPI Overview).

By contrast, blockchain settlement can clear within minutes, with transaction costs often measured in cents to low dollars depending on network conditions (Ethereum Gas Tracker – Etherscan; L2 Fee Analytics).

For platforms operating at scale, even a 2-4% efficiency gain across millions in volume translates into substantial margin recovery.

B. Working capital is trapped in payout operations

Finance teams today must:

• Pre-fund multiple accounts across tools
• Hold excess liquidity “just in case”
• Manually reconcile batches and balances

This creates:

• Idle float that earns little to no return
• Fragmented treasury visibility
• Operational overhead in reconciliation

The BIS Committee on Payments and Market Infrastructures (CPMI) highlights that cross-border frictions create “liquidity inefficiencies” and capital fragmentation across correspondent chains (BIS Cross-border Payments – Stage 3 Roadmap).

Research from the Federal Reserve Bank of New York and BIS further discusses liquidity and capital inefficiencies in correspondent banking networks (BIS Quarterly Review – Correspondent Banking).

Meanwhile, US Treasury yields ranged between 4-5% in 2023–2024, illustrating the opportunity cost of idle capital (Federal Reserve Economic Data – 3M Treasury).

Yet most businesses cannot safely deploy float into yield without breaking accounting boundaries or payout availability guarantees.

C. Complex payout logic lives off-chain

Real-world payment workflows involve:

• Milestone-based releases
• Multi-sign approvals
• Refunds and disputes
• Revenue splits
• Cross-currency preferences

Today, these conditions exist in:

• Spreadsheets
• Slack threads
• Email approvals

Banks only see the final debit. There is no enforceable state machine representing the payout lifecycle.

The BIS report on Distributed Ledger Technology in payment systems notes that programmable settlement and atomic transactions can reduce reconciliation complexity and operational overhead (BIS DLT in Payment Systems).

Traditional ERP reconciliation cycles require manual stitching of:

• Approval logs
• Invoices
• Bank statements
• FX confirmations

The absence of a unified intent ledger increases dispute frequency and audit complexity.

D. Market scale

The total addressable market is substantial:

• Global payment flows exceed $190 trillion annually (BIS Red Book Statistics).
• Global B2B payments exceed $150 trillion annually (McKinsey Global Payments Report) (McKinsey Global Payments Report).
• Stablecoin transfer volume exceeded $10 trillion annually in 2023–2024 (Chainalysis Crypto Adoption Report).
• Stablecoin circulating supply exceeds $150B market capitalization (CoinGecko Stablecoin Data).

Challenges we ran into

Postmortem (What happened -> Why -> Fix -> Prevention)

1) Vercel deployments crashed (Prisma not initialized / outdated client)

• What happened: The API intermittently failed on Vercel with “Database client not initialized” and Prisma errors about Vercel caching causing an outdated Prisma Client.
• Why: Serverless builds cached dependencies; Prisma Client generation didn’t reliably run. DB env var naming also differed across providers/prefixes.
• Fix: Ran prisma generate during build, expanded DB URL resolution across multiple env keys, and returned a clear 503 instead of crashing when Prisma couldn’t initialize.
• Prevention: Keep Prisma generation as part of the build pipeline; validate env presence at startup; fail fast with actionable errors.

2) Migrations blocked by a failed migration (P3009)

• What happened: prisma migrate deploy refused to apply new migrations due to a prior failed migration recorded in the database.
• Why: Prisma protects production DBs by stopping migration application when a migration is marked failed.
• Fix: Made the failing migration idempotent and added a “heal and retry” path using prisma migrate resolve --rolled-back followed by re-running deploy.
• Prevention: Make production migrations idempotent where possible; monitor migration status; avoid leaving partially applied migrations in shared DBs.

3) RPC outages broke indexing and made balances look like zero

• What happened: Treasury balances and history went blank; backend event sync threw 503/429 RPC errors.
• Why: Public Base Sepolia RPC endpoints were unstable/rate-limited.
• Fix: Added multi-RPC fallback on the frontend and defensive RPC handling on the backend (skip/return defaults instead of crashing).
• Prevention: Always use fallback RPCs, cache key reads, and treat RPC as a flaky dependency with graceful degradation.

4) BigInt JSON serialization errors broke API responses

• What happened: Endpoints returned {"error":"Do not know how to serialize a BigInt"}.
• Why: JSON.stringify cannot serialize BigInt, and some Prisma/RPC outputs include BigInts.
• Fix: Added a JSON-safe response helper that converts BigInts to strings consistently.
• Prevention: Normalize numeric types at the boundary (API responses); enforce serialization-safe schemas.

5) Payment “Confirm” flow was inconsistent (disabled, stuck, duplicate submits)

• What happened: Users couldn’t confirm escrow creation reliably; sometimes Confirm was disabled without clear reason, sometimes it triggered multiple times, and sometimes the UI crashed.
• Why:
  • Confirm was gated by strict conditions (wrong chain, swap route missing, token not eligible, yield strategy not allowed).
  • Receipt-handling effects could re-run and re-trigger follow-on actions without idempotency guards.
  • Some UI assumed state fields existed (swap) when older drafts didn’t include them.
• Fix:
  • Added network gating with a “Switch to Base Sepolia” CTA.
  • Added idempotency guards (process a txHash once).
  • Added defensive defaults to prevent crashes.
  • Added an eligibility checklist + auto-fallback rules to keep the flow actionable.
• Prevention: Treat the confirm path like a state machine with explicit transitions; enforce “exactly-once” handling; always show the user why a CTA is blocked and what the app will do next.

6) Explore didn’t show the real “Step 1-4” context

• What happened: Jobs appeared in Explore but didn’t reflect the meaningful details users entered.
• Why: The UI wasn’t leveraging the backend job/recipient relations and some display fields were hardcoded.
• Fix: Updated Explore/ExploreJob mapping to show recipient identity, assets, and flags; removed hardcoded assumptions.
• Prevention: Define a stable “public job view model” and render directly from it; avoid duplicating business logic between screens.