Recently updated on September 30, 2026
A sub-merchant portal is a self-service interface that lets sellers, service providers, and other businesses operating under a payment platform manage their own onboarding, transactions, balances, payouts, disputes, and payment account information. It is the screen the seller logs into, sitting one layer above the infrastructure that does the processing.
The arrangement it sits on is standard in card acceptance. Visa describes a payment facilitator as a third-party agent that signs a merchant acceptance contract on behalf of an acquirer and receives and distributes settlement proceeds on behalf of its sponsored merchants. Platforms tend to call that same party a sub-merchant. The seller needs somewhere to see their money.
Below: what a sub-merchant portal does, the features it needs, how it differs from a platform admin portal, and which businesses end up building one.
A sub-merchant is a business that accepts payments under another company’s acquiring relationship. Take a hair salon booking clients through a scheduling app: the acquiring contract belongs to the platform behind the app.
Four roles sit in the chain.
| Role | Who it is | What it does |
|---|---|---|
| Acquirer / PSP | Bank or payment service provider | Holds the licence, processes card transactions, settles funds |
| Payment platform | Marketplace, SaaS platform, PayFac or ISV | Onboards sellers, owns the commercial relationship, directs payouts |
| Sub-merchant | Seller, vendor, contractor or service provider | Sells goods or services, accepts payments, receives payouts |
| End customer | Buyer or payer | Pays for the goods or services |
A standard merchant contracts directly with an acquirer and holds its own merchant ID. A sub-merchant contracts with the platform, processes under the platform’s arrangement, and looks to that platform for onboarding, verification and payouts.
The distinction carries commercial and legal weight. Visa notes that all merchant requirements apply equally to a sponsored merchant, and that the acquirer remains responsible for the acts of both the facilitator and the sellers underneath it. The platform inherits obligations it then has to operationalise, and the portal is where that work becomes visible to the seller.
A sub-merchant portal is the UI layer between payment infrastructure and the seller. Checking a balance, chasing a payout, exporting a statement, contesting a chargeback, updating a bank account: all of it happens there, under the platform’s brand.
The chain runs in one direction:
PSP or acquirer → payment platform → sub-merchant portal → seller
The PSP processes and settles. The platform holds the relationship and the configuration, and the portal renders both for the seller. Some teams write the term without the hyphen; a sub merchant portal is the same product.
Authorisation, custody of funds, and settlement stay with the payment infrastructure. The portal reads state from it and writes instructions back. A seller clicks refund; the portal calls an API; the processor moves the money.
That separation is what makes a portal buildable. You are writing screens and permissions over an existing ledger. It also fixes what the portal owns: presenting state accurately and leaving balances to the ledger that holds them.
A platform usually ends up running two of these: one for sub-merchants, one for its own payment operations team.
The lifecycle runs from invitation to steady-state operations. Each stage maps to a different part of the portal.
The platform invites a seller, who creates an account and submits business information: legal entity, trading name, category, expected volume, website. Adyen’s platform model calls this record an account holder and hangs the legal entities and balance accounts off it. The portal’s job here is to collect each fact once.
Next comes verification: company registration data, beneficial owners, director identity documents, and bank account ownership. Under the EU’s Anti-Money Laundering Regulation, which applies from July 2027, obliged entities must identify the customer and take reasonable steps to identify beneficial owners before the relationship starts.
The portal surfaces what is outstanding, what failed, and what to upload. This shapes how long the KYC process takes.
Once checks pass, processing and payout capabilities switch on. Some providers stagger this: a seller can take payments at a low tier while fuller verification completes, with payouts gated until it does.
The portal shows the current tier, its limits, and the reason behind any held payout.
Then it is in a steady state: transactions, balances, payouts, statements, refunds, and disputes, indefinitely. Onboarding happens once. Everything after it repeats.
Seven areas cover what sellers open a merchant portal to do.
Sub-merchant onboarding is the first screen a seller sees. It carries the application status and the outstanding requirements in plain language.
There is also a way to upload a document and have the format checked right away, as well as a way to respond to calls for more information.
When a check fails, the portal names which one and says what to do next, so the seller knows which document to send.
A searchable transaction list with filters on date, amount, status, payment method, and reference. Each transaction shows its status, the fees deducted, and its settlement state.
This screen is driven by a single question: did this particular payment arrive? Whether the portal responds depends on search speed and reference fields that correspond to the seller’s own order system.
Refund initiation belongs here too, with partial refunds and a visible refund status.
Available balance, pending balance, and the reason funds are held. Then merchant payouts: history, amounts, status, expected arrival, and the bank account each one went to.
Sellers add and verify bank accounts themselves.
Holds and reserves carry a stated reason next to the adjusted number, which answers the seller’s question where it arises.
Merchant transaction reporting means statements per period, fee breakdowns, and exports in formats an accountant can use. CSV covers most of it, alongside a settlement file that ties each payout back to the transactions inside it.
Payment reconciliation is the job the seller is doing with this data. The export format decides how much of it they can finish alone.
Chargebacks arrive with a scheme deadline attached. That deadline, the dispute cause code, a guided evidence upload, and the case’s current status are all displayed on the portal for a seller on a platform.
Each dispute carries a response window set by the scheme. We surface those deadlines on the seller’s landing view and back them with email prompts.
Some platforms layer fraud scoring on top to reduce the inbound volume.
Merchant account management covers company information, trading details, multiple locations or outlets, payout bank details, and users with roles. A restaurant group running several sites needs per-site reporting alongside a consolidated view.
Role-based access matters here: the owner sees payouts while the shift manager sees transactions only.
KYC and KYB status, periodic re-verification prompts, and PCI DSS attestation where it applies.
The PCI Security Standards Council is explicit that outsourcing payment processing leaves a merchant responsible for ensuring account data is properly protected. Sellers have their own responsibilities, and the portal is a useful tool for bringing these to light prior to an annual deadline.
These are two products sharing one data model. The sub-merchant portal covers a single seller; the admin portal, the merchant management portal your own team uses, spans every seller on the platform.
| Area | Sub-merchant portal | Platform admin portal |
|---|---|---|
| Scope | One merchant | All merchants |
| Transactions | Its own | Platform-wide |
| Payouts | Its own history | Payout oversight and control |
| Disputes | Its own cases | All cases, with SLA tracking |
| Onboarding | Submit and track | Review, approve, reject |
| Account | Self-service edits | Sub-merchant management, limits, suspension |
| Purpose | Self-service | Operations, risk, and control |
Permissions carry practical consequences. The sub-merchant portal scopes every query to one account holder, and the server enforces that scope on each request. The admin portal leaves queries unscoped by default and gates them by staff role.
We usually build both on one API, with a separate authorisation context for each. Separating them later can mean reworking the authorisation layer, which is one of the things software audits tend to surface.
If your platform onboards businesses and moves money to them, the question is how much portal you need and when. Four business models reach that point.
A marketplace merchant portal gives each seller their own view of sales, earnings and payout dates. Spreadsheets and emailed statements cover the same ground for a handful of sellers.
Catalogue and order management usually live in the same marketplace seller portal. The payments view tends to arrive second, onto a data model already shaped around orders.
Restaurant, healthcare, hospitality, salon, and field-service platforms embed payments into software that already handles bookings, jobs or appointments. For these platforms the payment merchant portal usually opens as a tab inside that product.
That placement sets the design brief. The portal borrows the layout, labels and typography of the screens around it, and the seller stays in one application throughout.
A payment facilitator portal is the PayFac’s primary customer-facing product. At thousands of sponsored merchants, self-service carries the account questions that would otherwise arrive one at a time.
Underwriting, monitoring and merchant reserves each need a portal surface. Visa’s risk guide for facilitators and marketplaces spells out what those controls cover, and the portal is where a PayFac’s team runs them day to day.
An ISV here is a software vendor that takes a share of the payments running through its product. That places it between the two models above: more payment revenue than a plain vertical SaaS platform, lighter operational load than a PayFac.
Most begin by sending sellers to the PSP’s own dashboard, which arrives with the integration. They move to a portal of their own once payment revenue grows large enough to be worth protecting.
Every major provider offers a ready-made seller-facing dashboard, and they cover more than platforms expect. Stripe’s Express Dashboard, to take one, hands connected accounts their balances, payouts, disputes and refunds.
It works, and it comes with the Connect integration itself.
Five things push platforms off it.
Brand. A seller who logs into someone else’s interface learns the name of your payment provider. A white-label merchant portal keeps that relationship yours.
Unified data. Your platform records the orders, invoices and jobs; the PSP records the payout. Yours is the side that can show a payout next to the sales behind it.
Workflow control. Provider dashboards expose provider concepts. Your own portal exposes yours, with the fields, labels, and states your product already uses elsewhere.
Permissions. Access rules for franchise structures, multi-site operators and outside bookkeepers go past what a generic dashboard supports.
Support volume. Tickets reach your team whichever dashboard the seller uses. The portal you own is the one you can reshape around the questions that keep arriving.
Providers also offer a middle path: embeddable UI components that render provider-hosted functionality inside your own application. That gets you brand and placement, and the payout screens stay theirs. The integration work is yours.
The decision comes down to which layers you own.
| Area | Build on raw PSP APIs | Build on payment infrastructure |
|---|---|---|
| Development | Custom throughout | Prebuilt workflows extended |
| Integration | Provider APIs, one per provider | Unified abstraction over providers |
| Onboarding | Build the KYC/KYB interface | Ready onboarding flows |
| Payouts | Build payout screens and scheduling | Existing payout management |
| Events | Maintain webhook handlers per provider | Normalised event stream |
| Permissions | Build roles from scratch | Existing role management |
| Time to first release | Months | Weeks |
| Where you differentiate | Everywhere, including plumbing | On top of the plumbing |
Building directly on PSP APIs makes sense when payments are your product, or when multi-provider routing is a strategic requirement.
The cost falls on webhook reliability, idempotency, reconciliation, and reporting.
Building on existing payment infrastructure, either a white-label platform or a core payments layer you extend, puts a working portal in front of sellers sooner and leaves engineering time for what is specific to your vertical.
The list below covers what a merchant portal handles end to end.
One more: mobile. A merchant dashboard that works at phone widths lets sellers check balances away from a desk.
A sub-merchant portal is where sellers experience your payments product, and also where payout questions get answered or forwarded to your team.
At Kindgeek we build the layer around Adyen for Platforms: the portal sub-merchants log into, the admin panel the team managing them works in, and an onboarding flow that mirrors Adyen’s legal-entity model one to one.
Adyen holds the funds, makes the KYB and KYC decisions, and grants capabilities once verification passes. Card details go through Adyen’s hosted components, which keeps cardholder data outside the portal’s PCI scope. The portal reads balances and payout information from Adyen and sends payout instructions back to it.
What a tenant gets:
Delivery runs in four phases: model fit in a week, tenant provisioning in one to two, validation on your test keys in a week, then production cutover. Platforms reach go-live in weeks because the tenant is configured on an existing implementation. We stay involved as you iterate afterwards.
Book a call to share your Adyen setup and seller model, and we will come back with the scope, timeline and team.
Contact usA sub-merchant portal is a self-service interface where businesses selling through a payment platform manage their own payment activity. It covers onboarding and verification, transactions, balances, payouts, refunds, disputes, reporting, and account details. The platform provides it; the seller uses it. It presents payment data; the processing happens elsewhere.
A merchant contracts directly with an acquiring bank and holds its own merchant ID. A sub-merchant sells under a payment platform’s acquiring arrangement, and the platform handles its onboarding, verification and payouts. Visa calls these businesses sponsored merchants, and applies the same acceptance requirements to them as to any other merchant.
Complete onboarding and submit verification documents, view and search transactions, issue refunds, check available and pending balances, track payouts and manage bank accounts, download statements for payment reconciliation, respond to chargebacks, update company details, and manage users and permissions. Exactly which of these are available depends on how the platform configures the portal.
No. The portal is an interface layer. Authorisation, settlement, and fund movement happen in the payment infrastructure behind it: the PSP, acquirer, or core payment platform. The portal reads state from that infrastructure and sends instructions back to it, such as a refund request or a dispute response.
Most do once seller numbers grow. Manual reporting and emailed statements cover a small roster. Past that, sellers ask for their own view of balances and settlement dates, and a marketplace merchant portal moves that lookup work from the support queue to the seller.
Yes. A white-label merchant portal carries your brand, domain, and design system, so the seller sees your name throughout. Providers support this through embeddable UI components or fully custom builds against their APIs. Provider-hosted dashboards offer limited co-branding.
Payments fraud is a constant wherever money moves. Payments fraud reached 76% of US organisations…
Ninety percent of technology professionals now use AI at work, according to DORA's 2025 research.…
Java backend and Java tests. Why matching your test automation language to the backend gets…
AI in payment processing uses models to make the calls that fixed rules used to…
AI models are increasingly influencing payment decisions involving real money, from whether a transaction should…
As more companies choose a blockchain consulting partner every year, the success of their blockchain…