Building a Multi-Bank QR Payment Platform for SMBs

The Problem

Cyberland's SMB clients were managing customer relationships on our platform — but payments were happening outside it. Clients were collecting payments through bank transfers, cash, or separate payment apps, then manually reconciling records in the CRM. We had no visibility into payment status, and our clients had no single source of truth.

The opportunity was clear: close the payment loop inside Cyberland, increase platform stickiness, and unlock a new revenue stream through transaction fees.

Discovery → Strategic Bet

Who we were building for

Two users, one transaction — but entirely different failure modes.

Centre Finance Manager — responsible for invoicing parents, chasing outstanding payments, and reconciling collections against the CRM. Spending 2–3 hours daily cross-referencing bank statements with records. When payments arrived via bank transfer, she had no way to know a parent had paid until the statement cleared the next business day — so chasers went out to parents who had already settled, damaging trust.

Parent Payer — paying tuition and enrichment fees across DBS, OCBC, or UOB. Comfortable with PayNow on mobile, but had no in-app confirmation after transferring. Called or messaged the centre to verify — adding to the finance team's queue.

Pain point prioritisation

Five client interviews surfaced three recurring pain points: no real-time payment visibility across the platform, daily manual reconciliation consuming 2–3 hours of finance time, and a fragmented collections process that mixed bank transfers, cash, and third-party apps with no single source of truth. All three were real — but manual reconciliation was the primary filter. It had the highest daily frequency, the highest error cost (misallocated payments created compliance issues at audit time), and was universal across every client we interviewed. Solving it directly addressed both users: the finance manager's workload and the parent's uncertainty about whether their payment had landed.

One detail stood out across interviews: clients' parent communities weren't banking with one provider — they spread across DBS, OCBC, and UOB.

The strategic bet

The multi-bank insight came from engineering scoping, not discovery. When we mapped a DBS-only integration, the question surfaced immediately: what happens when the next client asks for OCBC? PayNow's architecture answered it. As a standardised scheme governed by the Association of Banks in Singapore, every bank's API conforms to the same spec — making a common abstraction layer the obvious path. The alternative — DBS-only first, expand later — would have served a fraction of pilot demand and required architectural rework when the second bank arrived.

Before committing any engineering hours, we sent priced quotations — setup fee, monthly subscription, per-centre structure — to five prospective clients and asked for a soft commitment. Four expressed strong interest; three converted to pilot. That was the green light: build once, ship across banks — trading higher upfront cost for compounding leverage. Commercial validation before engineering commitment is what made this a bet, not a feature.

We set annualised payment volume processed through the platform as our north star — the signal that clients had adopted payments as their primary collection method, not a fallback alongside cash and bank transfers.

Go-to-Market: Partner Sequencing

DBS combined the broadest consumer reach in Singapore with the strongest partnership and support ops of the major banks we considered — and that second factor was sequencing-critical. With an 8-week integration target, a slower partnership team would have pushed certification to week 12 or 14, delaying the credibility flywheel that the rest of the GTM depended on. Completing the DBS integration earned us Official Software Integrator status: a bank-issued public credential that lowered procurement objections in pilot sales conversations and made OCBC and UOB partnership discussions materially faster — both banks could see we had already passed bank-grade compliance, so their own vetting was shorter.

Pilot clients were selected by stacking two filters: largest clients by payment volume potential, and highest pain intensity in finance and reconciliation workflows. The stack was deliberate — high-value clients with acute pain gave us the highest probability of activation and the highest feedback signal per engagement. OCBC and UOB followed in sequence driven by commercial pull: prospective clients in the sales pipeline were asking for their banks by name, and because the abstraction layer made each new integration cheap, we sequenced by demand rather than engineering capacity.

The Process

7a. Partnership Initiation & Scoping — Weeks 1–2

I initiated formal contact with DBS's fintech partnerships team and submitted our application for API access under their integrator programme. In parallel, I ran internal scoping with engineering to define integration architecture and surface technical constraints early.

7b. API Integration & Compliance — Weeks 3–5

DBS's payment API required compliance documentation — data handling policies, security architecture sign-offs, and a technical review of our implementation. I coordinated the compliance response with our CTO and prepared the full documentation package.

I also wrote the PRD covering: QR generation, payment status webhooks, reconciliation logic, and the in-app payment tracking UI.

7c. Testing & Rollout — Weeks 6–8

We ran a closed beta with three enterprise clients who had been requesting payments. I personally onboarded each of them, walked through setup, and collected structured feedback. Their involvement surfaced edge cases — partial payments, refund handling, timeout states — that we resolved before general availability.

7d. Post-Launch Bank Expansion — OCBC & UOB

[PLACEHOLDER — to be completed. Outline: how the abstraction layer made subsequent integrations faster; timeline for OCBC and UOB onboarding; whether compliance requirements differed; any integration surprises.]

7e. Team

[PLACEHOLDER — to be completed. Outline: team composition (PM, engineering, CTO involvement, DBS partnership contacts); your specific scope vs. what engineering owned; any external compliance or legal support.]

Architecture Decision

The Common PayNow Abstraction Layer holds the bank-agnostic logic: QR generation, webhook processing, reconciliation, and a reusable test framework. Below it, each bank gets a thin connector scoped to auth, endpoints, and webhook normalisation — and not much else. The shared layer carries the weight; the connectors handle only what differs per bank.

Stakeholder Navigation

The hardest part wasn't the technology — it was three-way alignment between our internal team, DBS's partnership and compliance teams, and enterprise clients with contractual expectations on payment timelines.

I maintained a shared decision log visible to all parties. Whenever a DBS compliance requirement changed our implementation plan, I translated the impact for the client-facing team immediately — no one was surprised by a delay because they were always one step ahead of it.

DBS's team later cited our documentation quality and communication as the reason the review moved faster than typical.

[PLACEHOLDER — add one specific tradeoff moment: a decision point where two stakeholders wanted different things, what you decided, and why.]

Outcomes

Platform Proof

PayNow is governed by the Association of Banks in Singapore (ABS) as a standardised scheme. Every bank's API conforms to that spec, which is why we designed for a common connector layer from day one.

We built once: a shared connector, a reusable invoice and reconciliation layer, and a portable QA test suite. Each new bank required only API-specific adjustments and client-specific payment page tweaks — scoped customisation, not a rebuild.

DBS took 8 weeks as the first integration. OCBC and UOB followed at ~2 weeks each — a ~75% reduction in subsequent integration time across 3 live banks.

Client Impact

Before, parents waited up to 3 business days for payment confirmation — and in that gap, finance teams sent chasers that often landed on parents who had already paid, eroding trust.

After, real-time webhooks marked invoices paid the moment funds cleared. Auto-matching eliminated manual reconciliation — 2–3 hours of daily finance work dropped to ~1 hour of exception handling — and removed the misallocation errors that came with manual transcription.

Strategic Outcomes

Integrated payments unlocked two revenue lines: a one-time setup fee per client onboarding, and a recurring monthly subscription charged per centre, scaling with client footprint as clients grew.

DBS Official Software Integrator status became a sales asset in enterprise deals. Finance and compliance buyers needed a credibility signal before procurement moved — integrated payments, backed by bank certification, gave them that signal. In a category where most CRMs don't touch payments, this was a positioning advantage.

Customer Feedback & Iterations

The closed beta with three pilot clients surfaced edge cases that the PRD hadn't fully specified: partial payments (a parent paying a deposit, not the full invoice), refund handling when a session was cancelled, and webhook timeout states where payment cleared at the bank but confirmation didn't reach the platform. Each was a support ticket in waiting — we resolved all three before general availability.

Post-launch, the feedback split cleanly across the two user types. Finance managers reported that manual reconciliation time dropped from 2–3 hours to around 1 hour of exception handling — the daily rhythm shifted from chasing payments to reviewing exceptions. Parents flagged one recurring friction: they wanted an in-app confirmation message after payment, not just a status update inside the centre's portal. That became the first iteration after launch — a lightweight payment confirmation notification sent to the parent immediately on webhook receipt.

The request pattern that emerged in month one — multiple clients independently asking for PayLah and credit card support — was the feedback signal we hadn't anticipated. It told us the payment method scope was under-specified at launch; clients assumed QR was a starting point, not the product.

What I'd Do Differently

Publish the roadmap at launch, not after

I scoped the initial release to PayNow QR only to hit the 2-month target — the right call. But I didn't publish a payment method roadmap at launch. In the first month post-launch, we fielded the same request for PayLah and credit card support individually from multiple clients. A public roadmap would have converted that noise into confident wait-and-see.

[PLACEHOLDER — add 1–2 more lessons. Suggested areas: anything unexpected in the multi-bank compliance process; how you'd approach the abstraction layer decision differently with hindsight; resourcing across the bank expansion phases.]