Moving HealthPay onto BajajPay Rails Without Breaking the Business

Payment migrations look simple from the outside.

Replace one QR with another.
Move merchants to a new payment rail.
Sync transaction and settlement feeds.
Roll out to the field.

In reality, it is far more fragile.

A QR code sitting at a doctor clinic, lab, or hospital is not just a payment artifact. It is tied to merchant onboarding, field sales, QR logistics, customer payment journeys, transaction feeds, settlement visibility, provider communication, refunds, support workflows, and reconciliation.

The HealthPay–BajajPay transition was one of those projects where the product challenge was not just technical integration. The challenge was to move a live healthcare payment ecosystem onto BajajPay infrastructure while preserving business continuity, provider trust, customer experience, and operational control.

I worked on this project in parallel to Partner Center. My contribution was concentrated around requirement definition, solutioning, merchant onboarding flows, QR migration planning, transaction and settlement feed requirements, logistics/service SOPs, support workflows, and UAT support. In the final stages, I was moved to another project, so the final rollout ownership transitioned to other stakeholders.

That distinction matters. This was a strong product and integration strategy project, but I would not position it as a full final-rollout ownership story.

The situation

HealthPay had built a healthcare payment ecosystem across doctors, labs, and hospitals. Providers used HealthPay QR codes and payment flows to collect money from customers. These payments were connected to BFHL systems, provider-facing platforms, settlement workflows, and internal reconciliation processes.

The next strategic step was to transition HealthPay QR infrastructure to BajajPay.

On paper, that sounds like a payment-rail migration.

In practice, it touched almost every part of the HealthPay operating model:

• provider onboarding,
• doctor/lab/hospital merchant mapping,
• QR generation,
• QR template design,
• QR logistics,
• existing QR migration,
• new merchant onboarding,
• transaction feeds,
• settlement feeds,
• refund handling,
• health-plan consumption,
• provider communication,
• customer communication,
• support workflows,
• Partner Center / Provider Portal visibility,
• DRx and HRx journeys,
• S1 onboarding,
• field-force readiness,
• CUG and GTM planning.

The project was not only about getting payments to work. It was about ensuring that every actor in the ecosystem still knew what to do after the migration.

What was actually broken or risky

The existing HealthPay payment model worked, but it had to evolve into a group-level BajajPay-led infrastructure.

That created several risks.

Provider migration risk

Doctors, labs, and hospitals already had HealthPay QR codes in the market. Replacing or mapping those QR codes was not just a backend change.

If the wrong QR was placed, mapped, activated, or communicated, transactions could fail or settlements could go to the wrong mapping layer.

The product had to account for:

• existing HealthPay UPI IDs,
• new BajajPay UPI IDs,
• old-to-new QR mapping,
• QR activation,
• QR status,
• QR logistics,
• provider-level reconciliation,
• QR-level transaction visibility.

Business continuity risk

Healthcare payments cannot be disrupted casually.

A customer standing at a clinic or lab expects payment to work.
A doctor expects settlement to happen.
A provider expects transaction visibility.
Support teams expect traceability when something fails.

A failed migration could create:

• payment failures,
• duplicate payments,
• refund queries,
• provider escalations,
• settlement confusion,
• support TAT increase,
• loss of provider trust.

Multi-system integration risk

This project sat between BFHL and BFL systems.

That meant multiple systems had to stay aligned:

• HRx app/web,
• 3-in-1 app,
• DRx / doctor systems,
• Provider Portal / Partner Center,
• BajajPay systems,
• HealthPay / PayRx systems,
• SFDC,
• payment dashboards,
• SFTP feeds,
• settlement APIs,
• transaction webhooks.

The challenge was not just “build an API.”

The challenge was:

If a transaction starts in one system, who owns the journey, who communicates to the customer, who communicates to the merchant, who settles the money, who handles support, and where does the data become visible?

Support model risk

The customer or merchant did not care whether the issue belonged to BFHL or BFL.

If a payment failed, refund was delayed, QR did not work, settlement was missing, or chargeback came in, the support model had to be clear.

The product had to define:

• customer support ownership,
• merchant support ownership,
• primary and secondary support teams,
• SFDC case flow,
• payment-origin-based routing,
• analytics feed between systems,
• resolution ownership.

Without this, every issue would become a cross-company escalation.

The product insight

The simple framing would have been:

“Migrate HealthPay QR to BajajPay QR.”

That would have missed the real problem.

The deeper product insight was:

A payment migration is not only a payment migration. It is an ecosystem migration.

Every QR code represented a relationship between customer, provider, platform, payment rail, settlement engine, support process, and field team.

So the product needed to solve for more than QR generation.

It needed to solve for:

• merchant onboarding,
• QR lifecycle,
• transaction traceability,
• settlement traceability,
• refund traceability,
• provider communication,
• customer communication,
• support ownership,
• field logistics,
• migration sequencing,
• compliance continuity,
• failure recovery.

The real question was:

How do we move HealthPay providers to BajajPay infrastructure without breaking payments, settlements, support, or provider trust?

What I shaped

My work focused on the early-to-mid product definition and solutioning layers of the merger.

Merchant onboarding design

The onboarding flow had to support multiple provider types:

• doctors,
• labs,
• hospitals,
• existing HealthPay providers,
• new BFHL merchants,
• bulk-upload merchant migration.

Doctors had a more detailed onboarding flow because their listing and payment activation depended on document collection, profile validation, bank details, KYC, clinic details, QR placement, consent, QC, and activation.

Labs and hospitals had their own onboarding complexity:

• legal name,
• display name,
• provider type,
• services,
• sample collection model,
• centres,
• SPOC details,
• pincode coverage,
• banking details,
• packages/tests,
• online booking mechanism,
• settlement mapping.

The product direction was to keep BFHL as the front-end owner of provider data collection and operational coordination, while BajajPay powered QR generation and payment rails.

This avoided forcing providers into a completely new onboarding behavior overnight.

Existing HealthPay provider migration

The migration problem was delicate because existing providers already had HealthPay QR codes.

The core transition logic was:

Share existing provider and HealthPay UPI data with BajajPay → generate new BajajPay QR/UPI details → send new mapping back to BFHL → store BajajPay UPI ID against old HealthPay UPI ID → ensure HRx / 3-in-1 / provider-facing systems can identify the correct provider from the new QR.

This mapping layer was critical.

Without it, BFHL could generate payments but lose traceability.
And without traceability, settlements, provider communication, and support would break.

QR lifecycle and logistics

The QR workflow was not just about creating a QR image.

The product scope included:

• QR generation,
• QR activation,
• QR template design,
• co-branded QR collateral,
• QR logistics,
• QR scanning,
• QR status,
• QR ID mapping,
• multi-QR support,
• QR update/edit APIs,
• QR image visibility on provider-facing platforms.

The logistics layer was especially important.

Existing HealthPay QR standees were already in the market. New BajajPay QR codes had to be printed, quality-checked, shipped, delivered, and placed across clinics, labs, and hospitals.

The project therefore needed SOPs around:

• who orders QRs,
• who prints them,
• who validates them,
• who ships them,
• who delivers them to partners,
• how QR placement status is tracked,
• what happens to old QR standees,
• how migration is communicated to the field.

This is where product thinking had to extend into field operations.

Transaction feed design

The transaction design had to support different customer origins.

A customer could pay through:

• HRx app or web,
• 3-in-1 app,
• other UPI apps,
• health-plan consumption journeys,
• UPI / PPI / EMI / wallet / card modes.

Each origin created a different ownership model.

For example:

• If the transaction originated from BFHL assets, BFHL owned the journey and communication.
• If the transaction originated from 3-in-1, BFL owned the customer journey and communication.
• Merchant communication largely remained with BFHL.
• Other UPI app journeys required transaction feed visibility back to BFHL.

The product challenge was to define how transaction data would move back into BFHL systems for provider visibility, support, and analytics.

The expected design included:

• real-time transaction feed,
• transaction status API,
• transaction webhook,
• retry logic,
• failure alerts,
• transaction visibility in merchant-facing systems,
• payment dashboard support.

This ensured that BFHL did not lose operational visibility after moving payment rails to BajajPay.

Settlement feed design

Settlement was a critical part of provider trust.

A provider does not only care whether the customer paid. The provider cares whether the money was settled and whether they can see it.

The settlement design needed:

• settlement API,
• SFTP settlement feed,
• QR-level settlement mapping,
• provider-level settlement visibility,
• settlement communication,
• consistency between HealthPay and BajajPay settlement messaging,
• alignment of settlement timelines,
• visibility in Provider Portal / Partner Center.

The key product requirement was:

Even if BajajPay becomes the payment rail, BFHL partners should continue getting transaction and settlement visibility through BFHL-owned merchant-facing channels.

This mattered because Partner Center was becoming the partner operating layer. If settlements moved to BajajPay but visibility disappeared from BFHL systems, partner trust would suffer.

Refund and chargeback handling

Refunds and chargebacks are where payment systems reveal whether they were truly designed end-to-end.

The project needed to define:

• refund API,
• refund webhook,
• partial refund,
• full refund,
• refund statuses,
• refund callback to BFHL,
• support visibility,
• chargeback alerts,
• proof-of-delivery upload,
• invoice support for chargeback handling.

This prevented the migration from being limited to successful transactions only.

A payment product cannot be designed only for success states. It must handle failure, reversal, refund, and dispute states as first-class workflows.

Customer and merchant support model

Support ownership had to be split based on journey origin.

For customer support:

• HRx-originated cases were to be handled by BFHL.
• 3-in-1-originated cases were to be handled by BFL.
• BFHL needed feeds for analytics and visibility where required.

For merchant support:

• DRx PMS / Provider Portal cases would be created in BFHL SFDC.
• BFHL would be first-level support for merchants.
• BFL would become second-level support for cases related to BajajPay payment origin or payment-rail issues.

This created a joint operating model.

The important product decision was:

Merchants should not be forced to understand internal ownership between BFHL and BFL. They should raise issues through the familiar BFHL merchant support layer, while internal routing handles ownership.

Health-plan consumption on 3-in-1

One of the more complex parts of the merger was health-plan consumption.

If a customer had BFHL health-plan benefits, those benefits needed to be visible and usable in the 3-in-1 app. That required coordination across benefit visibility, checkout experience, transaction breakup, communication templates, and post-payment visibility.

The product considerations included:

• show applicable health plans during checkout,
• support multiple plan benefits,
• show benefit breakup in transaction history,
• ensure HealthPay/HRx gets visibility of transactions using benefits,
• align customer communication across transaction types,
• ensure merchant communication remains with BFHL.

This was not just payments. It was the merger of payment and benefit consumption journeys.

How the workflow changed

The earlier HealthPay model was more BFHL-owned and HealthPay QR-led.

The future state moved toward:

BajajPay-powered QR infrastructure + BFHL-owned provider relationship + shared transaction/settlement feeds + coordinated support model + Partner Center visibility.

Before transition, the operating model looked closer to:

HealthPay QR → BFHL payment/recon ecosystem → BFHL provider communication → BFHL support.

The target model became:

BajajPay QR → BFL transaction/settlement infrastructure → feed to BFHL → BFHL merchant visibility/support → coordinated customer/merchant communication based on transaction origin.

That is a much more complex model.

The product challenge was to keep the provider experience simple even though the backend ownership had become more distributed.

What made this hard

This project was hard because it had too many moving parts.

Cross-company dependency

BFHL and BFL systems, teams, processes, and support models had to align.

Even small delays at one end could affect the entire logistics or transaction journey.

Many failure points

The project had risk across onboarding, QR mapping, QR activation, payment capture, transaction feed, settlement feed, refund webhook, support routing, and provider communication.

Field readiness

QR migration is not purely digital. Physical QR standees, FOS onboarding, QC, logistics, and field communication all mattered.

Legacy continuity

Existing HealthPay records and QR histories could not simply disappear after migration.

Old HealthPay QR records had to remain traceable while new BajajPay QR mappings became active.

Communication complexity

Customer communication depended on payment origin. Merchant communication remained with BFHL. Support ownership depended on case type and transaction source.

This required careful service design.

What was achieved before my transition

The integration reached an advanced stage before my movement to another project.

The project documentation indicates:

• integration between BajajPay and HealthPay was completed,
• UAT testing was completed successfully,
• code base was moved to production from both ends,
• logistics SOP was approved,
• service SOP was in progress,
• GTM planning was prepared with the doctor listing team,
• CUG was dependent on FOS onboarding readiness from the BFL side.

My contribution sat across the product definition and transition-planning layers:

• requirement definition,
• merchant onboarding flows,
• HealthPay-to-BajajPay QR migration logic,
• QR generation and logistics process,
• transaction and settlement feed requirements,
• refund and webhook requirements,
• provider-facing visibility requirements,
• customer and merchant support flows,
• health-plan consumption design,
• SOP inputs,
• business UAT support,
• GTM/migration planning inputs.

I was moved to another project during the final stages, so I would position final rollout as transitioned to other stakeholders.

What this delivered

The project created the foundation for moving HealthPay providers onto BajajPay QR infrastructure while preserving operational continuity.

The intended business direction included:

• migration of existing HealthPay doctor business to BajajPay QR codes,
• fresh doctor onboarding onto BajajPay QR infrastructure,
• later migration of labs and hospitals,
• alignment of transaction and settlement feeds,
• support for health-plan consumption through 3-in-1,
• stronger compliance through BajajPay adoption,
• unified provider visibility through BFHL systems.

The project also defined the risk controls needed for a complex payment transition:

• old-to-new QR mapping,
• transaction webhooks,
• settlement feeds,
• refund APIs,
• SFTP backup,
• support ownership,
• SOPs,
• FOS onboarding,
• QR logistics,
• UAT and CUG planning.

What this says about my product approach

This project reflects a different side of product management: not feature-building, but ecosystem migration.

The challenge was not to design a beautiful screen.
The challenge was to make a complex payment transition operationally safe.

It required thinking across product, technology, payments, field sales, support, provider operations, compliance, logistics, and communication.

The most important product principle here was:

When infrastructure changes, the user experience should not collapse.

Doctors, labs, hospitals, customers, and support teams should not feel the complexity of internal systems changing. The product manager’s job is to absorb that complexity into flows, mappings, APIs, SOPs, and support models.

That was the essence of this project.