Vetting a new trader before you take their money

What actually changes when I turn application review on?

The order of the two things that matter. Without review, a vendor books and pays and you find out afterwards. With review on, the confirm step files an application instead of pricing an order: the trader completes the form, uploads their certificate, and gets a page saying you will let them know. No order row exists. No payment intent exists at the provider. There is nothing to capture, refund or reconcile, because no money apparatus was ever created.

That distinction is the whole value. "We do not charge before approving" is not a flag somebody could set wrongly or a workflow step somebody could skip — the money path itself refuses, on every surface, including a back-office booking and the public API. A market that has been burned by a trader whose card was taken before anyone looked at their paperwork is buying exactly this.

Approving emails the applicant a link to pay. Rejecting releases the pitch back on sale immediately, scrubs what they submitted, and notifies them. Both decisions are one click from the queue.

What does the reviewer actually see, and what is held meanwhile?

The approvals queue lists each waiting application with the trader’s answers labelled in your own words — business name, product category, pitch size, power, insurance expiry — and the uploaded documents as links you open. That last part is the point: a reviewer deciding on public liability cover needs to read the certificate, not see a tick saying one was attached.

While you decide, the pitch is reserved rather than sold. The hold the applicant took becomes a review window, so nobody else can take that pitch and the market has not recognised any revenue. The queue shows the deadline against each application, and if you let it pass, a background sweep expires the application and puts the pitch back on sale by itself. That is the right failure: a forgotten queue costs you a booking rather than quietly holding a pitch empty all season.

Set the expectation with traders that a decision takes less than that window. The sweep is a safety net, not a workflow.

• Answers are labelled with your own question wording, not database keys.
• Documents open in one click from the queue — read them, do not just count them.
• The pitch is held, not sold, and nothing has been charged.
• A lapsed application expires itself and releases the pitch.
• Rejection releases the pitch and scrubs the submitted data.

Where does bindro stop on insurance and permits?

At TELLING you, and this is the most important paragraph on the page. bindro asks for the expiry date as a required question and the certificate as a file, shows you both when you decide, and from then on compares that date to today for traders booked onto dates still to come: they appear on your vendors screen, you are emailed once per document, and the lapse rate is counted for you. What does not exist is enforcement. There is no automatic suspension, and a trader whose policy expired in July can still book the August date — bindro raises it, you decide what to do about it.

Nor does bindro check anything. The certificate is bytes for a person to open, the food permit is a confirmation the trader makes, and no insurer, council or food-safety register is contacted by anyone at any point. Approving an application means a human at the market looked at the file and said yes.

And approval is per market day, not a standing status. There is no vendor register in bindro that carries "approved for the season" from one date to the next: if a market day requires review, every application for it is reviewed. For a market with sixty regulars this is real work, and the usual answer is to run review on the dates where new traders apply rather than on every date of the season.

So the JUDGEMENT stays with you, and so does the renewal chase — bindro emails you, not the trader. Markets that must hold current certificates use the alert as the prompt and the review step as the gate.

How should a market sequence all this across a season?

A pattern that works: open the season with review on, so every new trader passes a human before they can pay and you build the year’s roster deliberately. Once the regulars are in and the mix is right, run the remaining dates without review so a known trader can just book, and turn it back on for any date where you are recruiting.

Keep the question list stable across the season. The answers are what the board report breaks your year down by, and a category renamed in July makes the October table harder to read than it needs to be.