Payments for Healthcare Software Platforms: Embedded Payments, ISV Models & Merchant Onboarding

Healthcare Software Payments: The Quick Answer

Healthcare software companies increasingly have an opportunity to make payments part of their product rather than simply connecting customers to an external card processor.

A dental practice-management platform, veterinary PMS, optical system, private-clinic platform or healthcare booking application may already have hundreds or thousands of business customers accepting payments.

Those payments could include:

• card payments at reception;
• online appointment deposits;
• payment links;
• outstanding patient balances;
• high-value treatment payments;
• recurring contact-lens or healthcare plans;
• telephone payments;
• online ecommerce transactions;
• multi-site payments; and
• refunds and recurring billing.

For the software provider, the strategic question is no longer simply:

“Which payment gateway should we integrate?”

It is:

“What payment model should sit inside our software, how should customers be onboarded, who should own the merchant relationship and can payments become a commercial part of our proposition?”

This guide explains the main issues healthcare software providers should consider before selecting an integrated or embedded payments partner.

Find Your New Processor

Who Is This Guide For?

This guide is primarily for established healthcare software companies and technology platforms with business customers that accept payments.

This can include:

• dental practice-management software;
• veterinary practice-management platforms;
• optical practice software;
• private healthcare PMS platforms;
• clinic-management software;
• appointment and booking platforms;
• patient portals;
• healthcare CRM systems;
• medical billing software;
• subscription and membership platforms;
• vertical SaaS businesses serving healthcare;
• software used by multi-site healthcare groups; and
• healthcare technology companies looking to replace an existing payment integration.

This guide is written for healthcare software providers, ISVs and vertical SaaS businesses rather than individual medical practices. Healthcare businesses looking for merchant accounts, card terminals, recurring payments and practice-level payment solutions should start with our Healthcare Payment Solutions UK guide.

Those businesses have different payment requirements, which we cover within our dedicated healthcare payment guides.

Why Payments Matter to Healthcare Software Companies

Payments naturally sit inside many healthcare workflows.

Consider a private dental practice.

The software might already manage:

• appointment booking;
• patient records;
• treatment plans;
• deposits;
• invoices;
• outstanding balances;
• patient communications; and
• reporting.

Payment is simply another stage in that workflow.

The same principle applies elsewhere.

A veterinary system knows when an invoice is due.

An optical PMS knows when a customer has ordered glasses, paid a deposit or joined a recurring contact-lens plan.

A clinic-management platform knows when an appointment has been booked and when a patient balance remains outstanding.

If payment takes place completely outside the software, staff may have to manually reconcile the financial transaction with the operational record.

Integrated payments can reduce that separation.

Integrated Payments vs Embedded Payments in Healthcare Software

The terms are often used interchangeably, but the commercial models can be quite different.

Integrated payments

An integrated-payment arrangement generally connects payment functionality with the healthcare software.

For example:

1. the practice selects an invoice;
2. the amount is sent to a payment terminal;
3. the patient pays;
4. the transaction result returns to the software; and
5. the invoice is automatically updated.

The payment provider may remain clearly visible and the healthcare practice may contract directly with it.

Embedded payments

With a deeper embedded-payment model, payments can become part of the software company's wider product proposition.

The platform may control more of:

• merchant onboarding;
• payment user experience;
• payment configuration;
• pricing presentation;
• reporting;
• support;
• branding;
• payment-product development; and
• commercial revenue generated from processing.

The exact responsibilities depend on the provider and contractual structure.

Healthcare Software Companies Do Not Need to Become Payment Facilitators

One of the most important decisions is how much of the payments operation the software business actually wants to own.

A healthcare ISV does not necessarily need to become a Payment Facilitator to make payments part of its proposition.

Possible models include:

Read our full guide to integrated payments for ISVs for a broader comparison of these models.

Start With Your Existing Healthcare Customer Base

Before choosing a payment company, understand the merchants already using the software.

This is particularly important in healthcare because payment requirements vary substantially between sectors.

Dental software

Dental customers may need:

• integrated reception terminals;
• online booking deposits;
• payment links;
• higher-value payments for implants or orthodontics;
• staged treatment payments;
• patient finance integrations;
• refunds; and
• multi-practice reporting.

Veterinary software

Veterinary practices may require:

• reception terminals;
• emergency and high-value transactions;
• procedure deposits;
• payment links;
• remote collections;
• pet health-plan payments;
• insurance-related reconciliation; and
• multi-site processing.

Optical software

Opticians can combine healthcare, retail and recurring payments.

The platform may need to support:

• eye-test payments;
• NHS voucher-related customer balances;
• frame and lens deposits;
• balance payments at collection;
• online optical retail;
• contact-lens subscriptions;
• Direct Debit;
• recurring card payments; and
• multiple stores.

Private clinic software

Private healthcare platforms may need:

• appointment deposits;
• self-pay consultations;
• high-value treatment payments;
• payment links;
• virtual terminals;
• recurring treatment plans;
• online booking;
• multi-practitioner billing; and
• multi-site reporting.

The correct payments partner therefore needs to fit the real merchant portfolio, not simply the technical specification produced by the development team.

Merchant Acceptance Is as Important as the API

Healthcare software companies sometimes begin payment-provider selection with a technical review.

They compare:

• API documentation;
• SDKs;
• webhooks;
• developer environments;
• terminal APIs;
• tokenisation;
• hosted fields;
• checkout components; and
• reporting APIs.

All of these matter.

But there is a more fundamental question:

Will the payment provider actually accept the healthcare businesses using your software?

A technically excellent integration has limited commercial value if a meaningful percentage of the software company's customers cannot pass underwriting.

Relevant factors can include:

• healthcare sector;
• treatment types;
• products sold;
• business location;
• transaction values;
• advance payments;
• recurring transactions;
• online sales;
• chargeback exposure;
• refund profile;
• regulatory status; and
• processing history.

This becomes particularly important where the healthcare software serves a broad portfolio containing conventional practices alongside more specialist businesses.

Merchant Onboarding Is Part of the Product

If payments are embedded into healthcare software, merchant onboarding becomes part of the software user's experience.

A healthcare practice may need to provide information including:

• legal business name;
• company number;
• registered address;
• trading address;
• directors;
• beneficial owners;
• bank account information;
• business activity;
• website;
• processing volumes;
• transaction values;
• payment channels; and
• supporting documentation.

The provider then completes its required KYC, KYB, verification and underwriting processes.

Current platform payment products such as Stripe Connect and Adyen for Platforms provide hosted, embedded or API-led onboarding options depending on the chosen setup.

Hosted vs Embedded vs API-Only Merchant Onboarding

Hosted onboarding

The healthcare software directs the merchant into a payment-provider-hosted onboarding journey.

This generally requires less development work and allows the payments provider to control more of the verification experience.

Embedded onboarding

Pre-built onboarding components can sometimes sit directly inside the healthcare software interface.

This can create a more integrated experience without requiring the software company to build every KYC field and workflow itself.

API-led onboarding

The software provider builds more of the onboarding UI and sends the required information to the payment platform through APIs.

This provides greater control but generally creates more development and maintenance responsibility.

The right option depends on how important white-labelling, speed of launch, control and engineering resources are to the platform.

Do Not Design Merchant Onboarding Only for the Happy Path

A merchant application will not always move directly from submitted to approved.

Healthcare software companies should understand what happens when the payment provider requires:

• additional ownership information;
• another identity document;
• bank-account evidence;
• website changes;
• financial information;
• clarification of treatments or products;
• licensing or registration information;
• more detail about transaction values; or
• additional underwriting review.

The software should ideally be able to tell the user:

• what is outstanding;
• what action they need to take;
• whether payments are currently restricted;
• when verification has completed; and
• when the account is ready to transact.

Merchant onboarding therefore needs to be designed as an ongoing state-based workflow rather than simply a one-off application form.

Who Owns the Healthcare Merchant Relationship?

This should be established contractually before the integration is built.

Questions include:

• Does the healthcare practice contract directly with the payment provider?
• Does the practice also enter into platform payment terms?
• Who presents the pricing?
• Who communicates underwriting requirements?
• Who handles payment support?
• Who handles terminal support?
• Who deals with chargebacks?
• Who tells the merchant about reserves or settlement changes?
• Who owns the commercial relationship?
• What happens if the software company changes payments partner?

The answers can be very different between a simple referral partnership and a deeply embedded or PayFac-style model.

White-Label Payments for Healthcare Software

Some software providers want payment functionality to appear under their own brand.

This can potentially include:

• branded onboarding;
• payments dashboards;
• transaction reporting;
• payment notifications;
• merchant pricing;
• support journeys;
• terminal configuration; and
• merchant-facing payment documentation.

However, white-labelling the user experience does not automatically mean that the healthcare software company becomes the regulated payment provider or underlying acquirer.

The legal and commercial structure depends on the model agreed with the payments partner.

Read our guide to white-label merchant processing for SaaS and platforms.

Can Healthcare Software Companies Make Money From Payments?

Potentially, yes.

Payments can create an additional commercial revenue stream for established software businesses with a meaningful customer portfolio.

Models can include:

• merchant referral fees;
• revenue share;
• transaction-based revenue;
• platform fees;
• payment-product subscription fees;
• wholesale or buy-rate structures; and
• other negotiated commercial arrangements.

The precise economics depend on the provider and operating model.

The important starting point is to calculate the payment volume already sitting within the software's customer base.

Calculate the Addressable Healthcare Payment Volume

For example, imagine a dental software platform with 500 practices.

If the average practice processes £80,000 per month in card payments, the theoretical payment volume represented by the portfolio is:

500 × £80,000 × 12 = £480 million per year.

Actual adoption will be lower than the total addressable volume, but the exercise demonstrates why payments can become commercially important to vertical software businesses.

The same analysis can be performed for:

• number of software customers;
• average payment turnover;
• expected payment adoption;
• average transaction value;
• online/card-present mix;
• recurring-payment volume;
• countries; and
• payment methods.

This information can materially affect commercial negotiations with potential payment partners.

Find Your New Processor

Online and In-Person Payments Need to Be Considered Together

Healthcare platforms often need more than online card acceptance.

A dental PMS may want an integrated terminal at reception and online deposits through the same payment ecosystem.

A veterinary platform may need payment terminals plus remote payment links.

An optical system may combine shop-floor terminals with ecommerce and recurring payments.

When comparing providers, check support for:

• card-present transactions;
• online payments;
• payment links;
• virtual terminals;
• MOTO;
• mobile payments;
• Apple Pay;
• Google Pay;
• recurring payments;
• stored credentials;
• refunds; and
• multi-location processing.

Terminal Integration Matters in Healthcare Software

For many healthcare verticals, physical card terminals remain essential.

Software providers should establish whether the payments partner offers APIs or integrations capable of linking the terminal transaction to the software workflow.

An integrated terminal journey can potentially work like this:

1. staff open the patient's invoice;
2. staff select “take payment”;
3. the correct amount is sent to the terminal;
4. the patient taps or inserts their card;
5. the payment result returns to the software;
6. the invoice is updated automatically; and
7. the transaction is available for reconciliation.

This reduces the need for double keying.

Healthcare Platforms Need Payment Links

Payment links are particularly valuable in healthcare because the person paying is not always standing at reception.

A platform might allow a practice to generate a secure payment request for:

• appointment deposits;
• outstanding treatment balances;
• insurance-related balances;
• veterinary invoices;
• optical order balances;
• medical reports;
• remote consultations; or
• another invoice held within the software.

The payment result can then return to the platform through the provider's API or webhook.

Recurring Payments Are Particularly Important in Some Healthcare Verticals

Healthcare software providers should establish whether their customers require ongoing payments.

Examples can include:

• contact-lens subscriptions;
• veterinary health plans;
• private healthcare memberships;
• dental maintenance plans;
• treatment packages;
• regular therapy services; and
• other subscription arrangements.

Recurring payments introduce additional requirements around:

• tokenisation;
• customer authority;
• card updates;
• failed-payment retries;
• cancellations;
• refunds;
• reporting;
• payment-status webhooks;
• Direct Debit where required; and
• migration if the platform later changes provider.

Direct Debit May Need to Sit Alongside Card Processing

Healthcare payment architecture does not need to be card-only.

An optical software platform, for example, may use card processing for retail transactions while using Direct Debit for recurring contact-lens subscriptions.

A veterinary platform may use card terminals for treatment payments while pet health plans run through another recurring-payment rail.

The software provider should therefore decide whether it wants:

• one provider covering multiple payment methods;
• separate specialist providers;
• a payments orchestration layer;
• one consolidated reporting environment; or
• multiple integrations managed within the platform.

Stored Payment Credentials and Tokenisation

Healthcare platforms offering recurring or future payments should normally avoid storing raw card details themselves where this is not required.

Payment providers can use tokenisation so the software works with a payment token or provider reference rather than the underlying card number.

However, software companies should ask an important question before choosing a provider:

Who controls the payment token?

This can become critical later if the platform wants to:

• switch payment provider;
• add another acquirer;
• move existing recurring payments;
• support multiple processors; or
• reduce reliance on one payments company.

Read our guide to moving stored cards, tokens and recurring payments.

Provider Lock-In Should Be Considered Before Building

A payment integration can become one of the deepest dependencies within vertical software.

The platform may eventually have:

• thousands of onboarded merchants;
• millions of payment tokens;
• recurring subscriptions;
• installed terminals;
• merchant pricing agreements;
• payment reporting;
• refund workflows;
• chargeback processes;
• support documentation; and
• significant payment revenue.

Changing provider at that point can be considerably harder than changing an ordinary API.

Before committing, establish:

• data portability;
• token portability;
• merchant portability;
• terminal ownership;
• contract termination rights;
• exclusivity;
• minimum processing requirements;
• revenue-share termination;
• migration support; and
• what happens to existing merchants if the partnership ends.

Should a Healthcare Platform Use One or Multiple Payment Providers?

There is no universal answer.

A single-provider architecture can simplify:

• development;
• merchant onboarding;
• support;
• reporting;
• commercial agreements; and
• payment operations.

However, larger platforms may eventually want flexibility across more than one provider.

Reasons can include:

• different merchant risk profiles;
• international expansion;
• different payment methods;
• pricing;
• resilience;
• provider acceptance;
• local acquiring;
• specific terminal requirements; and
• reducing dependency on one PSP.

Architecture decisions made during the first integration can determine how easy this becomes later.

Refunds Need to Return to the Healthcare Workflow

Refunds are common across healthcare.

Examples include:

• cancelled appointments;
• changed treatment plans;
• refunded deposits;
• cancelled veterinary procedures;
• optical order changes;
• duplicate payments; and
• billing errors.

The platform should ideally understand:

• original payment;
• refund amount;
• refund status;
• merchant;
• practice location;
• invoice or order;
• user initiating the refund; and
• final reconciled position.

Chargebacks and Disputes

Healthcare software companies should establish where card disputes sit within the support model.

Questions include:

• Does the payment provider communicate directly with the merchant?
• Does the platform display disputes?
• Can evidence be uploaded through the software?
• Who receives card-scheme deadlines?
• Who explains the dispute process to the healthcare practice?
• How are dispute fees reported?
• How does a chargeback affect merchant settlement?

The platform should also be careful not to encourage practices to upload unnecessary clinical information into payment-dispute systems.

Healthcare Data and Payment Data Are Different

This distinction is particularly important in healthcare software.

UK data-protection law gives additional protection to health information as special-category personal data.

Depending on context, information such as appointment details, invoices or treatment-related records may reveal information about a person's health.

The payment platform does not necessarily need that information.

Healthcare software designers should therefore consider what information is actually passed to:

• the gateway;
• acquirer;
• payment processor;
• card statement;
• payment link;
• transaction metadata;
• webhooks;
• merchant dashboard; and
• support systems.

Clinical detail should not be placed into payment fields simply because the API allows custom metadata.

PCI DSS and Healthcare Software

PCI DSS provides security requirements for organisations that store, process or transmit cardholder data, or that can affect the security of the cardholder-data environment.

The current PCI DSS standard published by the PCI Security Standards Council is PCI DSS v4.0.1.

A healthcare software company should determine the PCI scope created by its chosen integration.

Questions include:

• Does raw card data ever pass through our servers?
• Do we host payment fields?
• Is checkout hosted by the provider?
• Are terminals point-to-point encrypted?
• Are card details tokenised?
• Does our software environment influence the cardholder-data environment?
• What PCI obligations apply to us?
• What PCI obligations apply to our healthcare merchants?

Architecture should be designed to minimise unnecessary exposure to cardholder data.

Payment References Should Avoid Unnecessary Health Information

Software companies should think carefully about transaction descriptions and metadata.

For example, references such as:

“John Smith – HIV consultation – Clinic A”

would clearly reveal considerably more information than a payment provider needs to process the transaction.

A more appropriate internal reference may use a non-clinical invoice or transaction identifier while the healthcare software retains the detailed record within the appropriately protected clinical environment.

Multi-Site and Multi-Entity Healthcare Customers

Larger healthcare customers may operate:

• multiple practices;
• multiple legal entities;
• franchise-style structures;
• different bank accounts;
• central finance teams;
• different brands;
• different merchant accounts; and
• multiple settlement destinations.

The payment integration should therefore consider whether the software can support:

• multiple merchant IDs;
• multiple legal entities;
• separate bank accounts;
• central reporting;
• site-level reporting;
• user permissions;
• refund permissions;
• shared customers;
• group pricing; and
• new locations being added over time.

Reporting and Reconciliation Are Core Product Features

Processing the payment is only half the problem.

Healthcare businesses need to understand what happened afterwards.

Useful platform reporting can include:

• transaction status;
• payment method;
• merchant location;
• invoice reference;
• refunds;
• chargebacks;
• fees;
• settlement;
• payout date;
• outstanding balances;
• recurring-payment status; and
• failed transactions.

For multi-site healthcare groups, the ability to reconcile at both practice and group level can become a significant product advantage.

Webhooks Matter as Much as Payment APIs

A modern payment integration should be designed around events that happen after the original payment request.

These can include:

• payment succeeded;
• payment failed;
• refund completed;
• chargeback received;
• merchant verification required;
• merchant approved;
• merchant restricted;
• payout sent;
• subscription payment failed;
• card updated; and
• account status changed.

The software needs reliable webhook handling, idempotency and internal status management so that payment state remains accurate.

Support Responsibilities Should Be Agreed Before Launch

Healthcare practices will not distinguish neatly between a “software issue” and a “payment issue”.

If the payment button sits inside the healthcare platform, the customer is likely to contact the software company first.

The parties should therefore establish who supports:

• merchant onboarding;
• declined applications;
• verification requests;
• terminal hardware;
• failed transactions;
• refunds;
• chargebacks;
• settlement queries;
• fee queries;
• recurring-payment failures;
• account restrictions; and
• technical incidents.

A commercially attractive revenue share can become much less attractive if the platform unexpectedly inherits a large payment-support workload.

Healthcare Payment Provider Due-Diligence Checklist

What Information Should a Healthcare Software Company Prepare?

Before approaching payment providers, build a clear picture of the opportunity.

Useful information includes:

• software product;
• healthcare verticals served;
• number of existing business customers;
• countries where those customers operate;
• number of new customers onboarded each month;
• estimated annual payment volume;
• average payment volume per customer;
• average transaction value;
• maximum transaction value;
• percentage of card-present payments;
• percentage of online payments;
• recurring-payment volume;
• Direct Debit requirements;
• terminal requirements;
• payment-link requirements;
• current payment integrations;
• current customer adoption;
• development resources;
• desired level of white-labelling;
• preferred onboarding model;
• geographic expansion plans;
• support capabilities;
• desired commercial structure; and
• expected launch timeframe.

The stronger this information is, the easier it becomes to compare payment-provider propositions properly.

When Should a Healthcare Software Company Review Its Existing Payments Partner?

A platform may need to review its current arrangement if:

• merchant onboarding is slow;
• too many customers are being declined;
• the payment provider's sector appetite has changed;
• terminal functionality is limited;
• recurring payments are difficult to manage;
• the commercial model is weak;
• the platform is expanding internationally;
• customer support is poor;
• the software wants greater control over branding;
• the provider cannot support new product features;
• token portability is becoming a concern;
• the platform wants multiple acquirers;
• payment volumes have increased substantially; or
• payments have become strategically more important to the business.

The larger the embedded payment portfolio becomes, the more carefully migration needs to be planned.

Merchant Advice Service View

For an established healthcare software business, selecting a payment provider should not start with an API demonstration or a headline revenue-share percentage.

Start with the merchant portfolio.

Understand:

who your healthcare customers are + what they sell + how they take payment + what transaction values they process + which payment methods they require + how they need to be onboarded.

Then determine:

how much of the merchant lifecycle the software company wants to own.

A relatively light-touch ISV integration may be enough for some platforms.

Others may have sufficient scale and payment volume to justify embedded payments, white-labelling or a managed PayFac structure.

The right answer depends on the software business, its customers and its long-term payment strategy.

How Merchant Advice Service Helps Healthcare Software Providers

Merchant Advice Service is an independent UK payments information, comparison and provider-matching service.

We can help established healthcare software businesses understand the different payment-provider and partnership models that may be available.

This can include:

• ISV payment partnerships;
• integrated payments;
• embedded payments;
• white-label payment processing;
• merchant acquiring;
• payment gateways;
• terminal integrations;
• merchant onboarding;
• recurring payments;
• tokenisation;
• payment-provider migration;
• multi-acquirer strategies;
• commercial payment models;
• platform payment strategy; and
• more complex software-payment requirements.

The objective is to understand the healthcare software platform and its merchant portfolio before comparing potential payment partners.

Final provider suitability, underwriting, contracts, technical approval and commercial terms remain subject to the relevant payments organisations.

Find Your New Processor

Sources and Reference Organisations

• Stripe Connect – platform payments, merchant onboarding and embedded payments
• Stripe – merchant onboarding and verification for software platforms
• Adyen for Platforms – onboarding users, processing payments and payouts
• Adyen – hosted and API-led merchant onboarding
• PCI Security Standards Council – PCI Data Security Standard
• PCI Security Standards Council – current PCI DSS documentation
• Information Commissioner's Office – health information and special-category data

Further Merchant Advice Service Guides

• Embedded Payments for SaaS & Platforms
• How ISVs Can Benefit From Integrated Payments
• White-Label Merchant Processing for Platforms & SaaS
• Moving Stored Cards, Tokens & Recurring Payments
• Split Payment Gateways for Platforms

Editorial disclosure: Payment providers and platform-payment products are referenced to explain different technical and commercial models available to software companies. Inclusion does not constitute a recommendation or ranking. Provider functionality, merchant acceptance, commercial models, APIs, integrations and geographic availability can change and should be verified directly before making a decision.

This guide provides general payments information and does not constitute legal, regulatory, data-protection or PCI compliance advice. Software platforms considering regulated payment activities, Payment Facilitator structures or other models involving greater responsibility for customer funds or merchant onboarding should obtain appropriate specialist advice.