Farmers Market Vendor Management

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "pitch" and "market day" because that is what a market says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

The certificate is a photograph in a message thread and the market day is Saturday

Every trader on the pitch list has to hold public liability cover, and the operating licence says the market keeps a copy. What actually happens is that the certificate arrives however the trader felt like sending it: a photograph in a message thread, a forwarded broker email with the PDF stripped out, a screenshot of a renewal quote that is not a certificate at all. Somebody at the market — usually the same person doing the pitch plan and the float — collects them into a folder on a laptop, and the folder is authoritative right up until the week it is not. The cost is not the filing. It is that on the Saturday morning of an inspection nobody can say, in under an hour, which of the forty traders on the street has a current certificate on file, and the honest answer to the inspector is that most of them probably do.

What bindro does: The certificate is a required file on the booking form and the expiry date is a required structured answer beside it, so an application without both is refused with the missing field named rather than accepted and chased. Both are checked on the money path rather than in the browser, which means a trader cannot skip them by using a phone that hides half the form. Both then arrive attached to the application in your approvals queue, where a person opens the file and decides. What that gives you is not a compliance system; it is one place where the document and the date are stored against the trader and the date they booked, exportable as rows whenever an inspector or a board asks. The judgement about whether the cover is adequate stays entirely yours, because nothing in bindro reads a certificate or contacts an insurer.

The money arrives before you have decided whether to let them trade

A market is a curated thing. The operator is balancing a trader mix, honouring an unwritten promise to the baker who has been there four years, and keeping out the reseller who buys wholesale and calls it local. Generic ticketing has no concept of any of that: it takes the card the moment the trader clicks, and the market finds out it has sold a pitch to somebody it did not want at the same moment it finds out it has their money. Every option from there is worse than the last. Refunding reads as a rejection with a receipt attached, and the trader tells the other traders. Letting them come this once sets the precedent. Keeping the money and stalling is how a market ends up in a chargeback it will lose, because the trader did buy a pitch and did not get one.

What bindro does: Application review moves the whole decision upstream of the money. With it on, a booking files as an application: no order is created, no payment intent exists, the trader is told plainly that it is with the market, and the pitch is held while you look. Their answers and their uploaded certificate sit in your approvals queue with the product category and the pitch size they asked for. Approving emails them a link to pay for exactly the pitch they were held. Rejecting releases the pitch back to the date, tells them, and scrubs what they submitted rather than leaving a rejected trader’s insurance certificate sitting in your system indefinitely. The difference this makes to a market is that saying no costs a sentence instead of a refund, an argument and a story that goes round the other stalls.

Saturday turns out to be four bakers, three candle stalls and no vegetables

Trader mix is the product. A market that is two-thirds prepared food is a street food event, a market with four bakers has three unhappy bakers, and a market with no vegetables has failed at the one thing its name promises. Operators know this and still get it wrong, because the information needed to get it right is spread across a booking system that recorded a name and an amount, an email thread where somebody described what they make, and the operator’s memory of who came last month. By the time the mix is visible it is Saturday morning and it is visible because you are standing in it. The pitch that should have been held for a grower went, three weeks ago, to whoever filled the form in first.

What bindro does: Product category is a required select on every application — produce, bakery, dairy, meat and fish, prepared food, drinks, crafts, plants — and it is answered before the money moves rather than reconstructed afterwards, so the queue you are approving from already tells you what each application would do to the balance of the street. Pitch size and whether they need power come with it. Because those answers are order-scope selects with no declared sensitivity, they are also the breakdown the board and funder report is built on, and they export as rows you can sort. The mix stays your decision and your plan — bindro assigns nobody to anywhere, and there is no layout in here — but you are making it in the approvals queue three weeks out instead of on the pavement at seven in the morning.

The season is twenty-six Saturdays and the diary is a spreadsheet

A market is not an event, it is a habit: the first Saturday in April through to the week before Christmas, same street, same hours, forty pitches. Ticketing tools are built for the opposite shape — one night, one door, sell out, done — so running a season on one means creating the same thing twenty-six times, or creating it once and then keeping the actual dates in a spreadsheet that the booking page knows nothing about. Both fail the same way. A trader asks whether the twelfth of July is open and the answer takes two people and ten minutes, and somewhere in the season there is a date that was never opened for booking at all, which nobody discovers until the week it arrives and there are nine traders on a street that holds forty.

What bindro does: The dates are generated rather than typed. A weekly cadence produces a session per market day in one transaction — the cadence row, the sessions and their inventory pools together, so a half-created season is not a state that exists — and each generated date carries its own pitches at their own capacity. Pitch sizes are published as separate types at separate prices: a three-metre, a six-metre and a vehicle pitch are three things a trader chooses between, and the platform refuses the booking that would take a date past its capacity rather than letting you find out. One limit stated plainly, because it changes how you publish: a trader books one market day per checkout. There is no multi-date basket in this vertical, so a grower taking every Saturday until October checks out once per Saturday.

The field has no signal and the pitch list is on somebody’s phone

Markets happen in the places where phones do not work: a walled car park, a village green with one bar of coverage shared between three hundred people, a showground that was a field on Thursday. The pitch list is therefore printed, because the printed one always works, and the printed one was printed on Friday afternoon. Two bookings came in on Friday evening. A trader cancelled overnight. At half past six in the morning, in the dark, in the rain, two stewards are working from two different versions of a sheet of A4 and the only person who knows which is right is not on site yet. Nobody gets turned away over this — they get waved in, which is the same as not having a list at all.

What bindro does: Check-in is a name list here rather than a scanner, because that is how a steward actually works a market: find the trader, tap them in. The manifest downloads to the device before you leave, and the door then works with no coverage whatsoever — scans and taps are validated against the local copy and reconciled when the device next reaches a signal. A trader who has their confirmation code can be scanned instead, and a trader who nips back to the van and returns is tapped in again at the same device as a return rather than counted twice. Two stewards on two devices do not overwrite each other: re-uploads are ignored and genuine clashes surface as a conflict to look at. When there is a signal the count is live, so the person doing the pitch plan can see who has actually arrived rather than who was expected.

The funder wants a report and a bank statement is not one

Markets are funded. There is a council regeneration grant, a lottery award, a levy from the business improvement district, or a parish council that wants to see what its money did — and every one of them asks for the same thing in a different shape, once a year, with three weeks’ notice. The market has a bank statement, a spreadsheet of pitch fees kept by whoever kept it, and a set of numbers about free community pitches that lives in nobody’s system because free pitches were never sold. Assembling the report takes a volunteer a fortnight, it never quite reconciles to the bank, and the discrepancies are the part the funder asks about.

What bindro does: The board and funder report is derived from the ledger the payouts reconcile against, not summed from a status column, so the income figure on the report and the money that reached the account are the same arithmetic rather than two estimates that ought to agree. Free and comped pitches are counted separately instead of vanishing into a zero, which is usually the number a community-funded market most needs to show. The breakdown comes out by product category and pitch size — the trader-mix table a funder actually asks for. Receipts suitable for a nonprofit’s books are issued on the pitch fees, gross and fees and refunds are reported per market day, and everything underneath exports as CSV. Pitch occupancy itself is computed on the analytics screen with both numbers printed under it, so the figure a funder asks for is on a page rather than a fortnight away.

Pitches, sized and dated, as real inventory

A market day is a slot and the pitches on it are inventory in that slot, which is the shape the engine enforces rather than a convention you maintain. Inventory moves only under a row lock inside the confirming transaction with a database constraint behind it, so two traders cannot take the last three-metre pitch in the same second however hard they both refresh.

• Pitch sizes are published as separate types at separate prices — 3m, 4.5m, 6m and vehicle pitches are four choices a trader makes, each with its own count.
• A pitch that costs more because it has power is published as its own type at its own price; the power question on the form records a need and charges nothing.
• Each generated market day holds its own capacity, so a smaller winter layout is a number on that date rather than a note to remember.
• Sold out offers a waiting list rather than stopping at "All pitches taken": the trader at the front is promoted when a pitch frees up, with it held for them and a link to finish. Joining is not a booking and charges nothing.
• A refunded pitch stays counted against the date: raise the capacity by one if you want to resell it.

Applications you review before anybody is charged

Approval sits upstream of the money rather than beside it. Turned on for a market day, a booking files as an application and returns no order and no payment intent at all — the trader sees that it is with the market, and every money surface stays gated until somebody approves it. This is the capability that makes a curated market work on a self-service booking page.

• The application carries the business name, product category, pitch size, power requirement, insurance expiry date and the certificate itself.
• Approving emails the trader a link to pay for the pitch that was held for them.
• Rejecting releases the pitch and scrubs what they submitted, so a rejected trader’s documents do not accumulate in your queue.
• Approval is per market day, not a standing vendor status — there is no account to suspend and nothing carries a decision forward to the next date.
• Nothing is validated by machine: no insurer, council or food-safety register is contacted, and approving means a person at the market looked.

Invoices and purchase orders, for the traders who cannot use a card

A good share of a market’s pitch income does not come from somebody tapping a card on a phone. It comes from a business with an accounts department, a council department taking a stall for an awareness day, or a charity whose treasurer is the only signatory. Those bookings are invoiced against a purchase order rather than forced through a card checkout that will fail.

• An invoice is raised against the business and its purchase order number rather than a card being taken at the point of booking.
• The pitch is held against the booking in the normal way, so an invoiced trader occupies a real place on the date rather than a note beside it.
• Receipts suitable for a nonprofit’s own books are issued on the pitch fee.
• A booking can be created from the console for the trader who phones the market office instead of using the website at all.

A market day that runs whether or not the phones work

The day-of tooling assumes the worst conditions a market actually has: a field, rain, dark, and one bar of signal shared by everybody. Download the manifest before you leave and the door works entirely offline, reconciling when the device gets back into coverage.

• Name-list check-in is the primary method — find the trader, tap them in — with code scanning as the quick path rather than the only one.
• A trader coming back through the steward who checked them in is admitted again as a return; the same code at a different steward's device reads as already used. The arrival is counted once however many times it is scanned.
• Two stewards on two devices do not overwrite one another: re-uploads are ignored and real clashes go to a conflict queue.
• Live remaining capacity per pitch type while the market is running, when there is a signal to show it on.
• A trader who turns up unbooked is recorded as a back-office booking so occupancy and the funder report stay true — the cash or the card machine is yours.

Reporting shaped like a market’s obligations, not a dashboard

Markets report upwards — to a board, a council, a funder, a parish meeting — far more often than most ticketed businesses, and usually to somebody who will ask why two numbers differ. Income is therefore derived from the ledger the payouts reconcile against rather than summed from a status column.

• Board and funder reporting with the trader-mix breakdown by product category and pitch size.
• Free and comped community pitches counted as their own line rather than lost in a zero-value total.
• Gross, platform fees and refunds per market day, reconciling to what actually reached the bank.
• Receipts appropriate to a nonprofit’s books on the pitch fees themselves.
• Full CSV export of orders and vendors behind a one-time code, with no export fee and no notice period.

A rota, and people who see only their part of it

Most markets are run by two paid people and a rotating cast of volunteers and stewards, and the person who works the gate on Saturday should not be able to see what every trader paid. Roles are checked in the handler rather than by hiding a button, and being on the rota grants no permission by itself.

• Shifts are scheduled against market days, so who is on the gate is recorded somewhere other than a group chat.
• A door login sees a name and whether the trader is expected — not the pitch fee, not the payout, not the other traders’ documents.
• The market manager can work the rota and the check-in list without being given access to the money.

Your own booking page, on your own website, at no cost to the market

Every market day gets a hosted page that works on the phone a trader is holding, and it can be embedded into the market’s existing website so bookings do not send people somewhere that looks like somebody else’s brand. Fees default to the trader paying them, which is why a market can publish a full season before spending anything.

• 2.5% + $0.99 on each paid pitch, added to the trader’s total by default so the market pays nothing up front and free pitches cost nothing at all.
• The market can choose to absorb the fee instead, in which case it comes out of the pitch fee rather than being added to it.
• Discount codes for returning traders, seasonal rates or a launch date.
• Post-market emails to the traders who attended, for next season’s dates or the renewal reminder the platform will not send for you.

Who pays the booking fee?

The vendor, unless you say otherwise. Every market day carries its own setting — the vendor pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-pitch $25.00 market day that is $16.20 either added to what vendors pay or taken out of what you keep.

Because the default is the vendor, a market can go from signing up to a sold-out market day without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by market day, admits one only once its LAST session has ended, and pays it once. A market day sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on market days that have not happened is exactly how a cancellation becomes vendors with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per market day, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

Occupancy is the number because everything else a market worries about is downstream of it. A street that is four-fifths full looks busy and pays for itself; the same street two-thirds full has visible gaps, and shoppers read gaps as decline. Both halves of the fraction are things bindro holds exactly: the capacity you published per pitch type on that date, and the pitches actually sold against it, with arrivals checked in on the day so a booked-but-absent trader does not quietly count as occupancy. Per date, per pitch size, exportable. The division is done for you on the analytics screen with both numbers printed under it, so it is a figure you can audit rather than one you have to trust.

Vendor retention — the second KPI, and the one that predicts occupancy a season ahead — is now computed for you: the share of traders who traded more than one market day, over the traders who traded at all, counted from your own bookings on dates that have already happened. Refunded and cancelled bookings do not count as days traded, and comped pitches are kept out of it, for the same reason every report here separates free places from revenue. It is deliberately NOT the repeat-buyer figure sitting near it: a trader who places two orders for one Saturday bought twice, and did not come back.

Insurance lapse rate is computed from the certificates themselves: the share of traders booked onto a date still to come whose cover has already run out. The expiry date is collected as a required answer beside the certificate, shown to you when you review the application, and read back nightly from then on — the traders concerned are listed on your vendors screen and emailed to you once per document. What still does not happen is enforcement: no trader is stopped from booking the next date with cover that expired in June, and there is no standing vendor status that could be suspended even if something wanted to, because approval is per market day. So a market that needs lapses ACTED on still acts on them itself; what it no longer has to do is notice them itself.

Waitlist depth counts the traders still queueing on dates that are still on sale — which is exactly the evidence a funder asks for when you argue for a bigger site. The limit worth knowing is on the other side of it: a booking that is refunded does not return the pitch to the pool, so a refund promotes nobody. Raising the capacity for that date is the action that lets the queue move, and an unfinished booking whose reservation lapses promotes somebody by itself.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per market day, read from the ledger the payouts reconcile against.
• Pitches sold against vendors checked in, with a no-show percentage per session.
• Live remaining capacity while the market day is running, per pool, on the day-of screen.
• This market's own funnel — enquiry → application → documents uploaded → approved → paid → traded — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and vendors as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a market's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• bindro warns you about insurance expiry but never suspends a vendor. The expiry date is a required question, the certificate is attached to the application, and both are in front of you when you review it. From then on the date IS read back: traders booked onto a date still to come whose cover has run out — or runs out within a month — are listed on your vendors screen and emailed to you once, and the lapse rate is on your analytics page. What does not happen is enforcement: nothing stops a trader with lapsed cover booking the next date, because whether to let them trade is the market’s decision and not ours.
• bindro does not check any document. The certificate is bytes for a person to open and the permit number is a string nobody validates: no insurer, no council and no food-safety register is contacted. Approving an application means a human at the market looked.
• No season booking and no recurring billing. A vendor books one market day per order, because this vertical does not resolve the multi-day basket, the season pass or subscriptions — a trader taking a pitch every Saturday until October checks out once per Saturday, and no card is stored to be charged again later.
• No pitch map and no allocation. bindro sells a pitch of a stated size in a stated slot; which physical spot on the street that becomes is your plan, made wherever you make it today. Nothing here draws a layout or assigns a stand to a location.
• No trader rate for booking two pitches: two pitches cost twice one pitch. Paid extras are real — power, a table, a gazebo, extra frontage are add-ons a trader buys with the pitch — but the "power required" box on the form is still only a question, and a pitch that costs more with power is best published as its own pitch type at its own price.
• No sales tax is calculated, added or reported. The pitch price you publish is the amount the vendor pays, and what you owe on it is between you and your state.
• No card terminal at the market. A trader who turns up unbooked is either sent to the booking page on their phone or recorded in the console as a back-office booking, with the cash or card machine being yours, not ours.
• No transfer of a pitch to another trader, and no credit note for a rained-off date. Money out is the only lever: a full refund. A vendor who cannot trade is refunded, not moved to the following week.
• A refunded pitch does not go back on sale by itself. The money moves and the pitch stays counted against that date, so raise the capacity by one if you want to resell it.
• bindro cannot enforce a cancellation deadline. A vendor refunds themselves in full from the link in their confirmation email at any time up to the moment the market day starts — there is no notice window to configure and no fee to withhold. After the start time the decision is yours in the console.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

The reason is structural rather than a setting somebody forgot to turn on. This vertical does not resolve the multi-date basket, the season pass or recurring billing, so the season-booking path is refused at the call rather than half-working — and "subscription" appearing in the configuration’s list of pricing models does not change that, because the checkout only honours the models whose capabilities actually resolve. Two do here: a flat pitch price, and tiered pricing where the three-metre, six-metre and vehicle pitches carry different prices. A trader rate for taking two pitches is not one of them; two pitches cost twice one pitch.

In practice this matters less than it first sounds, for a reason worth knowing before you rule it out. Most markets that "sell the season" are not really taking one payment in March for twenty-eight Saturdays — they are taking a commitment in March and invoicing monthly, which is a conversation and an invoice rather than a checkout. That half does work here: a regular trader’s business can be invoiced against a purchase order, and a booking can be entered from the console rather than through the public page.

Where it genuinely hurts is the casual trader booking eight dates in one sitting, who now types their details eight times. If that is the bulk of your bookings, say so before migrating rather than after — it is a real limit, it is published here rather than in the small print, and the answer to it would be a capability declared, built and gated properly, not a workaround.

This is the most important operational sentence on this page, so here is the mechanism rather than the reassurance. The payout sweep looks for events whose sessions have all finished, groups the money by event, and releases one payout per event once. An event is only ever paid once. The trigger is the end of its LAST session, not the end of each one.

The weekly-series generator, which is the obvious way to create twenty-eight Saturdays and the right way to create a class course, produces sessions inside one event. That is exactly the shape that pays in October. If you want the money from the twelfth of July shortly after the twelfth of July — and a market with stallholder-funded running costs certainly does — publish each market day as its own event. You then get one payout per market day, two days after it runs, at the cost of creating the dates as separate events rather than generating them as a series.

Neither shape is wrong and the platform will not choose for you, but the trade-off is real and it is nearly impossible to unwind halfway through a season. Decide it before you publish. Either way the money moves only after delivery — there is no advance against a market day that has not happened, the payout is marked paid only against a real transfer reference checked by the database, and a market day cancelled for weather is refunded rather than paid out, since an event whose sessions were all cancelled is never delivered.

The limit is deliberate and worth stating on the page that is trying to win your business rather than in a help article you find in month three: nothing is enforced. A trader with expired cover can still book the next date. There is no suspension and no standing vendor record to suspend, because approval is granted per market day — so what you get is the prompt, and the decision stays yours. Bindro also reads no certificate and contacts no insurer: it compares the date the trader typed to today’s.

This page once claimed the tracking before it existed — "insurance expiry tracking" was in this vertical’s meta description and a hint under the required upload told traders they would be suspended if their cover lapsed. Neither was true, both were deleted rather than quietly left standing, and the feature was built afterwards. The claim on this page now is the narrower one the engine actually keeps.

What you can also rely on, and what the alert is built on: the date is a required structured answer rather than a note in a free-text box, so it is present, consistent and exportable for every application you have ever approved.

Signup is free and needs a phone number rather than a card. You name the organisation, create a market day, publish it, and it is sellable. Verification and bank details are deferred until you want the first payout, so a market can put a whole season on sale before proving anything to anybody — which also means a market can trial this against one date without a procurement conversation.

• One event per market day, or one event for the season? Decide first: it sets whether you are paid weekly or once at the end, and it is the hardest to change.
• Which pitch sizes are separate types, and their prices — including whether a powered pitch is its own type, since the power question charges nothing.
• Whether applications are reviewed before payment. Curated markets should say yes; a market that takes all comers can leave it off and let traders pay immediately.
• What you ask on the form beyond the required business name, category, pitch size, insurance expiry and certificate — every extra question is one more thing between a trader and a booking.
• Whether the trader pays the platform fee or the market absorbs it out of the pitch fee. The default is the trader, and it is why the market pays nothing up front.
• Who on your team gets which role, before the first Saturday rather than at half past six on it.

The comparisons linked from this page go through the same exercise against the tools markets most often move from, name where each of them is genuinely stronger, and carry the date they were last reviewed. A comparison with no such section is an advertisement and you would be right not to believe the rest of it.

• Does a meaningful share of your traders book many dates at once? Here they check out once per date.
• Do you rely on your current system to ENFORCE insurance — to suspend a trader whose cover has lapsed? The expiry date is read back and you are warned once per document, but nothing here blocks anybody; acting on a lapse stays yours.
• Do you need a pitch map that assigns stands to locations? That does not exist here; a waiting list for a full date does, and promotes the trader who asked first.
• Do you add sales tax to a pitch fee? Nothing is added to the price you publish. Paid extras alongside a pitch are sold as add-ons.
• Does your cash flow need paying per market day? Then publish each date as its own event, and check the payout section above before you generate a season.