A successful payment has very little dramatic potential. A card goes in, approval comes back, somebody leaves with a purchase. The audience wants the performance over quickly and has no desire to meet the cast. There is a particular satisfaction in this kind of engineering: the work can matter to a customer who will never learn the supplier’s name. Its public appearance is an approval message, followed by someone reaching for a shopping bag. Yash Kapadia has made his working life in the machinery behind that small, welcome anticlimax.
The founder and CEO of OmniPayments came to that machinery as a developer at Tandem Computers. When he left Tandem, he kept working with its NonStop platform and founded Opsol Integrators. OmniPayments grew out of that business. His career changed shape from writing software to running a company, while the underlying technical concern remained recognisable: applications that people depend on staying available.
The business traces its beginnings to 1995, when its speciality was bringing open-source solutions onto NonStop servers using Open System Services. That origin matters. Kapadia’s starting point was the practical work of making different kinds of software live together. Long before cloud migration entered the conversation, he was dealing with the awkward introductions between systems.
In a banking application, those introductions have consequences. A payment switch routes a request from a terminal towards the institution that can authorise it. The customer sees a few seconds; behind the counter sits a collection of connections, rules and older investments. Replacing any part requires rather more care than changing the sign above the door.
An affection for the difficult middle
By 2006, Kapadia was describing Opsol’s Integration Hub as the connecting layer between banking channels and back-office applications. He called the company’s focus “mission-critical applications with high transaction volumes”. That phrase is a useful guide to his career. It favours the demanding middle of a system, where separate technologies have to cooperate and an attractive demonstration still has to survive actual use.
His work also reached beyond payments. The OmniMessaging deployment for Japan’s KDDI involved 3,000 CPUs. Messaging and card authorisation belong to different businesses, but both give an engineer plenty to think about when volume and availability arrive together. Kapadia’s technical history includes transaction switches with direct Visa and Mastercard interfaces and integration hubs connecting multiple channels.
A 2008 project in Shelby County, Tennessee, gives his thinking a more human setting. The county needed to bring public information services onto newer technology, train its staff and control costs. Opsol worked alongside Chrysalis and HP. Kapadia argued for combining a robust product with customisation, rather than forcing an organisation to make expensive operational compromises around a software package.
“Getting that mix right for the customer” was his concise description of the task. The detail is revealing: the product and the customer’s existing operation both have a claim on the design. Software may be exceptionally fond of its own logic. A county office, like a shop queue, has other appointments.
“Getting that mix right for the customer”
Yash Kapadia · on product and customisation, 2008
A cloud with room for smaller retailers
In 2015, Kapadia was writing about a particular gap in retail payments. Large retailers could buy their own transaction switches and reduce their dependence on acquiring banks’ transaction fees. Medium-sized retailers might want the same arrangement, yet struggle to justify buying and operating the necessary servers. The economics drew a line through the market.
OmniCloud offered a way across it: host switches for multiple retailers on NonStop infrastructure and charge for the service. His account also described dedicated systems for retailers ready for their own switch, while leaving the purchasing and operational burden inside the cloud service. The proposal made hosting part of the product’s usefulness.
That approach continued through OmniCloudX, a private NonStop cloud offering for payment processing and disaster recovery. Kapadia’s attention to infrastructure came with attention to who could afford to use it. The engineering problem and the commercial problem shared a desk. A switch that a retailer could never justify purchasing would remain a rather theoretical convenience.
There is a pleasingly literal scene from the Atlanta NonStop user gathering in 2017. Kapadia stepped in for the planned presenter and spoke about OmniCloudX. A photograph shows him below a projection screen in a Home Depot theatre, explaining the service. Payment infrastructure had found itself a stage in a retailer’s premises. The setting suited the subject.
Six months inside a department store’s payments
JCPenney provided a concrete test of the migration work. In 2019, Kapadia was taking its switch replacement to the European Technical Boot Camp audience. The retailer needed payments across internet, store and mobile channels. OmniPayments supplied a new switch, and the full migration took six months.
An essential part of the arrangement was coexistence. The new software could work with existing applications, letting JCPenney retain investments while moving towards a different architecture. That word, coexistence, deserves its modest place in a technology story. It acknowledges that a functioning business already contains things worth keeping, along with the things it wants to change.
JCPenney’s technology leadership praised the team’s dedication and willingness to engage with questions. The achievement belonged to the retailer and supplier working together. For Kapadia, it added a recognisable customer example to a career built around integration: a department store could change an important part of its payment operation within a defined period.
His comments on card payments also show an eye for what happens at the till. During the US chip-card rollout, he broke down the customer’s sequence: checking whether a reader accepted chips, choosing debit or credit, entering a PIN or signing, considering cashback, confirming the amount. Each step helped explain why paying could feel slow.
He pointed out that processing capacity and network congestion were not exhausting the system in that discussion. The interaction itself consumed time. A queue offers a stern editorial judgement on technology: the customer experiences all the prompts together, however neatly the engineering teams have divided their responsibilities. Kapadia was willing to follow the transaction all the way to the receipt.
The library needed somewhere to live
One of Kapadia’s more telling contributions involved a software library rather than a payment contract. ITUGLIB, the NonStop community’s collection of software, needed support for its hosting costs. In 2015, he offered to put its system in an OmniPayments data centre in San Jose. The company also took on HP maintenance fees.
The gesture had a practical shape. Power, cooling, connectivity and maintenance are the unromantic conditions under which shared software remains available. Offering a place to run the system addressed those conditions directly. For a community organised around continuously available computing, keeping its own tools available was a fitting use of the company’s resources. It is an apt detail in the life of someone whose business began with open-source software on NonStop.
His public work also includes recruiting developers and explaining technology to fellow practitioners. On LinkedIn in 2015, he sought Tandem coders with C, C++ and Java experience. At conferences he discussed switches, fraud prevention and, later, public-cloud deployment. The founder’s role has continued to include the technical community that surrounds the product.
There is a related practical streak in his discussion of self-service banking. In 2017, he described banks wanting to reduce the expense of human involvement while making machines behave more like people. OmniPayments had added loyalty-programme support in response to customer requests. Even a business devoted to automation still had to account for how people wanted to be treated.
OmniPayments offered a home for ITUGLIB in San Jose and took on HP maintenance fees.
Chile, Taiwan, and the next version of the same question
By April 2024, Kapadia’s conference agenda included OmniPayments in Google Cloud, alongside exports to Splunk and Kafka and tools for monitoring system performance. The technology vocabulary had expanded. The work still involved helping customers run transaction systems, observe what they were doing and move between generations of infrastructure.
In January 2025, he described OmniPayments’ work with Chile’s Redbanc on virtualised HPE NonStop in Google Cloud VMware Engine. Redbanc wanted to retain its NonStop foundation while moving infrastructure into the cloud. OmniPayments supplied professional and consulting services, including work on a third node on a separate platform.
The project made continuity an architectural choice: existing expertise could accompany a change in where systems ran. Kapadia’s account reported a tenfold improvement in compilation time for a switch environment. That was a development-process result, with a specific scope, rather than a measure of how quickly a customer’s card payment would be approved.
In September 2025, his account of Union Bank of Taiwan offered another variation. Working with the bank’s Union Information Technology Center and HPE GreenLake, OmniPayments replaced the legacy COSES system. The described deployment served more than 50,000 merchants and 90,000 terminals, with over 50 customisations and knowledge transfer to bank staff.
Training belongs beside those numbers. Helping a customer operate the result gives an upgrade a life beyond its installation. The Taiwan work included routing to the bank’s authoriser or the national switch, and an emphasis on operational independence. It fits the concern Kapadia expressed years earlier in Shelby County: a product has to meet the organisation where it works.
Across these projects, his ambition has remained concrete: modernise payment software, maintain availability and lower the cost of operating it. The settings have changed from county services and retail switches to cloud infrastructure and banking networks. The customer’s wish is wonderfully undramatic. Buy the thing. Receive approval. Get on with the day. Kapadia has spent decades working on everything that makes that possible.