Preparing certification evidence for an acquirer's risk desk

By the time an operator is filing, the acquirer's requirement is settled. Nobody on the merchant's side is going to argue it away, and the useful question is much narrower: what has to reach the risk desk, in what form, for the merchant to get boarded without four rounds of email and a fortnight of drift.

That is a production problem, and it belongs to whoever prepares the filing. The merchant will forward whatever you give them, unedited and usually without explanation, so the pack you assemble is the pack an analyst reads. Assembling it well is one of the least glamorous and most valuable things a filing operation does.

This is written for the agencies, MSOs and platforms who file on merchants' behalf and are then asked to evidence it, and for the risk analyst on the other end deciding whether what arrived is enough to clear a category condition.

Four facts, and everything else is context#

A risk desk can act on four things:

• the certified legal entity name, exactly as it appears on the certification record;
• the websites within the certified scope;
• the current status;
• the date that status was checked, and where it was checked.

Your case file contains far more than that. Intake forms, document requests, correspondence, the merchant's own description of its clinical and fulfilment model, internal review notes. All of it is essential to you and none of it belongs in what you send. An analyst working a queue reads for those four fields and stops; volume that buries them reads as evasion rather than thoroughness.

The discipline is to lead with the four facts as a block, in that order, and to treat anything else as an appendix somebody may never open.

Make the facts checkable, not just sendable#

A certificate PDF forwarded by the merchant is the weakest evidence available to a risk team. It was produced by the party being assessed, it carries no freshness, and it can be months out of date without anybody intending to mislead. Analysts who have been burned by one treat all of them that way.

The stronger form is a fact the analyst can confirm without going through you. State the entity name and the domains as published, name the source you checked, give the date you checked it, and attach the certificate as supporting material rather than as the claim itself. Do not crop it, annotate it, re-typeset it into your own template or convert it into a screenshot. Every one of those makes a suspicious document out of a straightforward one.

If your own record of the check includes who performed it, include that too. A dated, attributed check is the difference between evidence and reassurance, and it is what survives when the analyst who received it has moved on and a sponsoring bank is reviewing the file two years later.

Resolve the entity question before you send#

The commonest stall in this whole process is an entity mismatch. The certificate names one legal entity; the merchant agreement is signed by another. Both facts are ordinary and the combination is frequently a perfectly legitimate structure, but it arrives at the desk unexplained, and an unexplained mismatch is indistinguishable from a borrowed certificate.

Pre-empt it. One line of mapping does the work: which entity holds the MID, which entity is certified, which entity presents the offer to the customer, and how those relate. If they do not relate cleanly, say so first rather than letting it be discovered, and say what is being done about it. How a risk desk reads certified scope and what it can and cannot conclude from it is worked through in certification status as an underwriting signal; your job on this side is to make that reading possible at all.

List the domains, including the ones outside scope#

Domain scope fails silently, which is why it is worth over-communicating. Give the analyst two lists: the domains within the certified scope, and the domains that will actually route through the MID being boarded. If those lists are identical, say so explicitly — a stated "these are the same" removes a question that would otherwise cost a day.

If they are not identical, the difference is the entire conversation, so put it at the top of the pack. Include domains that sit deliberately outside scope, with a line on what each one is: parked, redirecting, presenting no offer, or processing on a separate MID. Merchants routinely forget checkout subdomains, landing pages built for paid acquisition, and retired brands that still resolve. You will find those in intake if you ask for them; the analyst will find them in a browser if you do not.

Present a file in progress rather than dressing it up#

The hardest packs are the ones where nothing has been decided yet. The temptation is to make the file sound further along than it is, and it is always a mistake, because the correction lands on the merchant rather than on you.

Say plainly what is true: submitted on a date, at a stated stage, with or without anything outstanding on the merchant's side, and last checked on a date. Do not characterise what the certifying body is doing with the file, how long it takes, or what it is likely to conclude. We prepare filings and take no part in the decision, so none of that is ours to describe, and an operator who implies otherwise in writing has created a problem that surfaces later at the worst possible moment.

What you can offer instead is something the acquirer can diarise: an undertaking to re-issue the same dated statement every fortnight, or on whatever rhythm suits them, for as long as the file stays open. Whether that is enough to board on is not your call. The acquirer's own policy — hold, decline, or board conditionally with a review date attached — is set out from their side in onboarding telehealth merchants at an acquirer.

Build the pack so you can send it again#

Everything in the pack decays. Status was true on the day you checked, scope changes when a merchant adds a brand or restructures, and the pack you sent in March describes a merchant who existed in March.

So build it as something regenerable rather than something written. A per-case record holding entity, domains, status, last-checked date and checker turns the next request into a lookup. Operators who keep this in email rebuild it by hand every time, rebuild it slightly differently each time, and eventually put two inconsistent versions of the same merchant's scope into the same acquirer's file. The record that makes running many applications at once tractable is the same record that makes this a two-minute job.

Agree a re-issue rhythm with the merchant while the relationship is still cordial, and tie it to their renewal cycle so the pack refreshes before an acquirer asks.

What to leave out#

• Clinical protocols, prescribing policies, licence schedules and pharmacy agreements. A payments desk has no capacity to assess them and no appetite for holding them.
• Drafts, internal QA notes and your own working commentary on the merchant.
• Any characterisation of the certifying body's criteria, fees, timing or likely response.
• Predicted outcomes, promised dates, and anything phrased as reassurance rather than as a dated fact.

Leaving those out is not caution for its own sake. Each one invites a question your desk cannot answer, and unanswerable questions are what turn a two-day boarding into a two-week one.

The operator is paid to make the condition legible#

The merchant is buying access to processing. The acquirer is satisfying a category condition it did not write. The operator in the middle is being paid to make the second thing legible without over-claiming, and the whole job comes down to four facts, checkable at source, dated, and re-sendable.

If you are running more than a handful of these, the VeriScripts platform keeps that record per case — entity, domain scope, status and history — so handing a payments partner a straight answer is a lookup rather than an archaeology project. If you have one merchant who needs one application prepared and submitted properly, our done-for-you service covers it at a published price.