A vendor portal is a logged-in view where each supplier sees their own sales, current earnings and payout history — and nothing belonging to anyone else. It exists to answer the question vendors actually ask, which is not "what did I earn last month" but "how am I doing right now", and to stop that question arriving as an email you answer by hand.
The support load a portal removes
Statements answer a closed period. They arrive once a month and settle what happened.
The questions that take your time are about the open one. How many have sold this month? Did that piece go? Am I going to hit the payout minimum? Each is a few minutes of looking something up, and the volume scales with vendor count rather than sales — twenty vendors asking once a month is twenty interruptions whether you sold ten items or a thousand.
A portal converts that from a support load into a link. It also changes the tone of the relationship: a vendor who can see their own numbers is a partner, and one who has to ask is a supplicant.
Why not just give them Shopify admin access
This is the shortcut stores reach for, and it is a mistake worth naming clearly.
Shopify staff permissions are not built for this. Even a tightly scoped account generally means a vendor can see:
- Other vendors' products and sales. Your suppliers should not be able to see how each other are doing, or what commission arrangements the catalogue implies.
- Customer data. Names, addresses, order history. There is no business reason a consignment vendor needs this, and depending on where you operate, handing it over may be a data protection problem rather than merely an awkward one.
- Your overall numbers. Total orders, revenue, what your store actually makes.
There is also a practical risk: a vendor with product permissions can edit prices, descriptions and inventory — including on products that are not theirs — usually by accident.
The right scope for a vendor is narrow and obvious once stated: their sales, their earnings, their payouts, their products. Read-only on all four.
What belongs in the portal
- Sales for the current period, line by line, with date, product, quantity and value. The thing they came to check.
- Earnings so far, with the commission rate visible rather than only the result. "£100 × 60%" answers itself; "£60" invites a question.
- Payout history, with each past statement downloadable. This is what removes "can you resend March".
- Adjustments, as their own lines referencing the original order. A refund that reduces earnings must be visible, or the total looks wrong.
- The schedule, stated: when the current period closes, when it pays, what the minimum is.
What does not belong: anything about other vendors, customer personal data, and any control that changes a price or an inventory level.
Customer data, specifically
Worth its own paragraph because it is the detail most often got wrong.
A vendor whose item sold does not need the buyer's name, email or address. If the vendor ships the item themselves — a marketplace arrangement rather than consignment — they need the delivery address and nothing else, and that is a deliberate, limited exception rather than general access.
The default should be that a vendor sees an order number, a date and a product. That is enough to reconcile against their own records, which is the only reason they need order-level detail at all.
What vendors look at, and in what order
Worth knowing before designing the first screen, because it is not what store owners assume.
Vendors overwhelmingly want one number: how much have I earned this period. Not orders, not units, not conversion. The money.
Second is which items sold, and specifically which ones — a maker with twenty pieces cares that the blue one went, not that three sold. For one-of-a-kind stock this is the interesting number and a count tells them nothing.
Third is when the money arrives. Not the policy in the abstract, which they have read, but the date for this period.
Everything else — charts, month-on-month comparisons, best-seller rankings — is something store owners want and vendors rarely open. Build the first three well and the rest can wait, or never happen.
One thing genuinely worth adding: what has not sold, and how long it has been there. A vendor who can see that four pieces have sat for eighty days will often propose a price reduction themselves, which is a much easier conversation than you asking.
Getting vendors to actually use it
Portals get built and then ignored, and the reason is almost always the first five minutes.
- Send the link in the statement email, every month. The moment they are thinking about their numbers is the moment to offer the place to see them.
- Do not require a password they will forget. A magic link to the vendor's registered email removes the commonest reason people stop logging in.
- Make the landing view the answer. If the first screen is a dashboard with filters, a vendor who wanted "how many sold this month" has to work for it. Lead with the number.
- Tell them when it updates. A vendor who checks and sees yesterday's figure will assume it is broken unless the page says how current it is.
Build it or use what the app gives you
A vendor portal looks like a small build — a login and a filtered list — and stores that try it usually find the list was the easy part.
What actually has to be right: authentication that does not become a support problem, authorisation that provably cannot leak one vendor's data to another, the same commission logic your payouts use rather than a second implementation that will drift, historical statements that stay stable when a rate changes, and somewhere for it to run.
That last point is the one that surprises people. A Shopify theme cannot host this — Liquid renders the storefront and has no notion of a logged-in vendor with private financial data. You need an app or an external service, which means hosting, updates and a security surface to look after.
The authorisation part deserves emphasis: a portal where changing a number in the URL shows another vendor's earnings is worse than no portal at all. That is a straightforward mistake to make and an expensive one to discover.
Building makes sense if your arrangement is genuinely unusual — an unusual commission structure, or a portal that has to do something beyond reporting. For "vendors should see their own sales", it is work you can buy.
What it does not solve
A portal removes routine questions. It does not remove the ones that matter — a disputed figure, a refund they did not expect, a rate change they want to discuss. Those still want a person.
It also does not replace the statement. A statement is a record sent at a point in time, which is what makes it useful in a disagreement. A portal shows current state, which by definition changes. Keep both: the portal for the running question, the statement for the settled one.
Payvenda includes a vendor portal on its paid plans, scoped so a vendor sees their own orders, earnings and payout history and nothing else.
Where to go next
If you have a handful of vendors and they rarely ask, a monthly statement is enough. The point a portal pays for itself is when vendor questions start arriving weekly, or when you catch yourself considering giving someone Shopify admin access.
What goes into the statement itself, and the payout mechanics behind both, are in the consignment and vendor payouts guide, and the setup sequence in running a consignment store on Shopify.
