Every merchant is screened before an account exists.
Screening is automated, evidence-based, and re-run after go-live. A merchant who cannot pass it is not onboarded — which is what makes the platform viable for the merchants who can.
Why we screen this way
Processing relationships rarely end over financial performance. They end over what a reviewer finds on a website: a catalog that differs depending on who is asking, a therapeutic claim on a product page, an age or eligibility gate that is decorative rather than enforced. Standard underwriting looks at financials and does not read HTML. We read the HTML.
What we scan for
Differential serving
We request each applicant's catalog twice — once as an ordinary browser and once as a search-engine crawler — and compare the inventory returned. We repeat the comparison with and without referral and affiliate cookies set. Any storefront that presents different products to different requesters is refused until it presents one catalog to everyone.
Applicants who need to restrict who may buy are directed to decouple listing from purchase: list the catalog openly and gate the transaction server-side. That is a defensible control. Hiding inventory from some requesters is not.
Claims and use framing
- Disease claims. Copy asserting a product treats, cures, prevents or reverses a named condition.
- Human-use framing on non-consumer products. Dosing guidance, self-administration instructions or body-weight calculations on catalogs positioned for laboratory or research use — where the instructions and the disclaimer contradict each other.
- Unsupported assertions. Purity, approval or clinical claims with nothing on the page substantiating them.
- Category vocabulary. Pharmacy and prescription language on merchants who are not licensed pharmacies.
Preventive controls
Where an applicant states that purchases are restricted — to verified buyers, to businesses, to an age threshold — we probe the order endpoint directly to confirm the restriction is enforced on the server. A modal the customer can dismiss is not a control, and we do not accept one as evidence of a control.
Card-data handling
Card fields must be served from a PCI-compliant provider in an isolated frame. Merchants capturing card numbers in their own page and posting them to their own servers are refused, because that liability does not stay with the merchant.
Commercial hygiene
- Reachable terms, refund/return and shipping policies.
- A working support email and telephone number.
- Consistent business identity across storefront, checkout and statement descriptor — the mismatch that produces “I do not recognise this charge” disputes.
- Prices, shipping and totals disclosed before payment details are entered.
- No negative-option or hidden recurring billing.
How findings are handled
Findings are graded, and every one quotes the page and the exact text that triggered it, with the remediation.
- Blocking — must be remediated before an account is created.
- Required — onboarding may proceed with a remediation deadline.
- Advisory — recommended, not gating.
Remediation is verified by re-scan, and the before/after result is retained on the merchant file. We would rather lose an applicant than onboard one we would have to offboard later.
Ongoing monitoring
Screening is not a one-time gate. Accounts are re-scanned periodically and after material changes to a merchant's site. A blocking finding after go-live pauses the account until it is resolved. Merchants agree to this at onboarding.
What we will not do
We do not help merchants conceal what they sell. Every control described here pushes in the same direction: describe the business accurately, restrict what needs restricting in a way that actually works, and be the same business to every party who looks. Applicants looking for the opposite are not a fit, and our acceptable use policy says so explicitly.