Open Fabric

Building a Buy Now, Pay Later payment platform from scratch for Southeast Asia.

Open Fabric payment platform

At a glance
Industry
Financial technology · BNPL
Region
Singapore · Southeast Asia
Engagement
Embedded team of eight engineers

What we did
  • Multi-tenant cloud platform
  • Microservices: data, transaction, logging, card
  • TypeScript & Kotlin backend
  • React + TypeScript merchant interfaces
  • AWS Lambda, EC2, S3, DynamoDB
  • PCI DSS compliance & encryption
  • Docker + automated CI/CD
  • Four-environment delivery pipeline
  • Singapore-region deployment
  • Embedded eight-engineer team

Outcomes

Live

A greenfield BNPL platform shipped end-to-end — ready for the first merchants and payment providers across Southeast Asia, with the core data model in place to grow from.

Core

We owned the data layer every transaction passes through — the customer, store, provider, and transaction model the rest of the product was built on top of.

Open Fabric platform overview

Overview

Open Fabric is a Buy Now, Pay Later payment platform started by operators out of PayPal and Grab. The plan was a single network making it simple for stores across Southeast Asia to accept digital and deferred payments — one integration on the merchant side, one on the provider side, Open Fabric carrying the rails between.

We put a team of eight engineers alongside the founders to build the technical foundation from scratch — a multi-tenant cloud platform that connects merchants with payment providers and routes transactions between them. Our remit was the core data system: the customer, store, provider, and transaction model that every other part of the product would sit on top of.

The platform shipped on the launch window the team had committed to, and Open Fabric carried it into one of Southeast Asia’s most competitive fintech segments. The partnership set the technical baseline they grew from.


01.

A multi-sided payments problem, on a startup deadline.

Merchants · shoppers · providers · PCI DSS

Open Fabric had to be three platforms at once. Merchants wanted more payment options to offer at checkout. Shoppers wanted methods that felt secure and quick. Providers wanted distribution across that growing merchant network. Under all of it sat a fintech-grade engineering bar: high transaction throughput to handle, PCI DSS compliance to meet, sensitive card data to encrypt and segregate, and a runway to scale as both sides of the network grew. None of it was unusual on its own; together, on a launch deadline, it needed the kind of team that's hard to assemble cold.

Open Fabric business challenges diagram — market complexity across merchants, shoppers, and payment providers

02.

Multi-tenant, microservice-shaped, from day one.

Data · transaction · logging · card services

We built a single platform that could safely host many merchants and providers behind one infrastructure — multi-tenant by design, with strict data separation enforced service-by-service. Even at the early stage, the system was sliced into discrete services so it could keep moving as the product grew: a data service holding the core domain model, a transaction service running payments end-to-end, a logging service auditing every step, and a card service walled off around the most sensitive payment information. TypeScript and Kotlin made up the backend; React and TypeScript carried the merchant and provider interfaces.

Open Fabric system architecture diagram showing service relationships

03.

Cloud-native on AWS, sitting next to its users.

Lambda · EC2 · S3 · DynamoDB · Singapore region

The platform lived in AWS from day one. Most services ran on Lambda so capacity tracked demand without anyone watching, Docker carried the parts that needed long-running isolation, and S3 with CloudFront held the static surface — merchant dashboards, documentation, the rest. We picked the Singapore region to put compute next to the Southeast Asian users the product was being built for, which kept latency on the experience side of the equation rather than the engineering side.


04.

Shipping at startup pace, with the seams kept tight.

Local · CI · staging · prod · trunk-based

A four-stage pipeline kept the team honest as they shipped — local development for the first cut, continuous integration on every change, staging as a production-like mirror, then production itself. Trunk-based development with short-lived branches kept the merge surface small, and coordinated releases lined up deployments across services that depended on each other. Eight engineers — senior backend, frontend, DevOps — slotted into Open Fabric's own team with daily standups, technical design reviews, code reviews, and joint on-call rotations, as if they'd been there from day one.

Open Fabric deployment process workflow — release stages from local to production

More case studies


Talk to us

A few sentences about your team and what you're building is usually enough. We reply within three working days.

See more work