Payment Facilitator Platforms: Why Sub Merchant Payouts Stop Matching the Acquirer File

Why becoming the facilitator changes what software you need

The day payments stop being a feature and become the business is the day your reporting breaks. Up to that point a platform account and a spreadsheet were fine: money came in, the provider took its cut, your sub merchants got paid, and the residual landed monthly. Then volume grows, the finance team starts asking why the deposit on the fifteenth was $412,880 when the sum of that day's sub merchant payouts plus your fee should have been $413,140, and nobody can trace the $260. It is interchange downgrades on nine transactions, one refund that crossed a settlement boundary, and a rolling reserve release that hit a different day than expected. Three people spend a week on it and the same gap appears the following month.

That is the honest trigger for this build. A facilitator is not running a checkout. It is running a small bank inside a software company: it underwrites merchants, it holds funds it does not own, it decides when someone gets paid, it carries loss when a sub merchant refunds a customer and disappears, and it has to prove all of it to an acquirer and to the IRS. None of that is a payments integration. It is a ledger with a risk policy attached.

Problem one: onboarding is a decision, not a form

Your sub merchant is a roofing contractor, a dental practice, a youth sports league or a freight broker depending on your vertical. KYB means collecting the legal entity, the EIN, beneficial owners at the ownership threshold your policy sets, a bank account to pay out to, and enough about the business to price its risk. Then someone decides: approve, approve with a reserve, approve with a volume cap, or decline.

Stripe Connect and Adyen for Platforms both do this well and fast, and if you are early you should absolutely use them. What you give up is the decision itself. Their risk model is tuned for the whole population of platforms on their network, not for the fact that in your vertical a two year old business with a $40,000 average ticket is normal and unremarkable, while in a general model it looks like fraud. You cannot tell them that your customers take deposits six months before delivering, which is exactly the pattern their model treats as a red flag. So your merchants get held, your support team escalates, and you have a churn problem you cannot fix with code.

What a custom build does: an underwriting decision engine where the rules are yours and written down. Entity verification and OFAC screening on the business and the beneficial owners at onboarding and on a recurring cycle. Automatic approval for the profile that makes up most of your book, a manual queue for the rest, and every decision stored with the data it was made on, because when your acquirer audits the program they will pull twenty files and ask why each was approved. Document extraction earns its place here: bank letters, EIN confirmation letters and formation documents arrive as photographs of paper, and a structured extraction pass with a human confirm step turns a three day onboarding into a same day one.

Problem two: the split is the easy part, the timing is the hard part

Everyone can compute a split. Ninety seven percent to the sub merchant, two and a half to you, the rest is processing. The difficulty is when.

In a home services vertical a customer pays a deposit on Monday for work scheduled in three weeks. If you pay the contractor Tuesday and they never show up, you own the chargeback. If you hold the deposit for three weeks, your best contractors leave for a competitor who pays next day. The correct answer sits between those and depends on the contractor's history, the job value, and whether you have any signal that the work happened. That logic is your risk appetite expressed as code, and it is the single most valuable thing in the platform. It is also the thing no processor will let you express, because they price for a generic distribution of platforms.

Payrix and Finix exist precisely for operators who want to get closer to the money and are willing to accept more of the responsibility, and they are reasonable choices. Infinicept is strong on the program side, the registration, the policies, the acquirer relationship, which is genuine work you would otherwise do badly. In each case the vertical specific payout logic, the reserve schedule and the ledger that ties it together still land on your engineering team. That is what you are actually budgeting for.

Problem three: your ledger has to be a ledger

The failure we see most often is a payouts table with a status column. It works until the first partial refund on a transaction that has already been paid out, at which point somebody writes a negative row and the reconciliation is never clean again.

What a custom build does: double entry, immutable postings, and accounts for every pot of money that exists. Funds in transit from the processor. Each sub merchant's available balance and pending balance. Reserve held per sub merchant, with the release schedule as postings rather than a cron job that occasionally runs twice. Platform fee revenue. Chargeback liability. Negative balance owed by a sub merchant who refunded more than they took. Every processor event, every payout, every fee and every reserve movement becomes a posting, and the balance of the settlement account should equal what the bank says it is, to the cent, every day. If it does not, the difference is a break with a transaction attached, not a mystery.

Problem four: acquirer files do not agree with your API events

Your processor's API tells you a charge succeeded. The daily settlement file tells you what actually funded, net of interchange, scheme fees, downgrades and adjustments, on a date that is not the date of the charge. Those two views never line up on their own. Interchange qualification changes a transaction's cost after the fact. A dispute reverses funds days later. A monthly fee lands as one lump you have to allocate across thousands of sub merchants to know your true margin.

Build the reconciliation as a first class module, not a report. Ingest the settlement file, match at transaction level, classify every unmatched item into a bucket that a human can act on, and hold the breaks until they are cleared rather than netting them away. The margin report that comes out the other end is the first honest answer you will have to the question of which sub merchant segments actually make money after their disputes and their downgrades.

What it costs and how long it takes

A first release, meaning onboarding with KYB decisioning, the double entry ledger, split settlement and payouts against a single processor, runs $80,000 to $180,000 and ships in 12 to 18 weeks. A full platform adding reserves and negative balance recovery, chargeback intake and representment routing, settlement file reconciliation, 1099-K reporting and a second processor runs $220,000 to $550,000 phased over 8 to 15 months.

What pushes cost up in this category: multi processor support, because a second acquirer means a second set of file formats and a second set of edge cases, not a config change. ACH alongside cards, since Nacha returns arrive days later and change the funding model. Instant payout options, which need a real time risk check. Card network rules that require a sub merchant above roughly a million dollars in annual card volume to hold a direct agreement, which means your platform has to support two contractual shapes at once. PCI scope, which you keep small by never touching card data and letting the processor tokenise. And marketplace tax reporting, which is tedious rather than hard and always takes longer than anyone plans.

Build versus buy, stated plainly

Buy, and do not let anyone talk you out of it, if you are under roughly $10M in annual card volume. Stripe Connect and Adyen for Platforms will get you live in weeks, absorb compliance you are not ready for, and cost you margin you can afford to lose while you are still proving the vertical.

Build when two or more of these are true. Payments are a top two revenue line and the take rate is your P&L. Your payout timing is a competitive weapon and the platform will not let you set it. You are being declined or held on merchants your own data says are fine. You need funds flow shapes the platform does not model, such as milestone releases, escrow style holds, trust accounting or multi party splits with a third party lender in the chain. Or the reconciliation gap has stopped being an annoyance and started being an audit finding.

How to choose a developer for a facilitator build

Ask them to draw the ledger before anything else. If the first diagram has a payouts table with a status column, stop. If it has accounts, postings and a settlement account that must tie to the bank daily, keep talking.

Ask what happens to a refund issued after payout on a sub merchant with a zero balance. The answer tells you whether they have run one of these before. Negative balance recovery is the least glamorous part of the platform and the part that decides whether you lose money.

Ask specifically which settlement files they have parsed and reconciled, by processor name. Building against an API is a different skill from reconciling a daily funding file with interchange detail, and only one of those keeps your controller calm.

Ask who owns the code, the underwriting rules and the cloud accounts, and put it in the contract before kickoff. Your underwriting policy and payout logic are the intellectual property of the payments business you are building. At Digital Heroes the client owns all of it from the first commit, and any developer who hesitates is proposing themselves as a permanent dependency.