I've watched a payment platform spend two years perfecting their API, ship a beautiful SDK, build elegant analytics, and then lose customers to a competitor with a worse API but a better onboarding flow. The customer wasn't choosing on developer experience. They were choosing on whether they could actually start accepting payments without spending three weeks on document collection and underwriting.
Onboarding is the part of payment platforms that nobody likes to talk about because it's not technically interesting in the way that, say, distributed transaction processing is interesting. It's tedious work, mostly compliance and operations, with a lot of human judgment calls. But it's where most platforms quietly die, and it's where the platforms that win quietly excel.
What "onboarding" actually means
When a merchant signs up for a payment platform, several things have to happen before they can take a single payment:
- Identification. Verify who the business is and who the people running it are. KYC (Know Your Customer) and KYB (Know Your Business).
- Underwriting. Decide whether to accept the merchant for processing, with what limits, at what rates, and under what risk classification.
- Bank verification. Confirm the bank account where settlement will go, and verify ownership.
- Configuration. Set up the merchant's account in the processor, configure their payment methods, fees, settlement schedule, and any custom rules.
- Integration. Help the merchant integrate the platform's APIs into their software (or, for POS, configure their hardware).
- Testing. Run end-to-end tests in sandbox, then a small live test transaction to confirm everything works.
- Activation. Flip the switch from "test mode" to "live."
Each step has its own failure modes. Documents get rejected. Underwriting flags issues. Bank accounts fail verification. Configuration disagreements with the processor surface late. Integration testing reveals edge cases. Each failure is a delay, and each delay is an opportunity for the merchant to give up and use someone else.
KYC/KYB is not optional
Regulators require it. Card networks require it. Your processor partner requires it. Even if you wanted to skip KYC, you can't.
What you can do is make it less painful. The default approach — "send us scans of these 12 documents" — is brutal for the merchant and slow for you (humans manually reviewing each document). The better approach uses identity verification services (Persona, Alloy, Onfido, Plaid, etc.) to automate large portions:
- Government ID capture and verification (driver's license, passport).
- Address verification through utility bills or bank statements automatically.
- Beneficial ownership verification through public records.
- Sanctions and PEP (politically exposed persons) screening.
- Adverse media screening.
What's left after automation is the harder cases: businesses with complex ownership, foreign founders, new entities without operating history, industries flagged by your processor as higher-risk. These need human review, but they should be the exception, not the default.
The platform that processes 80% of merchants automatically and routes 20% to manual review wins on speed. The platform that routes 100% to manual review loses on cost and patience. The platform that automates 100% gets shut down by their processor partner the first time a fraudster slips through.
Underwriting is judgment, not math
Underwriting is where the platform decides "should we accept this business?" The decision factors:
- Industry. Some are restricted (firearms, adult content, cannabis depending on jurisdiction). Some are higher-risk (travel, electronics, dropshipping). Some are vanilla (restaurants, professional services).
- Volume estimates. The merchant says they'll process $50K/month. The underwriter has to assess whether that's realistic and whether the platform can support it.
- History. New business or established? Prior payment processor relationships? Any prior chargebacks or disputes?
- Personal guarantees. Are the principals creditworthy? Are they in jurisdictions you can pursue?
- Geographic risk. Where is the business operating? Where are the customers? Cross-border patterns can flag fraud.
Each platform has its own risk appetite. A bank-backed processor (e.g., FIS, Worldpay) will be conservative. A modern PSP (Stripe, Adyen) is more permissive but charges accordingly. A specialized platform (cannabis-focused, high-risk-focused) operates in segments others won't touch.
The mistake I see often: under-investing in the underwriting model. Treating it as a checklist that any operations person can run, rather than as a domain that requires expertise. Result: false rejections (good merchants turned away) and false acceptances (bad merchants who later default or commit fraud, costing the platform real money in chargebacks and processor fines).
The better model: treat underwriting as a discipline. Hire people who've done it elsewhere. Invest in tooling — a proper underwriting workbench that surfaces all relevant data, not a spreadsheet. Build feedback loops from chargebacks and account closures back to the underwriting decisions that approved those accounts. Tune the model over time.
Bank account verification is harder than it looks
The merchant's settlement account is where the platform deposits their funds. Verifying it isn't just "did the routing number and account number look valid?" It's also "does the merchant actually own this account?"
Methods:
Micro-deposits. The classic approach: deposit two random amounts under $1, ask the merchant to confirm them. Takes 1–3 business days. Reliable but slow.
Plaid (or equivalent) account linking. Merchant logs into their bank through Plaid, the platform gets verified ownership. Fast (minutes), more friction for the merchant (they have to provide bank credentials), and adds a vendor cost.
Bank statement upload. Merchant uploads a recent statement, automation extracts account ownership. Faster than micro-deposits, slower than Plaid, less reliable in detecting fraud (statements can be doctored).
The right answer is usually a combination: offer Plaid as the primary path, fall back to micro-deposits for merchants who don't want to share credentials, accept bank statements as a third option for edge cases. Make it easy for the merchant to choose.
The failure mode I've seen: requiring micro-deposits for all merchants because the platform team didn't want to integrate Plaid. Result: 5–10% of merchants drop out during the wait. That's a measurable revenue loss attributable to a single vendor decision.
The "underwriting → activation" pipeline
Once a merchant is approved, they need to be activated in the underlying processor. This is mechanical work, but it's where I see surprising amounts of failure.
The flow:
- Underwriter approves the merchant, sets fee schedule and limits.
- Platform calls processor's "create merchant" API with collected info.
- Processor returns a merchant ID (MID).
- Platform configures the MID with payment methods, fees, settlement preferences.
- Platform configures any custom risk rules, fraud thresholds.
- Platform sets up the webhook endpoints for this merchant.
- Platform notifies merchant they're ready, sends them production credentials.
Each API call to the processor can fail. The processor might reject the merchant (their underwriting overrides yours, in some processor models). The MID creation might succeed but the configuration call fails, leaving an orphaned half-configured account. The webhook setup might succeed but the secret isn't stored properly.
Each of these failures has a recovery path that the platform must implement. The recovery often involves manual operations work (opening a ticket with the processor, asking them to delete the orphaned MID). If recovery isn't built, the operations team accumulates a backlog of half-onboarded merchants that someone has to clean up manually.
The platform with mature onboarding has all of this scripted, with retries, with idempotent operations, with rollback procedures, with alerting on failure. The platform without this has a Slack channel where ops people manually track which merchants are stuck and where.
The compliance load that doesn't go away
KYC isn't a one-time event. Periodically (typically annually for higher-risk merchants), you have to re-verify. New beneficial owners need to be added when ownership changes. New legal entities need to be added when the merchant restructures. New geographies trigger additional checks.
The platform has to build for ongoing compliance, not just initial onboarding:
- Periodic KYC refresh, automated where possible.
- Change-management for merchant records (when documents update, when ownership changes).
- Sanctions screening that runs continuously, not just at onboarding.
- Adverse media monitoring that flags news mentions of merchant principals.
- Regulatory reporting (SAR — Suspicious Activity Reports — when triggered).
This is operational infrastructure, not a one-time project. Underestimating its ongoing cost is a common mistake. The platform that gets onboarding right but never invests in re-verification ends up with a compliance backlog that grows as the merchant base grows.
Multi-country complications
Onboarding gets dramatically harder if the platform serves multiple countries. Each country has its own regulatory regime, its own KYC requirements, its own document types, its own bank verification systems, its own underwriting norms.
US: SSN/EIN, articles of incorporation, beneficial ownership disclosure under FinCEN rules. EU: VAT numbers, ID cards or passports, beneficial owners under AML directives, GDPR for data handling. UK: Companies House lookup, identity verification, prevention of money laundering rules. Canada: SIN, business numbers, FINTRAC requirements. Australia: ABN, AUSTRAC requirements. Singapore: UEN, MAS guidelines.
Each country also has different bank verification mechanisms. Plaid covers the US well, less so elsewhere. There are regional alternatives (TrueLayer in Europe, Stitch in Africa) but managing them all adds complexity.
The platforms that scale internationally either build deep country-specific onboarding flows (expensive, slow, comprehensive) or partner with onboarding-as-a-service vendors (Sumsub, Footprint, etc.) that abstract over the regional variation. Either way, the cost of multi-country expansion is heavily concentrated in onboarding.
The "fast track" temptation
There's always pressure to make onboarding faster. The merchant wants to start processing today. Sales wants to close the deal. Engineering wants to ship the integration quickly. Compliance wants to do their job carefully. Operations wants to clear the queue.
Some of these are legitimate (genuine merchants whose flows hit edge cases that bottleneck them). Some are not (sales pushing to bypass underwriting on a marginal merchant because the deal is big).
The platforms that hold the line do better long-term. The platforms that fast-track everything end up with worse risk profiles, more chargebacks, more processor pressure, and eventually higher fees passed back to all their merchants. Risk that gets onboarded too quickly comes due later.
That said, there are legitimate ways to speed onboarding:
- Pre-approval for known business types with clean profiles.
- Tiered limits — low initial limits with quick onboarding, higher limits after history is established.
- Risk-based document collection — fewer docs for lower-risk merchants.
- Better automation — every minute of manual review removed is a minute of latency saved.
These all involve genuine risk management, not just bypassing controls. The art is in distinguishing speed-from-better-process versus speed-from-cutting-corners.
The activation experience
Once the merchant is approved and configured, the experience of going live still matters. Common stumbling blocks:
- The merchant doesn't know what to test in sandbox before going live.
- Their first live transaction fails for a configuration reason and they don't know what to do.
- Their settlement schedule isn't what they expected.
- Their first chargeback arrives and they have no playbook.
- Their reporting doesn't show what they expected.
Each of these is a moment where the merchant might churn or open a support ticket that costs you time. Investing in activation guides, sample integrations, sandbox-to-live checklists, and proactive outreach in the first week pays back many times over in reduced support load and higher activation rates.
The platform with mature activation has a defined "first 30 days" experience: scheduled check-ins, defined success metrics (first transaction, first $1K processed, first day above target volume), proactive intervention when a merchant looks stuck. The platform without this has a website that says "you're approved, here are your credentials, good luck."
What the data tells you
If you're running a payment platform and you want to know how onboarding is going, these are the metrics that matter:
- Time from signup to first transaction. The single best summary metric. Should be hours for low-risk merchants, days for typical, weeks for complex.
- Drop-off rate at each onboarding step. Where are merchants giving up? That's where the friction is.
- Auto-approval rate. What percentage of merchants make it through without human review? Higher is better, until it gets too high and risk profile suffers.
- Time in manual review queue. How long do merchants wait when they need a human?
- First-30-days activation rate. Of approved merchants, what percentage actually start processing volume?
- First-90-days retention. Of activated merchants, what percentage are still processing in 90 days?
- Chargeback rate by onboarding cohort. Which cohorts had the highest chargebacks? Trace back to the underwriting decisions.
If you don't measure these, you don't know whether your onboarding is working. Most platforms don't measure them rigorously, which is why most platforms have onboarding problems they don't fully understand.
What I'd build differently
If I'm building a payment platform from scratch today, I treat onboarding as a first-class product with its own engineering team, not as an operations afterthought. The team owns:
- The merchant-facing onboarding flow (a real product, not a form).
- The internal underwriting workbench.
- The integrations with KYC/KYB vendors, bank verification services, and the processor's onboarding APIs.
- The operational runbooks and tooling for manual review.
- The compliance refresh and change-management workflows.
- The activation experience and first-30-days success metrics.
This is a meaningful investment. For a Series A platform, it might be one of the larger engineering investments. For a Series B platform, it's the team that scales fastest as merchant volume grows.
The alternative — onboarding as something the existing engineering team handles in their spare time, with operations doing manual review on the side — is what most platforms do. And it's why most platforms have onboarding measured in days or weeks when it could be hours.
The harder truth
Onboarding is the most undervalued part of payment platforms. Investors don't ask about it. Tech blogs don't write about it. Engineers don't dream about working on it. And yet it's the gating factor for nearly every customer relationship.
The platforms that win are the ones that take onboarding seriously: hire for it, invest in it, measure it, treat it as a competitive differentiator. Stripe famously did this with Atlas (incorporation as part of onboarding), with auto-fill for known business patterns, and with friction reduction at every step. Their onboarding was a moat as real as their API quality.
The platforms that lose are the ones who think onboarding is just compliance paperwork. They ship a beautiful API, build great analytics, and then wonder why their conversion rate from signup to first transaction is 25% while a competitor's is 80%.
Onboarding is product. Build it like one.
This is part of a series on payment systems architecture. See also the real cost of payment integration nobody talks about and PCI compliance shapes payment architecture.