A digital payment may take only seconds to complete. But when money moves across banks, card providers, and multiple financial systems, tracking exactly where it goes can be far more complicated.
For SoftFlex, this challenge came with an ambitious timeline: launching Travel&Check, a cross-border payment platform targeting users in South Korea, in approximately three months. The platform needed to support digital wallets, card payments, peer-to-peer exchange, and direct transfers, while accommodating different user roles, financial workflows, and external payment providers.
Building everything from scratch would have extended the launch timeline. Yet reusing an existing platform introduced its own challenges, from adapting payment workflows to maintaining transaction integrity and preparing for future integrations.
To address these requirements, Synodus joined SoftFlex in a hybrid software delivery engagement, contributing a 17-member engineering team to adapt, develop, integrate, and optimize the platform. Travel&Check went live in April 2026, approximately three months after kickoff, with development continuing to support new features, transaction visibility, and operational improvements.
Project goal:
- Launch a cross-border digital payment platform within three months while establishing end-to-end transaction traceability, supporting reliable reconciliation and dispute management, reducing dependence on a single card provider, and building a secure, compliance-ready foundation for international payment expansion.
About the client
SoftFlex is an IT and software development company with more than 50 employees. Its services span online payment solutions, custom web and mobile development, quality assurance, software testing, and UI/UX design.
Through Travel&Check, SoftFlex is developing a digital payment experience for users in South Korea, bringing together financial services such as fiat and cryptocurrency wallets, transfers, peer-to-peer exchange, and travel-oriented payment cards.
Business context & Challenge
A fast-moving payment market, with little room for financial errors
SoftFlex’s immediate priority was time to market. Rebuilding the platform entirely from scratch would have extended development beyond its intended launch window. Yet accelerating delivery could not come at the expense of transaction integrity.
Travel&Check was also more complex than a typical consumer payment application. Its operating model involved end users, agents, operators, settlement managers, sub-headquarters, and administrators, each with different responsibilities, financial flows, and commission rules.
A single transaction could involve a bank, a card provider, an internal ledger, and potentially blockchain events. These systems communicate asynchronously, meaning transaction updates may arrive late, out of order, or more than once. Without reliable processing and traceability, those conditions can create incorrect balances, duplicated actions, or transactions that operations teams struggle to reconcile.
Three additional constraints shaped the project:
- Provider dependency: Relying on a single virtual card provider created operational risk if issuance or transaction services became unavailable.
- Compliance and security: Identity verification, anti-money laundering controls, payment data protection, and requirements associated with Korean operations and Singapore-based partners had to be considered throughout development.
- Continuous production demands: The platform needed to accommodate changing business requirements, new third-party integrations, and traffic-related performance issues without interrupting ongoing delivery.
The business objective was therefore not simply to release features quickly. It was to establish a payment platform that could continue expanding while giving its operators greater visibility and control over financial transactions.
Project workflow
Synodus began working with SoftFlex in January 2026. After the initial production launch, development continued through successive feature releases and operational improvements.
| Phase | Focus | Timeframe |
|---|---|---|
| Foundation adaptation | Reused and adapted an existing platform; removed previous brand dependencies; developed mobile, back-office, and web components; integrated identity and verification services including KCB, AICC Happy Call, and ATS/WON verification. | Jan – Mar 2026 |
| Production launch | Released core capabilities including card payment, main card management, P2P transactions, and direct transfers. | Apr 2026 |
| Performance and feature expansion | Conducted four phases of performance optimization; delivered release v1.0.13, offer and URL management, and UseB face liveness and face comparison integrations. | May – Jun 2026 |
| Operational controls and card expansion | Developed chargeback dispute processes, Telegram notifications, and multi-provider virtual card capabilities; began MatchMove integration. | Jul – Aug 2026 |
| Continued development and partner validation | Worked on Matching & UMP, MatchMove UAT demonstration, in-app advertising v2.1, notification management renewal, and release v1.0.25. | Sep – Oct 2026 |
The engagement followed a feature-based delivery model. SoftFlex’s Product Decision Maker (PDM) established priorities, while the two teams coordinated requirements, technical decisions, testing, and production activities.
Solution: Reuse what worked, then engineer for what came next
Instead of rebuilding the payment platform from the ground up, the team adopted a “Clone & Extend” strategy: reuse an established foundation, remove dependencies on the previous product, and extend it around Travel&Check’s business requirements.
This approach shortened the path to production while allowing the team to focus engineering effort on the areas most specific to Travel&Check: payment flows, commission structures, transaction tracking, identity verification, and external provider integrations.
The resulting platform includes one Flutter mobile application, five back-office portals (PBO, ABO, SBO, OBO, and MBO), and a website. Together, these support consumer transactions and the distinct operational needs of agents, operators, settlement managers, and administrators.
Its capabilities can be grouped into four areas:
| Capability | What it supports |
|---|---|
| Payments and cards | Card payment and cancellation, main and virtual card management, P2P offers and exchange, direct transfers, and wallet-related services |
| Financial operations | Commission and settlement workflows, transaction tracking, reconciliation support, and chargeback dispute management |
| Identity and access controls | eKYC/AML workflows, identity and face verification integrations, and back-office IP management |
| Platform operations | Offer and URL management, notifications, Telegram alerts, in-app advertising, and integration with external services |
Underneath these features, the team used a modular, domain-oriented backend built with NestJS and TypeScript. Asynchronous processing and provider abstraction were incorporated to support transaction handling and reduce the effort required to integrate additional payment partners.
Technology stack
- Mobile: Flutter
- Back-office and web: React, Refine, Next.js
- Backend and data: NestJS, TypeScript, PostgreSQL, Redis, Bull/BullMQ, Neo4j, Google Pub/Sub
- Infrastructure and monitoring: Google Kubernetes Engine (GKE), Kubernetes, Helm, Redis Sentinel, Sentry, Firebase
The solution also depended on external services and partners, including KCB, KPS, UseB, Twilio, LiveChat, Fitz, and MatchMove.
Process: Engineering around the real constraints of payments
Making transaction histories reliable across asynchronous systems
One of the project’s most demanding components was the transaction tracking service.
In a payment ecosystem, events do not always arrive in the order developers expect. A delayed bank webhook, a repeated provider callback, or a blockchain event received at the wrong stage can affect how the platform interprets a transaction’s status.
To reduce those risks, the team introduced queue-based processing with concurrency controls, idempotency keys, and Redis locks. A transactional outbox pattern, scheduled jobs, and retry mechanisms with backoff helped manage failures between database updates and external processing.
But correct processing alone was not enough. Operations teams also needed to understand how money moved through different parties.
The team used Neo4j to represent transaction lineage, connecting financial activity across users, agents, operators, and settlement managers. This information became accessible through the PBO transaction tracking function, giving operations teams a centralized way to investigate transaction histories rather than reconstructing them manually across separate systems.
As tracking data grew, performance also became a concern. The team replaced individual tracking-log inserts with batch operations and added database indexes to improve retrieval efficiency.
The key engineering decision was to treat transaction traceability as part of the payment system itself, rather than a reporting feature added later.
Expanding virtual cards without locking the platform to one provider
Virtual card services introduced a different challenge: how to support additional providers without tightly coupling the platform to one partner’s APIs and operational rules.
The team designed a provider abstraction layer to accommodate Fitz and MatchMove, including handling situations where no provider was available.
MatchMove, a Singapore-based partner, required coordination across identity verification, card issuance, and transaction notification workflows. Its integration covered eKYC and face verification through a WebView SDK, temporary and permanent card issuance, transaction history, and real-time webhook processing.
The team also designed retry mechanisms for card issuance and transaction finalization, alongside push notifications triggered by provider events.
Compliance added another layer of work. Relevant anti-scam notification requirements associated with Singapore’s Monetary Authority were mapped to notification templates for POS, e-commerce, and ATM transactions, with implementation coverage tracked through Jira.
Because technical documentation and responses depended on an overseas partner, the teams consolidated open questions, coordinated integration decisions, and used a UAT demonstration as a checkpoint before production deployment.
This integration remained in progress as of October 2026. However, the multi-provider architecture established a foundation for reducing dependence on a single card service as additional partners become operational.
Stabilizing production while development continued
Once Travel&Check entered production, performance issues became an immediate engineering priority.
The team encountered Node.js event-loop lag, pod restarts during traffic spikes, and Redis timeouts. Investigations identified factors including heap memory pressure and CPU throttling.
Rather than approaching these as isolated incidents, the team conducted a four-phase performance optimization effort. Work included adjusting application memory and infrastructure resources, applying rolling updates, and running JMeter load tests to evaluate system behavior.
These improvements took place alongside regular feature development, requiring the team to balance production stability with an active release schedule.
The project documentation records the optimization work but does not provide verified uptime, latency, or throughput improvements. Those remain important measures for evaluating its longer-term operational impact.
Keeping decisions aligned across two delivery teams
Travel&Check used a hybrid engagement model involving 17 Synodus specialists: one Business Analyst, three Technical Leads, four Fullstack Developers, two Mobile Developers, one Frontend Developer, two Backend Developers, two Quality Control specialists, and two DevOps engineers.
They worked alongside SoftFlex’s internal business analysis, development, quality control, and operations teams.
When technical issues arose, Synodus’s Technical Leads and SoftFlex’s developers investigated causes, reviewed alternatives, and proposed a solution. The PDM retained final decision authority.
To manage changing requirements, the teams followed a structured feature workflow:
Requirements → Software Requirements Specification → Design → Development → QA → Staging → Production
Jira tracked epics, tasks, and defects, with standardized Git workflows supporting development and releases. Version-controlled requirements, SRS documents, test cases, issue logs, and meeting records helped preserve context as the product evolved. Slack, Telegram, and Google Drive supported day-to-day coordination.
The team also used Claude to assist with drafting specifications and API documentation, comparing code against requirements, investigating production logs, and preparing Jira tickets. Outputs were reviewed by the responsible Business Analyst or Technical Lead before use.
AI services in the product itself, including UseB face verification and AICC Happy Call, were third-party integrations rather than models developed or trained by the team.
Outcomes
Travel&Check’s results reflect both a completed initial launch and an ongoing software delivery engagement.
| Area | Recorded outcome |
|---|---|
| Time to market | Production go-live in April 2026, approximately three months after kickoff |
| Platform adoption | 100,000+ app installations, 80,000+ registered accounts, and approximately 15,000 users reported in a separate project update. |
| Platform delivery | One mobile application, five back-office portals, and a website operating in production |
| Continuous development | More than 25 production releases reported, alongside hotfixes and ongoing feature work |
| Transaction visibility | PBO transaction tracking enables operations teams to investigate transaction histories within the platform |
| Provider expansion | Multi-provider architecture developed, with MatchMove integration progressing through UAT toward production |
| Delivery coordination | Versioned requirements, test documentation, and issue records provide a clearer reference for development, quality control, and onboarding |
The most meaningful operational change is the visibility available to the teams managing transactions. Rather than relying solely on manual investigation across disconnected systems, operators can use the platform’s tracking capabilities to follow transaction activity and support reconciliation or dispute handling.
Chargeback workflows, access management, and notification processes also provide more structured operational controls as the product expands.
The available evidence demonstrates delivery progress and new operational capabilities but does not yet establish quantified reductions in reconciliation time, dispute rates, or production incidents.
What’s next?
Travel&Check continues to evolve beyond its initial release.
Upcoming priorities include completing MatchMove’s production integration and related MAS compliance work, expanding virtual card capabilities through digital wallet and tokenization support, and enabling future integration with Apple Wallet, Samsung Wallet, Apple Pay, and Samsung Pay.
The roadmap also includes improvements to user tiers and access permissions, settlement workflows, filtering, and the PBO overview.
Synodus remains engaged in feature development, maintenance, and operational support alongside SoftFlex’s internal teams.
For a payment platform, a successful launch is only the beginning. Every new provider, transaction type, or operational workflow introduces more dependencies to manage.
Travel&Check illustrates why effective software delivery in FinTech requires both speed and engineering discipline: getting a product into the market quickly, while building the visibility, controls, and flexibility it needs to keep moving forward.
