Comparison
Against NMI Merchant Central, row by row
Merchant Central is IRIS CRM — NMI acquired it and renamed it, so if you have used one you have used the other. It is a serious product with a long head start, and the table below says so where it is true.
What follows is 30 capabilities with a verdict on each side and a note explaining it. Both columns include the rows we lose.
- Both, fully
- 4
- Only us
- 20
- Only them
- 4
- Neither, yet
- 2
“Neither, yet” is a row where both sides are partial or unestablished — the four add up to 30.
Method
How to read this table
Their column quotes them
We cannot audit somebody else’s software, so every cell about Merchant Central describes what NMI publishes about it, and links to the page it came from. Read those pages — they are good, and they are the primary source.
“Not established” is not a no
Where we could not confirm something from published material, the cell says so rather than scoring a point. A product page is written to sell, not to enumerate — absence from it is not absence from the software.
Our column is code, not roadmap
Nothing is ticked here on the strength of being planned. Where something is half-built — processor connectors, most obviously — the cell says which half.
Compared on 15 August 2026 against NMI — Merchant Central , NMI — Payments CRM , NMI — Residuals Management , NMI — Merchant Signup & Onboarding , NMI — Merchant Boarding . Both products change; if you find a row that has gone stale, tell us and we will fix it.
Comparison
Residuals, splits and payouts
This is the part that decides what people are paid, so it is the part worth comparing hardest. Both products calculate residuals. What differs is what happens when the arithmetic is asked an awkward question.
| Capability | Superior CRM | NMI Merchant Central |
|---|---|---|
| Residual calculation across processors | Yes Import processor residuals and allocate across agents and partners by configured splits, including overrides up a hierarchy. | Yes Published as unified residuals reporting that combines each processor report into one source, viewable at portfolio, processor, merchant or agent level. |
| Exact minor-unit arithmetic, never floating point | Yes Every amount is an integer in the currency’s own minor unit, with its exponent applied. Rounding happens once, at a stated point, rather than accumulating. | Not established Not something a product page would state either way, and not something we can establish from outside. Ask them directly — it is a fair question to put to any vendor holding your residual maths. |
| Outstanding derived from the ledger, not stored as a balance | Yes What a partner can draw is computed as allocations less payouts still in flight. There is no stored balance that can drift out of step with the rows behind it. | Not established Not published. The question to ask is what happens to a partner’s available balance when a payout fails after being marked sent. |
| A failed payout releases its hold; a pending one does not | Yes A pending payout reserves its amount. A failed, returned or voided one gives it back. The same residual cannot be drawn twice, and the rule is a pure function with its own tests. | Not established Not published. |
| Multi-currency residuals with dated, directional FX | Yes Rates are directional and effective-dated. No rate is quietly inverted to fill a gap, a manually entered rate outranks a fetched one on the same day, and a missing rate stops the run rather than assuming parity. | Not established Not published. Relevant only if you pay partners in more than one currency. |
| ACH payout execution | No This product does not move money and is not built to. It computes what is owed, assembles the run and holds it for approval — then hands off to a disbursement seam. That is a deliberate boundary, not a missing feature, and it is why nothing here is in PCI scope. | Yes Published as automated ACH payouts from the same dashboard. |
| Scheduled runs that survive short months and a missed window | Yes A run set for the 31st still fires in February, and a cycle missed while a scheduler was down is caught up rather than skipped. Runs hold for approval by default instead of paying out unattended. | Partly Automated residual runs are published; the behaviour at a month boundary or after an outage is not. |
| 1099-NEC for the agents and partners you pay | Yes Box 1 built on a cash basis — keyed on the date a payout actually settled, not the period it covered — with 31 December handled rather than lost, and payees missing a TIN, address or legal name surfaced before filing season. | Not established Their published tax surface is 1099-K and monthly statements for merchants, which is the other side of the ledger — a different form for a different taxpayer. Whether the agent-side 1099-NEC is covered is not stated. |
Comparison
Signing and boarding a merchant
The stretch from first call to a live MID. This is where Merchant Central is strongest, and the matrix says so.
| Capability | Superior CRM | NMI Merchant Central |
|---|---|---|
| Boarding straight into processors | Partly Six adapters exist — NMI, Fiserv, TSYS, Worldpay, Nuvei, Elavon — with capabilities declared per processor rather than assumed. None has been run against its processor’s sandbox, so none can be enabled in live mode: the product refuses it in two places and a test asserts all six stay unverified. Boarding today means a submit-and-poll seam that is built and tested, against connectors that are not yet proven. | Yes Published as boarding through 10+ processor integrations, with TurboApp extracting merchant information and populating processor boarding fields. This is a real and substantial lead. |
| Automated KYC, KYB, AML and risk scoring | No Not built. Underwriting here is a structured human workflow — stipulations, documents, decision rules — with no third-party identity or credit data behind it. MATCH/TMF and credit checks are likewise absent. If automated risk decisioning is what you are buying, this is not it yet. | Yes Published as ScanX, performing 100+ risk checks using automated KYC, KYB and AML data to produce risk-scored decisions. |
| OFAC sanctions screening that cannot report a clean result it did not produce | Yes SDN screening on merchants and principals against Treasury’s own list, refreshed nightly. Its status has three values, not two: screening switched off, a list that failed to download, a blank name or a provider timeout all record unknown with a reason, and unknown blocks approval unless somebody signs it off explicitly. | Partly AML data is published as part of ScanX. How an inconclusive or failed check is represented is not stated — which is the whole question, because a null result reads as fine to every screen that does not special-case it. |
| E-signature on applications and proposals | Yes Templates, a public signing page and an ESIGN/UETA audit trail. The signed copy stays attached to the account it created. | Yes Published as built-in eSignature for merchant processing applications. |
| Separate merchant and agent-recruitment pipelines | Yes Two boards with their own stages, because signing a restaurant and recruiting a sub-agent do not share a funnel. A lead cannot drift between them. | Not established A CRM with configurable pipelines is published; whether agent recruitment is modelled as its own board is not. |
| A public enquiry form that attributes a stranger to the right tenant | Yes Signed partner-lead forms an ISO can put on its own site, with the submission attributed to the right organisation and dropped into triage. | Partly Merchant signup and onboarding flows are published. Attribution of an inbound enquiry to a specific partner office is not described. |
Comparison
Running the portfolio afterwards
Both products keep going after the signature. The differences here are about how many separate places the work ends up in.
| Capability | Superior CRM | NMI Merchant Central |
|---|---|---|
| Support ticketing with routing and SLA timers | Yes Queues, assignment by agent skill, priority and SLA escalation capped at a configured level, sitting beside the merchant rather than in a separate helpdesk. | Yes Published as an integrated helpdesk with tickets routed to teams automatically by configured workflow. |
| Merchant-facing portal | Yes Optional and off by default. A portal login is bound to exactly one merchant, refused on every route not explicitly marked as merchant-facing, and an unbound login resolves to nothing rather than to everything. | Yes A merchant portal with a transaction dashboard, PCI status and daily alerts is published. |
| Email, SMS, live chat and voice on one timeline | Yes Four channels, all writing back to the record they belong to: drip campaigns with exit conditions, SMS with a consent engine and quiet hours, in-app chat that escalates to a ticket, and click-to-call with screen-pop on inbound. | Not established A payments CRM with merchant communication is published; the specific channel set is not enumerated. |
| TCPA and A2P consent enforced before a message is composed | Yes Consent state, quiet hours by the recipient’s timezone, and per-segment metering that matches what the carrier will actually bill — so the number a rep is shown before sending is the number you pay for. | Not established Not published at this level of detail. |
| Automation on leads, merchants and tickets | Yes A graph-based workflow engine: triggers, conditions and actions, with delays that resume, runs that fail visibly rather than retrying forever, and auto-approval off unless deliberately turned on. | Partly Configured workflow is published in the context of ticket routing. A general automation engine across objects is not described. |
| Custom fields without a release | Yes Fields an office adds to its own leads and merchants, visible across the merchant screen. No schema change, no deploy. | Not established Not published. |
| Mobile app | No There is none. The web application is responsive and works on a phone, which is not the same thing as an app a rep keeps on a home screen. | Yes Published as a mobile app giving agents their month’s residuals broken down by processor, with gross sales volume, transaction volume and net residual. |
Comparison
The parts you only notice when they fail
Tenancy, auditability and operational visibility. Nobody buys a CRM for these and everybody regrets not asking about them — which is why they are the rows where the difference is largest.
| Capability | Superior CRM | NMI Merchant Central |
|---|---|---|
| Tenant isolation enforced in the data layer | Yes Every query is filtered by organisation by a database-client extension, not by each service remembering to add a where clause. A service that forgets cannot leak, because the filter is not the service’s to forget. Models are discovered from the schema, so a new table cannot be missed. | Not established Multi-tenant by nature — it serves many ISOs — but how isolation is enforced is not published. Worth asking, because "every query filters correctly" and "no query can fail to filter" are very different guarantees. |
| Tamper-evident audit trail | Yes Activity is hash-chained hourly into checkpoints, and the head of those chains is signed nightly and sent somewhere this deployment cannot reach — the difference between an edit being detectable and an edit being detectable by somebody other than whoever made it. | Not established Audit logging is a normal expectation of a CRM in this industry; tamper-evidence is a stronger and separate claim, and is not published. |
| Operator visibility into background work | Yes Every scheduled job reports its last run, consecutive failures and whether it is overdue, on one page. Everything leaving the building goes on a durable queue with retries and a dead letter, and a watcher turns all of it into notifications with deduplication and an all-clear. | Not established Not published. This is a fair thing to ask any hosted vendor: when a residual import silently stops, who finds out, and how long does it take. |
| Subject-access export and erasure | Partly Every table holding personal data is registered, and a guard fails the build when a new one is not — so an export cannot quietly go stale. Erasure tombstones the rows. Two stated gaps rather than discovered ones: it does not reach document bytes in blob storage, nor the verbatim line kept by a data migration, because the guard reads column names and cannot see inside a JSON blob. | Not established Not published. |
| Encryption with a rotatable key | Yes Stored credentials, 2FA secrets and contact numbers are encrypted under a keyring, so a key can actually be retired: a background sweep moves values onto the new key and reports, from the rows themselves, when the old one is safe to drop. | Not established Not published. |
| Bring your own email and SMS providers | Yes Email through SendGrid, or through your own Gmail or Microsoft 365 mailbox over SMTP — a mailbox and an app password, with no OAuth project to register. Text and voice through Twilio. Your sending reputation, your 10DLC registration, your bill — and every outbound integration is off until you turn it on, so a fresh tenant composes messages, runs every consent gate, records what it decided, and delivers nothing. | Not established Not published. |
| Migrating in from the other one | Partly Merchants, leads, tickets and notes come in from CSV exports, with a preview that names every column nothing would carry before a single record is written, and re-importing updates rather than duplicating. Partial because it is CSV rather than a direct pull, and because residual history goes through the separate residual importer. | Not established What Merchant Central offers for getting a book of business *out* is not something we found published. Worth asking them directly, and worth asking us the same question — the answer here is that every table is exportable and the migration record keeps the original line. |
| Alerts into the channel your team already watches | Yes Every scheduled job, dead letter and stalled queue can raise an alert into Microsoft Teams or Slack, deduplicated, with an all-clear when it clears. Teams refuses the generic JSON body every other tool accepts, so the payload is chosen from the URL — a connector gets a MessageCard, a Workflows endpoint gets an Adaptive Card. | Not established Not published. Worth asking of any hosted CRM: when a background job stops, who finds out, and through what. |
| Independent of any one gateway | Yes Its own frontend, API and database. It needs no gateway tenant to run, and a processor connector is an optional outbound integration rather than a dependency — including the connector to NMI. | Partly Merchant Central is NMI’s own product and integrates with 10+ processors, so it is not gateway-locked in the narrow sense. It does mean your CRM and one of your gateways are bought from, and renewed with, the same company. |
The short version
Three differences that decide it
Strip out everything both products do, and this is what is left.
- 1
The balance is derived, so it cannot drift
What a partner can draw is computed every time from allocations less payouts still in flight — there is no stored balance to fall out of step with the rows behind it. A pending payout reserves its amount; a failed, returned or voided one hands it straight back. The failure this prevents is a partner paid the same residual twice after a payout bounced, which is discovered a quarter later by the partner and not by you.
- 2
Nothing reports a clean result for a check it did not run
Sanctions screening, identity verification and the do-not-call seam each carry three states, not two — and every one of them records unknown, with a reason, when screening is switched off, a list failed to download, a name was blank, or a provider timed out. Unknown is not a soft pass: it blocks approval unless somebody signs it off explicitly. A stub returning clear would board a sanctioned merchant while leaving an audit trail saying it was checked, which is worse than no screening at all, because it destroys the evidence that nobody looked.
- 3
A query cannot forget which office it belongs to
Isolation between organisations is enforced by the database client itself, not by each piece of code remembering to filter. The tables it applies to are discovered from the schema, so a new one cannot be left out, and the rule is a pure function with thirty tests of its own. The distinction worth pressing any vendor on: “every query filters correctly” is a claim about today’s code, and “no query can fail to filter” is a claim about tomorrow’s.
Straight answer
Where Merchant Central is ahead today
If any of these is the thing you are buying, buy theirs. Saying so here costs us the deals we would have lost in month three anyway.
Proven processor boarding
They publish 10+ live processor integrations with field-level application mapping. We have six adapters whose capabilities are declared per processor and whose payloads are tested — but none has been run against its processor’s sandbox, and the product refuses to enable an unverified one in live mode. That is a real gap and it is measured in partner agreements, not in code.
Automated risk decisioning
ScanX runs automated KYC, KYB and AML checks and returns a risk score. We have sanctions screening and a structured human underwriting workflow, and no identity, credit or MATCH/TMF data behind it at all.
A mobile app, and a track record
Their agents get residuals on a phone. Ours get a responsive web app, which is not the same thing. And Merchant Central has been running real portfolios for years longer than this has existed — which is worth something real when the question is who you trust with a residual run.
Due diligence
Six questions worth asking both of us
Answers to these tell you more than any feature list, including this one. We will answer all six in writing.
- When a payout fails after being marked sent, what happens to that partner’s available balance?
- What does an inconclusive sanctions or identity check look like in the record — and can it be told apart from a clean one?
- If a residual import stops running, who is told, and how long does it take?
- Can an audit entry be edited by somebody with database access without it being detectable afterwards?
- Which capabilities are in the base price, and which are separately licensed modules?
- What comes with us if we leave, and in what format?
Bring a real residual month
The fastest way to settle this is to run one of your own processor reports through both. Bring a month with a failed payout and a split that changed mid-period — that is where the differences show up.