Onboarding telehealth merchants at an acquirer

A payments team can onboard telehealth merchants safely without acquiring any healthcare expertise at all, provided it is disciplined about one distinction: the difference between what it asks a merchant for and what it verifies itself. Everything that goes wrong in this category goes wrong because those two lists were allowed to merge.

The failure looks like this. Someone on the risk desk decides certification is important, starts collecting supporting documents to assess it properly, and within a quarter has a queue of pharmacy agreements and clinical protocols that nobody is qualified to read. The desk has taken on unpriced advisory work, slowed its own onboarding, and created a written record of judgements it cannot defend.

This post is for underwriting, risk and partner teams at acquirers, PSPs and payment facilitators — the people who own the boarding policy and have to apply it consistently across a desk. If you are the merchant trying to get boarded, the sequencing advice here still applies to you, but the policy questions do not.

Decide what you are underwriting before you design the form#

You are underwriting a payment relationship. You are not underwriting a clinical model, and the moment your process implies otherwise you have volunteered for something you cannot deliver.

That sounds obvious until you look at what onboarding forms in this category actually ask for. Requests for prescribing protocols, clinician rosters, state licence schedules and dispensing agreements appear constantly, usually because a well-meaning risk analyst added them after an incident. Each one arrives, gets filed, and is never assessed by anyone with the training to assess it — which is arguably worse than not collecting it, because now the document is in your possession.

The scope discipline is simple. Your desk answers three questions: is this merchant who they say they are, does the category condition apply to them, and has the condition been satisfied for the entity and domains that will process on this MID? Everything else belongs to somebody else.

Put the gate where the merchant self-categorises#

The single highest-leverage change most teams can make is moving the certification question earlier — before pricing, before contracting, before any integration work starts.

Merchants in this category routinely reach the end of onboarding before anyone mentions it. By then the merchant has a signed agreement, an engineer halfway through an integration, and a launch date they have told their investors about. The requirement now reads to them as a bait-and-switch rather than a category condition, and your relationship manager is arguing a case they cannot win.

Put the question on the application itself, at the point where the merchant describes what they sell. Two fields do most of the work: what is being sold, and to whom is it being dispensed. If the answers put the merchant in the category, the certification question fires immediately and everything downstream — pricing, reserve, timeline — is quoted with that condition visible.

This is also the point to explain, briefly, that the condition is not yours to waive. Merchants who understand that stop negotiating and start filing, and naming what you will eventually want to see shortens the sequence further, because entity, domains, status and date are precisely what a prepared filer will hand you.

The gate only holds if the front line can carry it#

Underwriting sets the condition, but a relationship manager delivers it, usually on a call, often weeks before anyone on the desk sees the file. If that person cannot state the requirement accurately or cannot say who owns it, the merchant hears a preference rather than a condition and plans accordingly.

Give the front line three sentences and one hard boundary: the condition applies to this category, it is not the desk's to waive, and the merchant's answer goes on the application rather than into a call note. Sales teams follow rules they can explain and route around rules they cannot. The failure here is rarely someone overriding the gate outright — it is someone who mentioned it vaguely in the first conversation and never recorded the answer, so the file reaches underwriting looking clean.

Ask for four things, verify three#

Long onboarding checklists in this category produce worse information than short ones, because merchants answer thoroughly right up until the point they start guessing.

Ask for:

• the registered legal entity that will sign and hold the MID;
• each domain that will present the offer on that MID;
• a plain-language description of the clinical and fulfilment model, including who prescribes and who dispenses;
• certification status and, if certified, the certified entity name.

Verify the entity, the domain scope and the status yourself, at the published source rather than from a PDF, a screenshot or a portal export the merchant produced. Those go stale without anybody intending to mislead.

The fourth item, the model description, is not verified. It is context, and its job is to make the entity and domain mapping intelligible. If the description and the certified scope disagree, that is your signal to ask one more question rather than to start assessing clinical practice.

The mid-application merchant defines your policy#

Every acquirer in this category eventually meets the merchant who has applied and is waiting. Review takes as long as it takes, the merchant has revenue now, and your relationship manager wants a decision today.

Improvising this case is how a team ends up with three different answers in the same month. Decide the policy in advance, and pick one of three stances: decline until certified, hold the application open with no board, or board conditionally with constraints.

If you choose conditional boarding, the constraints have to be ones your systems can enforce without a human remembering. A named review date on the file. A volume ceiling that triggers something when breached. A defined consequence if status has not changed by the review date. Conditional approvals fail almost exclusively because nobody attached a mechanism that raises the file again — the exception is granted, the ticket closes, and eighteen months later nobody can say why this merchant was treated differently.

Mid-application is not a neutral fact either. A file submitted last week and one open for months with unanswered follow-ups are different situations, and asking which you have costs one email.

Decide what the gate does to merchants you already have#

Introducing the condition creates a back-book question the same afternoon, and it gets asked first by whichever relationship manager has the largest account that fails it. Answer it once, centrally, before it starts being answered account by account.

The workable stances are unremarkable: verify at the next annual review, require the condition within a stated window, or apply it only to new MIDs and to new domains added to existing ones. Any of those can be defended to a sponsoring bank. What cannot be defended is having no stance, because the desk then enforces the gate on merchants with no advocate and waives it for merchants with a persuasive one, and that pattern is extremely visible when somebody reads the portfolio end to end.

Do not become the merchant's compliance department#

The most expensive drift in this whole process is helpfulness. A risk analyst explains what evidence a merchant will need. The merchant asks a follow-up. Someone reviews a draft. Now your desk is advising on an application you have no visibility into, and the merchant reasonably believes you have blessed their approach.

Two lines hold. Your team explains the requirement and what you will verify. Your team does not explain how to satisfy the requirement, review the merchant's evidence, or predict an outcome. When merchants need that help — and many will — refer them out. Keeping a short list of independent preparers to hand is faster than fielding the questions yourself, and it keeps the boundary clean.

Record the decision so it survives the people who made it#

Whatever you verify, write down what was checked, when, by whom, and what scope it covered. Entity name, domains, status, date.

This matters at two moments. The first is portfolio review, when a sponsoring bank asks how a set of merchants was assessed and the honest answer is spread across four inboxes. The second is drift, which you can only detect against a baseline somebody took the trouble to write down.

Status is a fact with a date on it#

Whatever you verify at boarding describes the day you checked it, which makes re-checking a portfolio process rather than an onboarding one; the mechanics are set out in monitoring a certified portfolio for drift. What a status does and does not evidence, and why an underwriter should read nothing into it beyond scope and date, is worked through in certification status as an underwriting signal.

The merchants you refer out have somewhere to go#

If you find yourself repeatedly referring merchants somewhere, the VeriScripts platform is what agencies and telehealth platforms use to run those filings at volume, with client portals and a review workflow that produces the entity and domain scope your desk wants to verify. For a single merchant who needs one application prepared and submitted properly, our done-for-you service covers it at a published price.