2006 — Present · Pune, India

Nineteen years,
five rooms.

Every company on this page solved the same problem at a different scale: make a payment move, and make sure it only moves once. This is how that got harder, and better, each time.

2006 — 2008

Indicus Software

Software Engineer · Pune

The first eighteen months, fresh out of a BE in Information Technology — general-purpose Java/J2EE consulting, not payments yet. The clients were a grab-bag: a Japanese consumer-finance company, a Japanese automaker, a niche jobs portal. The common thread was building workflow-driven web apps against whatever backend a client already had, which turned out to be good training for everything that came after.

  • Built a customer-registration system for a Japanese consumer-finance company, integrating third-party credit-bureau lookups into the onboarding flow.
  • Delivered a warranty-claim review system for Nissan Motors Japan, validating dealer claims against automated filters before routing exceptions for review.
  • Built candidate and recruiter workflows for a jobs portal serving the molding industry.
Java / J2EEStrutsHibernateOracle / PostgreSQL
2008 — 2020

Infonox (a TSYS Company)

Senior Software Developer → Manager, Application System Development · Pune · 12 years

This is where the payments habit actually started. Joining Infonox — an acquirer-side company that TSYS had already bought — flipped the focus from generalist web apps to merchant infrastructure: Enterprise Tools, a configurable framework banks used to build their own merchant-onboarding workflows, and Transending, a merchant-management ERP with underwriting (credit, OFAC, and match-report checks) and Harmony, the interface giving end-to-end visibility into a transaction's lifecycle across products. Over twelve years the role grew from developer to manager, and the scope grew from onboarding to fraud.

  • Built Enterprise Tools' configurable eApplication framework, letting acquirers define their own merchant-onboarding workflows without a custom build.
  • Delivered Transending's underwriting module — automated credit, OFAC, and match-report decisioning — plus Harmony, the inter-product bridge for transaction-lifecycle visibility.
  • Integrated with TSYS Card Guard, configuring fraud rules and card controls for the authorization engine underneath card transaction decisions.
  • Grew from individual contributor to leading a 10-person team spanning backend engineering and automation QA.
  • Designed the team's technical hiring framework, integrating HackerRank assessments to standardize evaluation across every open role.
JavaStruts / SpringMyBatis / HibernateFraud & AuthorizationTeam Leadership
2020 — 2021

SpendLabs

Technical Director · Pune

A short, intense stop with an outsized architectural mark — and one that started with a gap: no prior Scala or Akka experience. Taught myself the stack first, then wrote the ramp-up plan the rest of the team used to learn it. The mandate was blunt: take a monolith apart into event-driven microservices without losing a single live customer along the way — joined in March 2020, live in production by January 2021. That constraint — no downtime, no data loss, no "we'll fix it in the next release" — forced real discipline around ordering and correctness rather than just splitting services along convenient seams. It was also the leanest team of the five: full ownership from dev to production, backed by integration tests running on Testcontainers and a build breaker that wouldn't let coverage drop below 80%.

  • Joined in March 2020 with no prior Scala or Akka experience — taught myself the stack, then wrote the ramp-up plan the rest of the team used to learn it. Led the migration from a monolith to event-driven microservices while keeping live customers on the platform throughout, live in production by January 2021.
  • One of the leanest teams of the five roles: full ownership from dev to production, including owning incidents end-to-end — triage, resolution, post-incident fixes; backed by integration tests running on Testcontainers, with a build breaker enforcing 80% coverage as a quality gate.
  • Implemented an Akka cluster singleton in the Processor Gateway to dedupe transactions fetched from the processor APIs before publishing to Pulsar and indexing to Elasticsearch — exactly-once processing under pod restarts and churn. Carried the same pattern forward into Fiserv.
  • Built a plugin-based issuer layer using CQRS and DDD to model corporate account hierarchies — a new processor became a plugin, not a project.
ScalaAkkaEvent-DrivenCQRS / DDDTestcontainers
2021 — 2025

Fiserv

Director, Software Development · Pune

Scale changed shape here — not just more transactions, but more kinds of team. Running a ~15-person organization across backend, SRE, web, mobile, and QA meant the job was as much about org design as system design: who owns what, and how a corporate card platform serving hundreds of banks across the EU and US stays fast and correct as the tenant count climbs. Part of that was culture, not just code — performance testing had been reactive, run only when a client asked for it and then scrambled to hit the expected TPS. Replacing that with a weekly cadence — deploy the latest build of every service to a production-scaled QA cluster and run the load tests automatically, report shared with clients every time — took a few rough Fridays to bed in, but it stuck.

  • Led a ~15-person organization spanning backend, SRE, web, mobile, and QA for a corporate card platform serving hundreds of banks across the EU and US.
  • Drove a shift to lean performance-testing culture: replaced ad hoc, client-triggered performance runs with a weekly cadence — pull the latest build of every service, deploy to a QA cluster scaled to match production (replicas and resources included), and run the load tests. The first few weeks needed hands-on firefighting most Fridays; a few weeks in, it ran on its own, with the latest report shared with clients every time.
  • Owned a platform handling millions of transactions a day for hundreds of bank customers across the EU and US.
  • Tuned Elasticsearch indexing and refresh semantics to hold read performance under sustained load.
  • Automated multi-tenant file ingest, provisioning accounts under the correct tenant automatically — onboarding became configuration, not a project.
ElasticsearchMulti-tenantOrg DesignSREPerformance Testing
2025 — Present

Verifone

Director, Cloud Engineering · Pune

The current chapter, and the sharpest version yet of the same obsession: a payment should move exactly once, and settlement shouldn't hold a business hostage overnight. Leading a 10-person team across 30+ microservices, the biggest wins have come from making correctness structural — an idempotency framework instead of careful code review, container-backed tests instead of hopeful unit tests, parallel processing instead of a settlement job everyone just budgets eight hours for.

  • Lead a 10-person engineering team owning 30+ microservices across the payments platform.
  • Reduced settlement processing time by 90% — 8 hours to 45 minutes — by re-architecting the settlement engine for parallel processing.
  • Ended a recurring source of delayed merchant payouts: the settlement engine's acquirer file — a strict 80-byte fixed-record format — used to get rejected outright by the acquirer when it contained duplicate transactions. Built a lightweight duplicate check before each record is written, with the uniqueness key configurable per settlement service — each service defines its own combination of fields, no dependency on the client passing an idempotency key. Started in-memory, now runs underneath multi-million-transaction settlement services with zero acquirer rejections since.
  • Designed and deployed an enterprise-grade idempotency key framework guaranteeing exactly-once transaction processing across EMEA and US.
  • Introduced Built-In Quality practices, shifting from unit-test-heavy coverage to container-backed integration tests using Testcontainers across 30+ services.
  • Regularly present architecture decisions and technical strategy to leadership, driving internal RFCs for major platform changes.
MicroservicesIdempotencyTestcontainersKubernetes / AWS
The throughline

Same problem, five scales.

Underwriting exceptions in 2007. Fraud rules in 2015. Exactly-once writes in 2020. Multi-tenant onboarding in 2023. Idempotent settlement in 2026. It's the same question asked at every layer of the stack: how do you make a payment system correct by default, not by discipline? That question is why the two case studies on the next page exist. See how it plays out in the architecture →