Platform thesis
Why merchants work with us
The platform is built around one core idea: pre-screen the merchant, the catalog, and the public site before processor underwriting ever sees a bad application.Thesis
Processor risk teams do not only evaluate approved merchants. They also learn from the applicant pool flowing through a platform. A platform can have a clean approved book and still create risk if its funnel is full of weed shops, prescription-drug sellers, TRT clinics, peptide therapy resellers, GLP weight-loss brands, or other merchants looking for a processing workaround.
That is why pre-screening happens before account creation. The goal is not just to protect an individual merchant from rejection. The larger goal is to prevent the platform from being passed around in the wrong circles and training underwriting systems that the platform is a haven for restricted businesses.
Why Merchants Choose This Platform
Correct positioning before underwriting
Merchants get concrete guidance on how their site, catalog, checkout, policy pages, product language, and documentation should look before they apply.
Category-specific onboarding
The platform creates the processor account through the API with the intended merchant category, MCC, business description, support fields, fee policy, reserve policy, and metadata.
Lower false-rejection risk
The merchant can fix obvious issues before they become processor records, instead of sending a messy site directly into underwriting and hoping it gets interpreted correctly.
Operational compliance layer
The plugin and API enforce restricted-product checks, payment metadata, callback reconciliation, shipping monitoring, reserves, and audit logging outside the merchant's own site controls.
Applicant Pool Hygiene
Every rejected applicant should still leave a record. If a merchant applies, fails screening, edits the site, and reapplies, the platform needs to recognize the same legal entity, domain, email, EIN, owner, or catalog pattern. This prevents repeat applicants from learning the rules and gaming the intake process.
- Rejected applications are logged instead of discarded.
- Repeated domains, entities, owners, and emails should be linked together.
- Rejected applications should not be forwarded into processor account creation.
- Manual approvals should include a reason, admin identity, merchant category, MCC, and timestamp.
- Trusted onboarding links should be used only after a human has already approved the merchant.
Screening Pipeline
1. SKU Screen
First-pass regex and fuzzy matching against a master restricted keyword list. This catches obvious disqualifying catalogs before a processor account exists.
- Blocks prohibited substances, aliases, stems, and creative spellings.
- Returns the exact matched SKU or phrase.
- Routes clean submissions forward and failed submissions to remediation or rejection.
2. Site Audit
Headless browser crawl of the site and catalog. The scanner extracts visible text, page URLs, screenshots, and relevant assets, then evaluates them against the compliance policy.
- Flags medical, dosing, consumer outcome, injection, therapy, and supplement-style positioning.
- Scores severity instead of auto-rejecting every edge case.
- Routes borderline cases to human review.
3. Domain and Reputation Checks
WHOIS and lightweight reputation checks help identify throwaway domains, very new stores, and merchants with weak operating history.
- Domains under 90 days old are higher review priority.
- Traffic and public history can help calibrate manual review.
- Legal entity searches can surface lawsuits, warnings, or enforcement history.
4. MATCH and High-Risk History
Direct MATCH access usually requires acquirer or provider relationships. Until that exists, intake should ask about prior terminations and manual review should search for public risk signals.
- Ask directly about prior processor terminations.
- Search legal entity and owner names with risk terms.
- Integrate a real MATCH/data provider once volume justifies it.
Phased Buildout
| Phase | Build | Purpose |
|---|---|---|
| 1 | Intake form, SKU screen, restricted keyword JSON, rejection or review workflow | Remove the majority of obviously bad applications before account creation. |
| 2 | Playwright site audit, compliance-policy scan, structured violation output, severity scoring | Catch merchants that look acceptable on intake but have bad site positioning. |
| 3 | Agreement signing, merchant data prefill, hosted processor onboarding dispatch | Turn approval into a repeatable onboarding product. |
| 4 | Merchant portal with status, violations, credential delivery, re-scan request, and agreement status | Give merchants a clear path to fix issues without creating support chaos. |
| 5 | Vision model checks, WHOIS, traffic and domain reputation signals | Improve detection of images, visual claims, syringe/wet-goods cues, and throwaway sites. |
| 6 | MATCH or merchant-risk provider integration | Add external terminated-merchant and high-risk history checks when provider access exists. |
Compliance Standard Before Full Approval
A merchant is not fully ready until these are true:
- The catalog has no restricted products, aliases, hidden products, or prohibited product categories.
- The site does not contain medical, therapeutic, dosing, injection, consumer outcome, or supplement positioning.
- The site has the required category-specific compliance pages, checkout acknowledgments, support details, refund policy, and terms.
- Research-material merchants show research-use-only language, not-for-human-or-animal-consumption language, CoA references, and qualified buyer positioning.
- Images do not imply human use, before/after outcomes, injections, administration, wet goods, syringes, or supplement consumption.
- The merchant has signed the Merchant Agreement and represented sufficient ownership authority.
- The account was created through the platform API with the intended category MCC and metadata.
- The merchant token and callback URL have passed connection testing.
Rejected Merchant Policy
Rejected merchants should not be routed to Venmo, Zelle, Cash App, crypto, or other side-channel payment workarounds. Those trails create avoidable evidence that the platform knowingly redirected restricted businesses into informal payment rails.
The correct rejection posture is clean and narrow: if a merchant sells products that require pharmacy, telehealth, compounding, controlled-substance, or other high-risk underwriting infrastructure, they need a specialized acquirer or partner that explicitly supports that category. They are outside this platform's supported model.
Product Principle
The strongest product design is symmetric: the same compliance policy that merchants use to fix their brand is the same policy the scanner uses to evaluate them. Merchants should know exactly what standard they are being held to, and the platform should keep an auditable record of every pass, failure, override, and re-application.