How fast is merchant boarding?
Clean applications clear the automated flow without a human touching them, and the merchant gets a live MID at the end of it, not a “we’ll be in touch.” Fast here does not mean loose: it means the file arrives complete, the checks run in one pass, and nothing sits in a queue waiting to become somebody’s Tuesday.
Speed comes from ownership. The underwriting engine, the credit policy, and the MID issuance all live on QorCommerce, so there is no application packet crossing to a third-party processor and waiting in someone else’s queue. When boarding, decisioning, and issuance are one system, time-to-MID is a number you can watch, not a promise you relay. If your funnel loses signed merchants to boarding lag, that is not a sales problem; it is a queue problem, and this is the fix.
What does Automated Underwriting check?
Four things, in one pass: who the people are, whether the business is real, whether either appears on a match or sanctions list, and what the credit signals say. Identity verification covers principals and beneficial owners; business verification confirms the entity, its registration, and its web presence against the stated business model.
Match-list screening includes the card-brand terminated-merchant checks and sanctions lists. Credit signals (processing history, requested volume, average ticket, vertical risk) feed a risk score that routes the application: auto-approve, decline, or human review.
If you have worked a boarding desk, you know the real cost is not the checks; it is the chasing. Here the file arrives worked: identities verified, lists screened, the web presence already matched against the stated business model. The application you open is the application you can decide.
When do humans review?
When the score says so. Applications that trip a threshold (volume out of profile, a vertical flagged in policy, a mismatch between stated and observed business) route to an exception queue where a QorPay underwriter works them.
Human review is a defined path with defined thresholds, not a fallback for a broken automation. The reviewer applies the same written credit policy the engine runs; the difference is judgment on the edge cases, and a decision the merchant can actually ask questions about.
The result is a queue an underwriter would choose to work: it holds exceptions, not everything, and every decision leaves with its reasons attached. A decline with reasons survives the sales team’s appeal; an approval with conditions survives the auditor’s question. Nothing in this flow asks anyone to defend a number they cannot explain.
How do platforms embed boarding?
Boarding is an API before it is a form. Send applications through the boarding API from your own onboarding UI, or drop in QorPay-hosted forms and skip the build entirely. Either way the merchant never leaves your product to “apply with our payments partner,” and either way the same engine, the same policy, and the same speed sit underneath.
Status is queryable throughout (submitted, in review, approved, MID issued), so your platform can gate features on boarding state instead of emailing someone for an update. Signup, decision, and a processing merchant become one continuous flow your product controls. The building QorCommerce solutions guide covers it end to end; a developer can read it before lunch.
What about hard-to-place merchants?
They get reviewed, not auto-declined. A merchant that fails a mainstream processor’s MCC screen goes to manual review here, where an underwriter looks at the actual business: processing history, financials, dispute record.
Approval may come with conditions (a reserve, a volume cap, tighter monitoring), but it is a written decision under our own policy. Because QorPay carries the credit risk, we can say yes where a reseller of someone else’s risk appetite cannot. If your book has merchants you believe in and cannot place, send us the profile; a yes with conditions beats a template decline every time it is the right yes.