- Platform
- Web and Mobile App
- Duration
- 14 weeks
- Industry
- FinTech
- Read time
- 8 min
Short answer
RaftLabs built a mobile point-of-sale and merchant-acquiring platform for a UAE FinTech operator (under NDA). Merchants accept contactless cards, QR codes, tap-to-pay, and payment links from a phone, with no hardware terminal, backed by a merchant web dashboard and an internal admin console. It processed 10,000+ transactions and 5,000+ downloads in its first three months, holds a 4.8-star Google Play rating, and lifted sales about 25% for merchants in previously cash-only locations. Built in 14 weeks on Flutter, Next.js, Node.js on AWS Lambda, and Hasura over PostgreSQL, it runs two payment processors (PayBy and Stripe) behind a single transaction ledger and passed a 2025 PCI DSS audit. It is now an ongoing engagement at version 1.17.
For small merchants in the UAE, especially field sellers, market vendors, and shops in remote areas, the barrier to digital payments is not demand. Customers already expect to pay by card or phone. The barrier is access: a traditional POS terminal needs hardware, a merchant account, and fixed infrastructure that smaller operators cannot justify or qualify for.
A UAE FinTech operator came to us to close that gap. We built a mobile POS platform where merchants accept contactless cards, QR codes, tap-to-pay, and payment links through an app on the phone they already own. No terminal, no counter. The platform processed 10,000 transactions in its first three months, reached 5,000+ downloads with a 4.8-star Google Play rating, and lifted sales about 25% for merchants in previously cash-only locations.
The real work sat underneath the app. Handling live money in the UAE means Central Bank regulation and PCI DSS from the first line of code, so the product was never "a payment app." It is a regulated merchant-acquiring platform, with a dead-simple POS on top. That platform now runs at version 1.17, moves money through two payment processors, and has passed a 2025 PCI DSS audit.
before & after
What changed
- Small merchants and field sellers could not accept digital payments without buying hardware POS terminals and qualifying for merchant accounts, a cost and process barrier most could not clear
- The operator had no compliant acquiring backbone: onboarding, KYC, per-merchant fee rates, settlement, and disputes all had to be built to regulation, not bolted on afterward
- Merchants in remote areas or temporary locations had no way to accept cashless payments, losing sales to competitors with modern payment infrastructure
- No transaction data existed for merchants relying on cash, so there was no visibility into sales patterns, peak times, or settlement
- Supporting several payment methods (cards, QR codes, tap-to-pay) meant several separate integrations that small operators had no technical capacity to manage
- Merchants accept contactless cards, QR codes, tap-to-pay, and payment links from a single app on their existing phone, with no hardware purchase required
- Onboarding, KYC, per-merchant fee rates, refunds, and settlement run through one compliant platform the operator can audit end to end
- Field sellers, market vendors, and remote-area merchants accept digital payments anywhere with a data connection, and offline sales sync on reconnect
- A real-time dashboard shows each merchant's transaction history, daily totals, payment-method breakdown, and peak periods
- New payment methods and a second payment processor activate at the platform level, without merchants changing their app or their workflow
What we had to solve
- 01
Compliance had to shape the architecture, not sit on top of it
In the UAE, handling real money means Central Bank payment regulation and PCI DSS for card data from day one. That is not a feature you add before launch: it decides how onboarding, card handling, settlement, and permissions get built. The harder constraint was doing all of it without an onboarding or checkout flow so heavy that a field seller abandons it. A compliant app nobody wants to use fails as completely as a non-compliant one. We designed for both up front, which is why regulatory approval did not stretch the 14-week timeline, and why the platform later passed a 2025 PCI DSS audit.
- 02
One transaction ledger sitting behind two different payment processors
Payments route through PayBy, the primary UAE processor, for local AED transactions, and through Stripe for international cards and payouts. The processor is chosen per merchant, but the rest of the platform cannot be forced to care which rail a payment took. We put a single payment-intents ledger in front of both: every transaction, refund, and settlement lands in the same record, whichever processor handled it. That decision paid off later, when adding the second processor became a configuration change rather than a rewrite.
- 03
Money had to move reliably on weak connections, then reconcile without gaps
Merchants in markets and remote areas often work on spotty mobile data, and a POS that drops payments trains people to stop trusting it. The mobile app queues transactions offline and syncs when the connection returns, invisibly to both the merchant and the customer. On the platform side, gateway webhooks are signature-verified, fanned out to per-event SQS queues, and drained by idempotent workers that reconcile each payment by its natural key. Records dead-letter after five failed attempts instead of silently disappearing. The outcome is a two-phase settlement where the initial charge and the confirmed result always agree.
outcomes
What we achieved
Merchants in remote areas were cash-only by default. No digital payment solution worked without a fixed terminal, a stable connection, and hardware investment.
Merchants in remote and cash-only locations turned away anyone without cash. Every card-carrying customer who walked out was a lost sale.
Small merchants had no affordable path to accepting digital payments. Hardware POS required capital and merchant-account qualification most could not access.
The payment tools available to small merchants were either expensive hardware or consumer apps not designed for merchant transaction management.
What clients say
In the client's words
Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.
RaftLabs helped us develop a mobile POS app that enabled smooth cashless payments. Their clear communication and collaborative approach kept the project running smoothly from start to finish, making the entire process efficient and successful.
Your merchants need digital payment capability but hardware POS is out of reach?
the build
What we built
The platform is two web portals and a serverless backend behind the mobile POS: a merchant dashboard, an internal admin console, and the acquiring engine that moves and reconciles money.
Merchants take tap, QR, or link payments from one app, with no card reader attached
A customer taps a card or phone to the merchant's device, scans a QR code, or pays through a shared link. Every method routes through the same transaction record and the same confirmation flow, so the merchant sees one consistent screen no matter how the customer chose to pay. Contactless needs no attachment: the phone's NFC chip handles the tap.
Payments work at a stall, a doorstep, or a client site, and offline sales sync on their own
Merchants accept payments at a market stall, at a customer's location, or at a delivery handoff using the same app they use at a counter. When connectivity drops, the app holds the transaction and completes it automatically once the connection returns. The merchant sees the same confirmation either way, and the platform stays the source of truth on reconnect.
Onboarding, KYC, and roles built for a regulated operator
Merchants sign up through multi-step KYC that captures directors and shareholders and closes with a Zoho Sign agreement. Cognito enriches each session with claims that Hasura turns into row-level permissions, so a super-admin, a merchant-admin, and a cashier each see only what their role allows. Soft-verified merchants trade under cumulative volume caps until full verification clears.
A merchant dashboard and an admin console reading from one live ledger
Merchants see daily totals, payment-method breakdown, peak periods, and full history with export. The operator's internal console approves merchants, sets per-merchant fee rates through invite codes, and pulls settlement and dispute data across the whole base. Both portals read from the same payment-intents ledger, so the numbers a merchant sees and the numbers the operator settles never drift apart.
Engagement
How we worked together
- 01Weeks 1–2
Discovery and scoping
We map the problem before writing code. Two weeks of technical audit, stakeholder interviews, and prototype, so both teams align on scope and risk before sprint one. - 02Ongoing
Two-week Agile sprints
Each sprint ends with working software, not a status update. You review a real build, request changes, and approve before we move forward. No surprises at handover. - 03Ongoing
Daily async updates
Slack for daily progress, Asana for task visibility, weekly video calls for decisions. You have full visibility without needing to attend every meeting. - 04Final
Handover and warranty
Full code handover with deployment runbooks and documentation. Thirty-day warranty period for production issues at no extra cost.
stack
Why we chose this stack
- 01FlutterThe POS app needed identical behaviour on Android and iOS across a wide range of low-cost merchant devices. Flutter's single codebase delivered consistent payment flows, camera access for QR scanning, and NFC tap-to-pay without maintaining two native builds.
- 02Next.jsTwo web portals, the merchant dashboard and the internal admin console, needed fast server-side rendering so merchants on lower-bandwidth connections could reach transaction, analytics, and settlement data without loading delays.
- 03Node.js on AWS LambdaThe acquiring backend handles payment processing, gateway webhooks, SQS-based reconciliation, and Cognito auth. Running it on Lambda scaled cleanly with spiky transaction volume, so the operator paid for compute during trading peaks, not for idle servers.
- 04Hasura + PostgreSQLA GraphQL layer over a roughly 40-table domain model, with the payment-intents ledger at its centre. Hasura enforced row-level permissions from JWT claims, and PostgreSQL gave the transactional integrity and audit history that money movement and settlement reconciliation demand.
Common questions about mobile POS and merchant-acquiring development
Compliance was designed in from the start and validated by a 2025 PCI DSS audit. Card data is encrypted in transit with the gateway's public key and never stored in plaintext: only the last four digits, card brand, issuing country, and a gateway token persist. Risk-based 3-D Secure steps up above per-merchant limits. Building this up front, rather than retrofitting it, is why regulatory approval did not delay the 14-week launch.
Yes. PayBy handles local AED transactions as the primary UAE processor, and Stripe handles international cards and payouts, including Connect for onboarding. The processor is selected per merchant, but a single payment-intents ledger is the source of truth for both. Because the ledger was built as the unified record from day one, adding the second processor later was a configuration change, not a rewrite of the platform.
Reconciliation is asynchronous and two-phase. The synchronous charge writes the initial record; then a signature-verified gateway webhook confirms the amount received, final status, card metadata, and settlement. Webhooks fan out to per-event SQS queues, each drained by an idempotent worker that upserts the ledger by natural key. Records dead-letter after five failed attempts, so a spike or a retry never produces a duplicate or a lost payment.
The app keeps an offline queue that captures the payment intent and holds it securely on the device when connectivity drops. When the connection returns, the queue processes automatically and the sale completes as normal. Merchants see a brief status indicator but take no action: the queuing is handled by the app, and the platform stays the source of truth once the device syncs back.
Onboarding is multi-step KYC that captures directors and shareholders and closes with a Zoho Sign e-signed agreement. Merchants move through soft-verified and fully-verified tiers, with soft-verified accounts trading under cumulative volume caps until full checks clear. Cognito enriches each session with claims that Hasura converts into row-level permissions, so super-admin, merchant-admin, and cashier roles each see only the data their role allows.
This was a deliberate trade-off. Hosted fields would shrink the PCI scope, but they would break the native tap-and-go feel that a mobile POS needs. So card data is encrypted on the device with the gateway's public key, tokenized, and never stored in plaintext, and the wider PCI scope is managed through that encryption, tokenization, and the audit. The offline queue stays in the mobile client; the platform reconciles it on reconnect.
It is an ongoing engagement. We shipped the initial launch in 14 weeks, and the platform has since matured to version 1.17 across roughly 59 releases, added the PayBy processor, and passed a 2025 PCI DSS audit. A regulated payment platform is rarely finished at launch: it keeps evolving with new processors, new markets, and new compliance requirements.
The initial launch took 14 weeks: the Flutter app, two Next.js portals, the serverless acquiring backend, offline queuing, and the gateway integrations. Compliance architecture and reliable reconciliation were the most time-intensive parts, because both are decisions that cannot be retrofitted. A single-method platform with no offline requirement would be faster. Contact us to scope by the payment methods, markets, and compliance rules your platform needs to cover.
