Building NetValve: A Payment Gateway for High-Risk CNP Merchants

Most payment gateway projects start with an existing product to improve. NetValve started with nothing — a domain name, a tagline ("Payments Simplified"), and a mandate to build a Card Not Present gateway for high-risk merchants in the US and EU market from zero.

I came in as Product Owner. My job was to define what the product was, how it would work, and get it live. Not in six months. On a committed timeline that the business had already communicated externally.

The Market We Were Entering

High-risk CNP acquiring is a specific, deliberately underserved segment of the payments market. Most mainstream gateways won't touch it — or they charge so much that the economics don't work for the merchant. The verticals that fall into this category include:

What makes these merchants "high-risk" in the acquiring world isn't necessarily that they're problematic businesses. It's that they carry elevated chargeback rates, operate in regulatory grey zones, or serve customer segments with higher dispute rates. Standard acquiring banks price them out or decline them entirely. A specialist gateway — with the right bank relationships, fraud controls, and compliance infrastructure — can serve them profitably.

That was the gap NetValve was being built to fill.

What the MVP Had to Deliver

The first discipline of greenfield product ownership is scope control. A payment gateway can expand indefinitely — 3D Secure, tokenization, Apple Pay, Google Pay, recurring billing, dispute management, multi-currency settlement. All of it eventually matters. None of it matters before the core transaction flow works.

The MVP scope was defined tightly:

The discipline wasn't in deciding what to build — it was in holding the line on what not to build yet, while the engineering team faced pressure to add scope. Every deferred feature was documented and sequenced for post-MVP delivery. Nothing was dropped — it was staged.

The Architecture We Built

NetValve was designed as a microservices architecture on AWS from the start — not because microservices are always the right answer, but because the business anticipated rapid scale and needed independent deployability across the transaction, bank, and admin service layers.

One of the architectural decisions I pushed hard on early was the response code framework. Most gateways return opaque bank response codes that merchants can't act on. We designed an intelligent layered system: BNK_ prefix for acquiring bank errors, GTW_ for gateway errors, FRD_ for fraud responses, 3DS_ for authentication — each with defined ranges for approved (1000–1999), soft decline (2000–2999), hard decline (3000–3999), and risk responses (4000–4999). This made the API meaningfully more useful to merchant developers at integration time.

What the Product Looked Like at MVP

NetValve — Gateway & Dashboard at MVP

Gateway login page and public-facing Coming Soon website — both live at MVP. Clean, professional, credible to merchants evaluating integration.

Admin View — Merchant Client Management

Admin view showing merchant client list with active/inactive status, and the merchant account configuration screen — bank, system, currency, API credentials, and descriptor management.

Merchant View — Order Tracking & Transaction Detail

Merchant-facing order list with captured amounts and status, and the full order detail view — transaction ID, authorization, CVV check, AVS check, card details, issuer, and raw gateway response. Built for merchants who need operational visibility, not just a processed/declined flag.

The Compliance Layer

High-risk acquiring without PCI DSS compliance isn't a product — it's a liability. From day one, the architecture was designed to achieve PCI DSS Level 1 positioning, which applies to service providers processing over 6 million transactions per year. Getting there from an MVP required deliberate decisions at every layer.

The most critical early finding from the system architecture review: CVV data was being stored in the database. PCI DSS Requirement 3.2.2 is explicit — CVV must never be stored post-authorisation. This was flagged, escalated, and resolved before any live transaction processing. Not after go-live. Before.

Other compliance work running in parallel: AWS KMS encryption with a rotation policy to define, TLS 1.0 and 1.1 disabled on public endpoints (the Qualys SSL Labs scan had capped the rating at B — fixing the protocol support moved it to A), OAuth2 authentication for API access, WAF enablement, and the SDLC security documentation required under PCI Requirement 6.

The Hard Part

Building the gateway itself was complex but tractable. The harder problem was the intersection of three simultaneous workstreams that each had dependencies on the others: engineering delivery, bank certification, and compliance readiness.

Bank certification — specifically getting the TSYS acquiring rails certified and live — was the critical path. Without a certified bank connection, the gateway processes nothing. The certification process involves test transaction suites, response code validation, and bank-side approval that is entirely outside your control timeline-wise. We built around it by using the Gateway Testing Simulator to run the full transaction flow internally while certification was in progress — so when the bank rail went live, the product was ready.

The second pressure point was scope creep from stakeholders who saw the MVP and immediately wanted everything that wasn't in it. The Preferred Partner Program. Apple Pay. Full tokenization. Each of these was real and legitimate — and each of them would have pushed the go-live date if we'd let them in. Holding that line, with a sequenced post-MVP roadmap as the evidence that nothing was being abandoned, was a significant part of the product ownership work.

What Came After MVP

The October 2022 go-live was the beginning, not the end. The engagement continued for two years, with expanding scope: additional bank rails (EMP, EPX), enhanced fraud controls and risk rule engine, full RBAC and user activity logging, dashboard analytics, tokenization planning, and infrastructure hardening across the AWS stack. The product grew from a basic MVP into a functioning specialist gateway with real merchant volume.

What This Means for You

If you're building a payment gateway — or evaluating whether to build vs buy — the questions that determine whether you succeed aren't product questions. They're infrastructure questions:

A payment gateway is one of the most technically and operationally demanding products to build. The companies that do it well don't do it by building faster — they do it by sequencing correctly, holding scope, and treating compliance as a first-class product requirement rather than a legal afterthought.