Payment Facilitator Platform: Custom Build or Stripe Connect and Adyen for Platforms
Buy. Under roughly $10 million in annual card volume, Stripe Connect or Adyen for Platforms gets you live in weeks and absorbs compliance you are not ready to carry.
On this page
Buy. Under roughly $10 million in annual card volume, Stripe Connect or Adyen for Platforms gets you live in weeks and absorbs compliance you are not ready to carry. Build your own facilitator layer when payments are a top two revenue line, when payout timing is a competitive weapon, and when the platform keeps holding merchants your own data says are fine.
What the off-the-shelf platforms actually do well
Nobody in vertical software should start by building this, and the products that exist are the reason why.
Stripe Connect and Adyen for Platforms both onboard a sub merchant, verify the business, run sanctions screening, take the card, compute a split and pay out, and they do it in weeks rather than quarters. Behind that sits a licensing and registration posture you do not have, an acquiring relationship you have not negotiated, and a risk team watching a population far larger than yours. Payrix and Finix sit a step closer to the money for operators who want more control and are willing to accept more of the responsibility, which is a real and useful middle. Infinicept is strong on the programme side, the registration, the policies and the acquirer relationship, which is genuine work most software companies would otherwise do badly.
Be clear about what you are renting. You are renting an underwriting decision, a funds flow and an obligation to answer to a card network. At early volume that is a bargain even at a fat revenue share, because the alternative is hiring a risk analyst before you have hired a second engineer.
Most vertical software companies reading this should stay exactly where they are, and we say that to prospects regularly.
Where they stop: the payout timing decision is yours and they will not take it
Computing a split is easy. Ninety seven percent to the sub merchant, two and a half to you, the remainder is processing. The difficulty is when.
In home services a homeowner pays a deposit on Monday for work scheduled in three weeks. Pay the contractor Tuesday and you own the chargeback if nobody shows up. Hold the deposit for three weeks and your best contractors leave for a competitor paying next day. The correct answer sits between those two and depends on that contractor's history with you, the job value, and whether you have any signal that the work happened. That logic is your risk appetite expressed as code, and no processor will let you express it, because they price for a generic distribution of platforms rather than for your vertical.
The same gap shows up at onboarding. In your vertical a two year old business with a $40,000 average ticket is ordinary. In a general model it looks like fraud. You cannot tell a platform risk engine that your customers take deposits six months before delivering, which is precisely the pattern the engine treats as a red flag. So good merchants get held, support escalates, and you have a churn problem code cannot fix.
Third gap: the ledger. Platform balances are per processor. The day you add a second acquirer, a bank rail or an instant payout option, no vendor balance can see the whole picture, so none of them can be your source of truth. What you need is double entry with immutable postings and accounts for every pot that exists, funds in transit, available and pending balance per sub merchant, reserve held, platform fee revenue, chargeback liability and negative balance owed. A payouts table with a status column survives until the first partial refund on an already settled transaction, then somebody posts a negative row and the books never tie again.
The arithmetic: basis points against build cost
This one resolves to a single calculation and you can do it before anyone quotes you.
Take your annual card volume. Multiply by the basis points you believe you would recover by moving from a platform revenue share to a direct acquiring relationship. Subtract the risk losses you would then carry yourself, which is the number most spreadsheets omit, and subtract the fully loaded cost of the people who watch them, which in practice is one risk analyst before you reach any real scale.
Now the crossover. At $10 million of annual volume, a recovery of 30 basis points is $30,000 a year, and no build clears that. At $50 million the same recovery is $150,000 a year and a first release pays for itself inside the first year. At $100 million and above the arithmetic stops being close. The other axis is sub merchant count: below about 500 active sub merchants, manual risk review is cheap and a build is mostly ceremony. Above roughly 2,000, review volume forces you to encode the decision anyway, and encoding it inside your own system costs less than escalating it through somebody else's.
One cost nobody quotes at renewal: platform revenue shares are typically expressed against volume, so the fee scales with exactly the thing your business is trying to grow. Model your renewal at double today's volume before you sign, not after.
What a custom build actually costs
From Digital Heroes delivery experience, a first release covering sub merchant onboarding with know your business decisioning, a 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, marketplace tax reporting and a second processor runs $220,000 to $550,000 phased over 8 to 15 months.
Migration runs 10 to 25 percent of first release cost, and here it means moving live sub merchants rather than rows. Every merchant needs a bank account re verified, a reserve position carried across correctly and a payout schedule that does not skip a cycle during cutover. Expect to run both systems in parallel for at least two full payout cycles and compare every line. Year two costs 15 to 20 percent of build cost annually, covering processor file format changes, card network rule updates that arrive twice a year, and the reconciliation edge cases that only appear at volume.
What pushes cost up: multi processor support, because a second acquirer means a second set of file formats and edge cases rather than a configuration change; automated clearing house alongside cards, since Nacha returns arrive days later and change the funding model; instant payouts, which need a real time risk check; and marketplace tax reporting, which is tedious rather than hard and always takes longer than planned.
The four situations where building wins
Regulatory fit. Payment Card Industry Data Security Standard 4.0 requirements became mandatory in March 2025, and your scope stays small only if card data never touches your infrastructure. Card network rules require a sub merchant above roughly a million dollars in annual card volume to hold a direct agreement with the acquirer, so your platform has to support two contractual shapes at once. Add sanctions screening on businesses and beneficial owners, and marketplace reporting on Form 1099-K. Confirm current thresholds with your acquirer rather than a blog post.
Scale economics. Past roughly $50 million in annual card volume the basis points recovered exceed the build and the risk team together, and the gap widens every year you grow.
A workflow that is your competitive advantage. Payout timing and reserve policy are the only two levers that make you materially different from every other platform in your vertical. If next day funding for proven contractors is part of your sales pitch, that logic belongs in software you own rather than in a support ticket asking a processor to make an exception.
Integration sprawl. Count what must agree: the processor, the settlement file, the bank, a business verification vendor, your ledger, the disputes queue and tax reporting. Once three or more must reconcile on the same sub merchant balance, the reconciliation is the product, and renting the middle of it is the arrangement that ages worst.
How to decide in a week
Take one month of settlement and try to explain it to the cent.
Pull last month's daily funding advices from your processor and your bank statement. For each funding day, reconstruct the number: gross captures, refunds, interchange and scheme fees, adjustments, reserve movements, and your platform fee. Where the two disagree, name the transactions responsible. Give this to your controller and one engineer with a deadline of three working days.
The result is the decision. If every day ties within a few dollars and the differences have names, your funds flow is under control and you should stay on the platform you have. If there is a four figure gap nobody can attribute, that gap is not an accounting problem, it is a missing ledger, and it will grow with volume rather than settle.
Second test, one hour: list every merchant the platform held or declined in the last quarter that your own data says was fine, and add up the annual revenue they represent. That number is the cost of renting somebody else's underwriting.
Then run a paid discovery of two to three weeks ending in a signed product requirements document covering the account tree, the underwriting rules, reserve and payout policy, the settlement reconciliation model and acceptance criteria. Digital Heroes writes that specification before code and you keep it either way, which is also the fastest way to find out whether your other quotes priced the same thing.
Who we are wrong for: a company that wants somebody else to hold the licence, the risk and the acquirer relationship. That is a legitimate choice and it points at Stripe, Adyen or Infinicept, not at a development firm. Digital Heroes builds and hands over: more than fifty specialists, over 2,000 projects, India LLP, US LLC and UK LTD entities so ownership assigns under your own law, and a named team you meet first. Verify on Clutch, Trustpilot, Fiverr Vetted Pro and D-U-N-S.
Book a 30-minute call with Digital Heroes and get a written plan and a fixed quote within 48 hours.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey found that tech debt can amount to 20-40% of the value of a company's entire technology estate before depreciation, and CIOs report that 10-20% of the budget for new products is diverted to resolving tech-debt issues. Source: McKinsey & Company (2020) →
- The right combination of digital transformation actions can unlock as much as US$1.25 trillion in additional market capitalization across Fortune 500 companies, while the wrong combinations put more than US$1.5 trillion at risk; companies with all three core factors (strategy, aligned technology, and change capability) saw a 5% market-value lift relative to peers. Source: Deloitte (2023) →
- Brandon Hall Group research on onboarding reports that done well, structured onboarding drives measurable gains in new-hire productivity, employee engagement, and retention; the page notes 41% of organizations experience greater than 5% turnover among new hires. Source: Brandon Hall Group (2024) →
- Gallup reports global employee engagement fell to 20% in 2025 (its lowest since 2020, down from a 2022-2023 peak of 23%), and estimates low engagement costs the world economy an estimated $10 trillion in lost productivity, or 9% of global GDP. (Note: this figure appears in Gallup's evergreen State of the Global Workplace page, currently reflecting the 2026 edition reporting on 2025 data.). Source: Gallup (2025) →
Frequently asked questions
How much does it cost to build a payment facilitator platform?
A first release with sub merchant onboarding, business verification decisioning, a double entry ledger, split settlement and payouts on one processor runs $80,000 to $180,000 and ships in 12 to 18 weeks in Digital Heroes delivery experience. A full platform adding reserves, chargebacks, settlement reconciliation, tax reporting and a second processor runs $220,000 to $550,000 over 8 to 15 months. Multi processor support and bank transfers move the number most.
At what volume does becoming your own facilitator start to pay?
Run the basis point calculation on your own numbers. At ten million dollars of annual card volume, recovering thirty basis points is thirty thousand dollars a year and no build clears that. At fifty million the same recovery funds a first release inside twelve months, and above a hundred million the arithmetic stops being close. Subtract the risk losses you would carry directly and the salary of the analyst who watches them.
What is the difference between a payment facilitator and a marketplace on Stripe Connect?
On Connect, Stripe holds the acquiring relationship and makes the underwriting decision while you configure splits. As a facilitator you take on sub merchant underwriting, its evidence trail, funds you do not own, and answerability to the card networks through your acquirer. The software difference is a real ledger with reserve and negative balance accounts. The commercial difference is that margin and risk both move onto your books.
How long does it take to migrate sub merchants off a platform account?
Twelve to eighteen weeks for the first release, with migration adding ten to twenty five percent on top. The slow part is not code. Every live sub merchant needs its bank account re verified, its reserve position carried across accurately and a payout schedule that does not skip a cycle. Run both systems in parallel for at least two complete payout cycles and compare every line before cutting over.
Who owns the underwriting rules if an agency builds our payments platform?
You should, along with the repository and the cloud accounts, agreed in writing before kickoff. Underwriting rules and payout logic are the accumulated risk policy of the payments business you are building, and a developer holding them in a proprietary format has taken custody of your margin. Digital Heroes assigns everything from the first commit, and hesitation on that question from any firm should be treated as disqualifying.
What happens if a sub merchant refunds more than their balance and disappears?
You carry the loss unless you planned for it, which is why reserves and negative balance recovery belong in the first design rather than a later phase. Recovery means debiting future settlement, debiting their bank account by prior agreement, or writing it off. Model both reserve and negative balance as real ledger accounts with scheduled postings, not as background jobs that might run twice and double credit a release.
Can we keep Stripe as the processor and still own the ledger?
Yes, and it is often the right first phase. Keep the acquiring relationship where it is, build the double entry ledger and payout engine in house, and demote the processor to an event source. That gets you an authoritative balance per sub merchant, defensible payout maths and clean reconciliation without touching your compliance posture. Adding a second processor later then becomes an adapter rather than a rebuild of the funds model.
Do we need a double entry ledger or is a payouts table enough?
You need double entry. A payouts table with a status column works until the first partial refund on a transaction already paid out, at which point somebody writes a negative row and reconciliation is never clean again. Model funds in transit, available and pending balances per sub merchant, reserves, platform fee revenue, chargeback liability and negative balances as accounts, with every processor event recorded as an immutable posting.
What compliance obligations come with running your own facilitator layer?
Sub merchant underwriting with a defensible evidence trail, sanctions screening on businesses and beneficial owners at onboarding and on a cycle, data security obligations that stay small only if card data never touches your systems, marketplace tax reporting, and registration with the card networks through your acquirer. Network rules also require larger sub merchants to hold direct agreements. Confirm current thresholds and screening expectations with your acquirer rather than a published summary.
What should we budget for the second year after launch?
Fifteen to twenty percent of build cost annually. That covers processor file format changes, card network rule updates that arrive on a regular cycle, reconciliation edge cases that only appear at volume, and support during settlement windows. If you add a second acquirer or a new payout rail in year two, treat that as new scope rather than maintenance, because each one brings its own file grammar and its own return codes.
What should I have ready before I contact a development agency?
Three things, none of them technical: a one-page description of the problem in your own words, a list of the tools and spreadsheets the new system must replace or connect to, and a must-have versus nice-to-have split of features. Add a budget range, even a wide one, because it changes the conversation from fantasy to engineering. You do not need a formal specification; producing that is what a discovery phase is for.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
If an agency builds my software, who actually owns the code?
You should own everything, assigned in writing: the contract transfers full IP to you on final payment, the code lives in your GitHub organization, and hosting runs in cloud accounts you control. The red flag is a proposal that mentions the agency's proprietary platform or framework, which usually means you are renting, not buying. Digital Heroes structures every build this way precisely so a client can fire us and lose nothing but the relationship.
Should we build an MVP first or go straight to the full system?
MVP first, for almost everyone: ship the single workflow that carries the business value in 10 to 16 weeks, learn from real users, then fund phase two from evidence instead of guesses. The caveat is that an MVP is a small version of a well-built system, not a badly built version of a big one; the data model must already support what comes next. An agency that cannot tell you what they deliberately left out of your MVP has not designed one.
We run everything on spreadsheets and Airtable. How do we know it's time for custom software?
The reliable signals are re-typing the same data into multiple tools, one employee acting as human middleware between systems, and errors appearing in handoffs between teams. Hard limits force the issue too: Airtable's Team plan caps at 50,000 records per base, and Business costs $45 per seat per month, so a 20-person team pays about $10,800 a year for a tool it has already outgrown. When workarounds consume more hours than the tools save, the spreadsheet era is over.
How do I make sure custom software is secure and compliant with rules like HIPAA?
Start with the baseline every business system should have: encryption in transit and at rest, role-based access control, and audit logs. If HIPAA applies, the hosting provider must sign a Business Associate Agreement, which AWS, Azure, and Google Cloud all offer, and access controls have to be designed in from day one, not bolted on. SOC 2 certifies a company's operating practices, not a codebase, so ask vendors what they have shipped in your regulated domain rather than which logos are on their website.
What happens if I stop paying for maintenance after launch?
Nothing breaks on day one, which is what makes it dangerous. Within 6 to 18 months, unpatched dependencies accumulate known vulnerabilities, an integrated API like Stripe ships a breaking change, and the first fix requires a developer to relearn a stale codebase at full price. Budget 15 to 20% of the build cost per year for upkeep; it is the difference between a $500 patch and a $15,000 emergency.
If we build for 20 users now, will the software cope with 500 later?
It should, without a rewrite, if it was built on a standard cloud stack; going from 20 to 500 users is mostly a hosting configuration change costing hundreds a month, not a second project. What actually breaks under growth is sloppier work: database queries never indexed for volume and features designed assuming one office's worth of data. Before signing, ask the vendor what happens to the system at ten times today's data, and listen for a specific answer.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
Who can build a custom software system?
Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other software companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
Related guides
Published · Last updated .
