28 Cards. 7 Networks. Zero Surprises

How a Tier-1 Indian payment aggregator used purpose-built EMV merchant test cards to validate their acquirer switch across seven payment networks — on time and without a single reconfiguration.

One of India’s largest payment aggregators, processing tens of millions of transactions every day, needed to validate its acquirer switch across Visa, Mastercard, Amex, RuPay, JCB, Discover, and Sodexo. Off-the-shelf test cards couldn’t accommodate their proprietary PAN ranges or the precise EMV configurations required by their switch. Payhuddle designed and delivered 28 fully custom merchant test cards in two weeks, enabling UAT to proceed without a single issue.

Background

The customer is one of India’s leading payment processors, handling tens of millions of transactions through their acquirer switch every day. At that scale, the switch must handle every network, every card type, and every transaction scenario without exception.

They were undertaking a full real-time EMV terminal User Acceptance Testing (UAT) exercise across seven networks: Visa, Mastercard, Amex, RuPay, JCB, Discover, and Sodexo. The goal was to ensure their acquirer switch performed correctly across all of them before go-live. To do that, they needed the right test cards, and not generic ones.

The challenge: Why weren’t generic test cards an option

Standard UAT test cards are built for standard environments. They work for labs, for reference implementations, and for certification against published network specifications. They are not built for the specific configurations of a live acquirer switch.

For this customer, the gap was fundamental. Their switch operated on proprietary PAN (Primary Account Number) ranges. The BIN (Bank Identification Number) routing logic, CVM (Cardholder Verification Method) lists, and ODA (Online Data Authentication) methods were all configured for their respective environments. A card built for a generic processor would not exercise what needed to be exercised.

Using misaligned cards wouldn’t just create noise in testing. It would create false confidence with the switch appearing to pass scenarios it had never truly encountered.

The scope also added complexity. Covering seven networks in a single UAT exercise, including a domestic scheme (RuPay) and a closed-loop network (Sodexo) alongside the international schemes, required network-specific expertise that went well beyond standard personalization tooling. And critically, both contact and contactless interfaces needed to be covered across the full card set.

They needed a partner who could precisely and quickly translate their switch configuration into a ready-to-test card set.

Why Payhuddle

Custom EMV test card personalization at this level of specificity is rare. Most vendors offer standard card sets or personalization tooling focused on regional card sets, standard network setups, and lab certification needs. Very few combine EMV subject-matter expertise with the ability to deliver fully custom, switch-specific merchant test cards configured for the customer’s exact environment.

Payhuddle is one of the very few vendors globally that do this. Two capabilities made the difference:

1. The Card Image Editor gives Payhuddle’s team precise control over every parameter at the card image level, such as PAN ranges, CVM lists, ODA methods, and interface types, without being constrained by standard templates.

2. The domain expertise to configure those parameters correctly across seven networks simultaneously, including nuanced differences between international schemes, a domestic scheme, and a closed-loop network, is not something that can be improvised or looked up. It comes from having done it before.

Payhuddle’s approach

Before any card configuration began, Payhuddle’s team worked closely with the customer to map the requirements for their acquirer switch across all seven networks. This was not a form-filling exercise. It required understanding how the switch was built, which BIN ranges it routed on, how CVMs were prioritized per network, which ODA methods were expected, and which interface types needed to be covered.

The Card Image Editor was then used to personalize the L3 card images to those exact specifications. Each card was built to reflect precisely what the acquirer switch would encounter in a live environment. The full card set was configured to:

• PAN numbers aligned to their proprietary PAN ranges
• CVM lists configured per network requirements
• ODA method defined for each card profile
• Single and dual-interface support addressed across the complete card set

In total, 28 cards were delivered, including dual-interface cards that support both contact and contactless testing across all seven networks.

The outcome

The complete card set was delivered within two weeks of engagement. All 28 cards were fully configured to the customer’s acquirer switch testing requirements, covering Visa, Mastercard, Amex, RuPay, JCB, Discover, and Sodexo.

UAT proceeded as planned. There were no issues requiring card reconfiguration, no delays caused by misaligned test data, and no follow-up cycles. The switch validation exercise ran against cards that reflected the live environment from the first transaction.

For a processor operating at this scale, that outcome mattered. A test card problem at this stage of a launch would not have been a minor inconvenience; it would have pushed the entire go-live timeline.

Why it worked

The cards were treated as a launch dependency rather than a procurement task.

Test card projects of this complexity succeed when the UAT card set is built into the launch plan from the start, scoped properly, delivered on time, and aligned with the live environment before testing begins. Payhuddle approached the engagement that way from day one.

Configuration expertise replaced template dependency.

Because Payhuddle’s Card Image Editor operates at the parameter level rather than from fixed templates, the team could incorporate the customer’s proprietary PAN ranges and network-specific configurations precisely. There was no compromise between what the switch required and what the cards could support.

Seven networks were treated as seven distinct requirements.

Each network in the card set, including RuPay and Sodexo, which have meaningfully different characteristics from the international schemes, was configured to its own specification. The breadth of network coverage didn’t reduce the precision of any individual card profile.