About
I build adaptable payment technology that works across devices, transaction flows, and the systems behind them.
01 / Foundation
I began my career in .NET backend development, learning how to build the services and data flows behind an application. I then worked across the full stack with AngularJS and moved into hybrid mobile applications. That progression taught me to see a product from its user interface through its APIs, operations, and infrastructure.
02 / Specialisation
My work later moved to Android payment terminals across device families from Landi, Ingenico, PAX, Verifone, KOZEN, Sunmi, Newland, and others. Each device has its own SDK and hardware behavior, while merchants and acquirers need a consistent payment experience. I focus on a common application layer that separates shared transaction behavior from vendor-specific integrations.
03 / Leadership
At Ingenico, I progressed from Technical Lead to Engineering Manager, working on Android payment applications, device-to-cloud connectivity, and engineering delivery through July 2025. Since September 2025, I have been Head of Technology at SeaPos Payment Services Pvt. Ltd., working across payment device software and the wider platforms that support it.
04 / Exploration
I am now exploring where AI can improve payment engineering and commerce, especially when an automated system must explain what it knows, stay within its authority, and handle uncertain transaction outcomes. On this site, I share practical writing, interactive tools, and selected work from that journey.
Highlight / Programmable escrow
I designed and built a smart-contract escrow and conditional-payments platform on a permissioned Hyperledger Besu (QBFT) network, with banks as custodians and contracts as the decision layer.
Upgradeable Solidity contracts on UUPS proxies, ERC-7201 storage, and OpenZeppelin AccessControl. Invariant and fuzz testing proves that payouts can never exceed secured funds and that valid settlements never get stuck.
An event indexer, keeper, and Custody Gateway that execute bank instructions (fixed-deposit liens, digital rupee) idempotently, and only after re-verifying them on chain.
Off-chain encrypted evidence that can be erased by deleting its key, KMS-managed custodial keys, reconciliation, observability, and a 4-validator fault-tolerant network.
Highlight / Payment key management
I designed and built a production-grade HSM integration for a multi-tenant card payments platform. It covers remote key injection to payment terminals and PIN and card-data translation on every transaction, with full support for DUKPT TDES (ANSI X9.24-1) and DUKPT AES (X9.24-3). It works with Futurex and Thales HSMs through a vendor-neutral adapter. Dual control governs every key change, and no clear key or PIN ever leaves the HSM boundary.
Payment terminals need unique encryption keys. Every card PIN must be re-encrypted for the acquirer without ever being exposed. The usual way is manual key loading in secure rooms, which is slow, costly and hard to audit.
Terminals receive DUKPT TDES or AES-128 keys remotely. Each terminal registers its RSA key with proof of possession, the HSM derives and wraps the device key (RSA-OAEP), the platform delivers it as a signed package, and the terminal confirms the injection with key check values.
The HSM translates PIN blocks from the terminal's DUKPT zone to the acquirer's key zone: ISO 9564 format 0 for TDES and format 4 for AES. It also handles Track 2 decryption and MAC. Each transaction checks that the key serial number belongs to that device, so cloned or retired terminals are refused.
Adapters for Futurex (over mutual TLS) and Thales sit behind one interface. Adding another vendor is an adapter, not a rewrite.
Maker-checker on HSM profiles and key sets. Base derivation and zone keys are generated in the HSM by a dual-control ceremony. Keys are never returned, logged or emitted, and every key event lands in an append-only audit trail.
A shared crypto library (DUKPT, ISO 9564, TR-31 key blocks, KCV) tested against published test vectors and validated live on a Futurex cloud HSM. An HSM emulator with fault injection runs in CI, and the design fails closed with bounded timeouts and bulkheads.
No more key-loading visits. Clear PINs and keys stay inside the HSM. There is a full audit trail for PCI PIN, and the bank can choose its HSM vendor.
Career chronology
Head of Technology
SeaPos Payment Services Pvt. Ltd.
Engineering Manager
Ingenico India International
Technical Lead
Ingenico India International
Lead Engineering
Commdel Consulting Services
Sr. Associate Engineer Lead
Commdel Consulting Services
Team Lead
Oath Infosystems Pvt. Ltd.
Senior Developer
Oath Infosystems Pvt. Ltd.
Software Developer
Winsoft Software Solution
Global delivery
Across both on-site and remote engagements, spanning terminal deployments, transaction platform integrations, and merchant-side rollouts.
Technical expertise
Smart-contract escrow and conditional payments on permissioned networks, with banks as custodians, contracts as the decision layer, and invariant-tested Solidity behind every payout.
Experience with Android payment terminals and SDKs across multiple device families, using explicit capability contracts rather than assuming every terminal behaves identically.
Distributed switching, orchestration, reversal and reconciliation, high-throughput authorization pipelines, connector abstraction, per-contract profiles.
Futurex and Thales, DUKPT TDES and AES, remote key injection, PIN translation.
Mandate design, consent freshness, step-up authentication, audit-trail-first agent flows, rails-aware policy — commerce for parties that aren't humans.
Principles
UNKNOWN is not the absence of information. It's information — that a layer sent a request and did not observe a response. Design your schema so every layer can say so.
An approval and a subsequent reversal are two facts. Overwriting the first with the second is lying about the past. Every dispute you'll ever answer will want the trail.
The logical-operation id is sticky across retries. The attempt id changes. If your terminal firmware generates a fresh transaction id every time the operator presses ‘retry’, you have duplicate transactions.
The terminal reports what it observed. The ledger is the source of truth. When they disagree, the ledger wins. Everything downstream should be built on that hierarchy.
Contact