Publishing a multi-week course, and taking the register each week

How should I model a six-week course?

As one event with six sessions, not as six events. The event is the course a learner enrols on; the sessions are the weeks it runs, each with its own capacity, its own register and its own attendance record. The console generates the series from a cadence rather than making you type each date, which matters when the same course runs every month through the year.

Per-session capacity is why the shape is worth the effort. A classroom evening that holds twelve and in-car sessions that hold two is a real constraint, and modelling it as capacity rather than as a sentence in the description means the platform refuses the third in-car booking instead of your instructor discovering it at seven in the morning.

One limit to design the page around: the hosted checkout sells one session per order, so a learner buying from your public page books the course as you published it rather than assembling their own weeks. Multi-line bookings across sessions ship on the JSON API today, and the console can take one on a learner’s behalf.

How do I make sure nobody pays before I have seen their permit?

Turn on application review for the course. With it on, a booking does not create an order: it files an application, the learner is told it is with you, and their place is held while you decide. No payment intent is created at all, which is a stronger guarantee than an unpaid order — there is nothing to capture, so no sequence of events charges them by accident.

The approvals page lists what is waiting, with the submitted answers beside each application and a link that opens the uploaded permit. Opening it is the point: bindro never validates a permit number and never looks at the image, so the review is the entire check.

Approving emails the learner a link to pay and only then does the checkout reach payment. Rejecting releases the place, tells them, and scrubs what they submitted. It is per event, so a classroom-only refresher can sell instantly while the permit-gated course beside it waits for a human.

• Application review is per event and off by default.
• The queue needs order-write — an instructor with only the scanning role cannot open it.
• An application left too long expires and returns the place rather than holding it forever.

What happens when the course fills up?

The public page offers the waitlist instead of a dead end, and the promise behind it is real inventory. Joining twice with the same address does not improve your place in the queue. When a place frees, the worker promotes the front entry by putting a time-boxed hold on that exact seat and emailing a link into the normal checkout, so the promoted learner has a day to claim a place that is genuinely theirs.

If they let the hold lapse it is swept like any other hold and the next entry is promoted on a later tick. Nothing is oversold along the way: the promotion holds the seat, it does not merely announce it.

Remember what does not free a place. A refund or a deferral leaves the seat counted as sold, so if you want the waitlist to move after somebody drops out, raise that pool’s capacity by one in the console.

What does taking the register look like each week?

Your instructor opens the session on a phone and sees who is booked on it. A learner either shows the code from their confirmation email, which is scanned, or is found by name and tapped — both write the same attendance record, because a name list is the primary method for this vertical and scanning is the quick path rather than the only one. The count updates live, and a learner stepping out and back in through the same device is readmitted as a re-entry rather than counted twice.

Each week is its own session and its own register, so the record shows which weeks a learner actually attended. Re-entry is allowed, so somebody stepping out and back in during a long classroom evening does not need a fresh pass. An under-18 whose guardian has not countersigned is refused here, which is where you find out if the email went unread.

The door needs a signal. Offline device sync is not among the capabilities this vertical declares, so a meeting point with no coverage means loading the list before you leave or carrying it on paper.

How do I issue certificates at the end?

From the register, once the session has ended. You issue certificates for a session in one action and only learners with a check-in record get one — hours come from the session’s length, each carries a serial, and re-issuing never duplicates a credit. A session that has not finished yet is refused, because a certificate issued from a sale rather than from attendance is worth nothing.

Be exact with learners about what they are getting. It is your school’s record that this person attended for these hours, printable and serialised. It is not a state completion certificate, and bindro transmits it to no authority: whatever your jurisdiction requires you to file, you file exactly as you do today.