What happens at Underwriting?
Automated Underwriting is the QorCommerce boarding engine: KYC/KYB checks, business verification, match-list screening, and risk scoring run in one flow under QorPay's own credit policy. Because the policy is ours, an application that would sit in a reseller's queue waiting on an upstream processor gets a decision from the people who wrote the rules. Clean applications flow straight through to MID issuance; edge cases route to a human review queue instead of an automatic decline. That is why merchants mainstream processors turn away can get a real review here: the engine scores the business, not just the MCC.
Platforms can embed the same flow, so their merchants board inside the platform's own UI. See Automated Underwriting for the policy details.
How does boarding work?
Boarding is the step that turns an approved application into a live merchant: MID issuance, pricing assignment, and placement in the portfolio hierarchy happen on QorCommerce the moment underwriting clears. There is no file handoff to a separate processor's boarding team, because underwriting and boarding are two stages of the same system. A merchant approved in the morning can key its first transaction the same day.
For multi-tenant operators, boarding lands merchants into Channels, the portfolio layer, with per-level pricing and access control already applied. Platform integrations are covered in the building QorCommerce solutions docs.
How is a transaction routed?
Intelligent Routing is the layer that prepares a transaction before it moves, because by the time an authorization leaves the building, most of its fate is already decided. Which MID carries it, checked against MID/BIN health so a merchant account drifting toward a brand program never takes the traffic (health is a veto, not a suggestion). Which of the safe options approves best for this card, brand, and merchant category, scored continuously by the approval-performance ledger. Which network and cost path. Whether a stored token or the PAN is presented. Whether Level 3 / CEDP data rides along so the transaction qualifies for better interchange instead of silently downgrading. Whether 3-D Secure steps up. Whether a retry is even worth sending: doomed retries get killed in-line rather than burning the approval ratio.
Dozens of parameters, set in milliseconds, informed by the closed loop of authorization, settlement, and dispute outcomes on one transaction key. The layer is in staged delivery: the in-line kill controls run today as part of Circuit Breaker, with health scoring and approval-performance routing landing behind it.
What does tokenization cover?
Tokenization is the vault layer: card numbers and bank account details are swapped for tokens at the edge, so raw PANs never sit in your systems. QorCommerce vaults both card tokens and ACH tokens on the same API, and the capture surfaces (hosted checkout, Secure Embedded Forms, and qor-charge.js) are built so card data goes straight from the customer's browser to our PCI DSS Level 1 environment.
The vault is operational, not just secure: tokens are searchable by customer name, phone, email, or last four at portfolio scale, and every token carries its own transaction history, so "what has this card done with us?" is one lookup. Card and ACH tokens live in the same vault, which is what lets a saved credential move between one-time checkout and Recurring without re-collection.
Two details matter beyond the vault itself. ACH is tokenized too: bank account numbers vault the same way card numbers do, so recurring debits and larger invoice payments run on tokens, not stored account numbers. And a level of QorCommerce tokenization is portable across processors, so a credential tokenized with us is not a credential held hostage by us.
The practical effect is scope reduction: with embedded forms or hosted checkout, most integrations qualify for the shortest self-assessment questionnaires instead of a full audit. The PCI DSS compliance guide maps each integration style to its scope.
How does processing work?
Processing is the authorization layer: card-present, card-not-present, ACH, APMs, and Crypto/Stablecoin on one set of APIs, JSON in and out, idempotency built in. Card-not-present traffic runs through the payments API and the checkout surfaces above.
The lifecycle is complete, not just the sale: authorize and capture together or separately, partial captures, voids before settlement, full or partial refunds after it, and recurring charges against vaulted tokens. Response behavior is documented down to the code (approvals, declines, AVS and CVV results), so integrations are built against published tables instead of trial and error.
In person, card-present acceptance runs through QorConnect for countertop and terminal deployments and Qor@theEdge for edge devices, and the hardware story is deliberately open. Alongside QorConnect, the platform supports a wide range of semi-integrated terminal solutions, where the device handles the card and QorCommerce handles the transaction, and OEMs certify their own equipment against the platform through Qor QAC. The certified device catalog widens on the OEMs' schedule, not a single vendor's roadmap.
However a transaction arrives, it rides the same rails: tokenized against the same vault, screened by the same in-line risk controls, settled on the same ledger. A merchant running a counter and a website reconciles one batch, not two vendors, and a platform that adds in-person acceptance later integrates nothing twice.
Because QorPay is the processor, an authorization does not hop through a gateway, then a reseller, then someone else's switch. It hits our stack and goes to the networks.
How does clearing and settlement work?
Settlement is the money-movement layer: captured transactions batch, clear through the networks, and fund merchant deposits on infrastructure QorPay operates under its sponsor banks. Every authorization, capture, fee, and deposit is reconciled on our own ledger, which is why Reporting can trace a deposit back to its batch and each batch back to its transactions: the data is first-party, not a feed from an upstream processor.
When a settlement question comes in, the team that runs the ledger answers it. There is no vendor to forward it to.
How is risk handled?
| Code | Meaning | Match key | Action | Strike | Last 24h |
|---|---|---|---|---|---|
| 07 | Pick up card (fraud) | tokenmerchantamount | Circuit break | First-strike | 38 stopped · 6 merchants |
| 43 | Confiscate card (reported stolen) | tokenmerchantamount | Circuit break | First-strike | 21 stopped · 4 merchants |
| 63 | Security violation | tokenmerchant≥ amount | Circuit break | N=2 tolerant | 9 stopped · 3 merchants |
| 51 | Insufficient funds | tokenmerchant | Allow always | — | not matched |
Risk & Compliance is the layer that sets the signals: exposure limits, velocity thresholds, dispute-ratio ceilings, and card-brand rules, tracked continuously by Network Compliance Monitoring. Enforcement happens where the transaction is: Circuit Breaker, operating in the Intelligent Routing layer, acts on those signals in real time, halting anomalous flow and doomed retries before they move. Signals set here, enforced in-line there: that separation is what keeps detection continuous and enforcement instant.
Around those modules sit the standard controls: AVS and CVV checks, 3-D Secure, and the fraud prevention toolkit. Disputes follow a documented flow: see how disputes work. Because risk and processing are the same platform, a Circuit Breaker halt is a platform action, not a phone call to a third party.
Where is the intelligence?
Spanning the layers, not bolted on top. Owning the stack means QorCommerce records authorization, settlement, and dispute outcome against the same transaction key: the closed data loop that AI tools riding on someone else's processor never see. Two systems are being built directly on that loop.
MID/BIN Intelligence works the transaction path: its first delivered piece, Circuit Breaker, is deployed in the in-line auth stream, with health scoring and approval-performance routing in staged delivery behind it.
| Name | Drift | Schedule | Queue | Status | Last activity |
|---|---|---|---|---|---|
| WT Watchtower | stable | stream | 23 | healthy | 2s ago |
| SA Sentinel-AML | stable | stream | 4 | healthy | 11s ago |
| SG Signal | watch | stream + agg | — | healthy | 3s ago |
| GK Gatekeeper | stable | event (pool 4/8) | 18 | healthy | 45s ago |
| NO Notary | stable | event | 9 | healthy | 1m ago |
| LE Ledger | stable | event-on-sched | 2 | awaiting file | 2h ago |
| BW Bellwether | — | cron (daily) | — | scheduled 04:00 | 23h ago |
The Agentic Resource Center (ARC) works the operator side: regulated payments work, run through AI, with every money-moving decision still in human hands. ARC is a governed team of specialized AI agents working the highest-stakes corners of the payments lifecycle (merchant underwriting, transaction risk and financial-crime monitoring, settlement, and disputes) with dedicated oversight agents watching the rest, under one rule: the deeper into the money flow, the less an agent may act. Machines draft and recommend; people own and sign every irreversible decision; and every step lands in an audit trail an examiner can walk field-by-field, same day. The stack is deliberately model-agnostic: frontier models from multiple vendors routed through a single in-house gate that logs every request. ARC's first resident, Ask Qora (a concierge that answers account questions with live account data), is in beta now.
This is the part competitors can't copy by buying the same models: everyone has the models. The moat in AI isn't the models; it's the audited pathway that makes them approvable, and the operating history that compounds behind it. Provable beats promised.