Wine club member pricing: the half bindro does, and the half your club software keeps

What does a member price actually do at checkout?

You publish a member rate on the ticket type alongside the standard one. The taster types their membership number into the field this vertical already asks for, and the server matches a one-way hash of it against your organisation's roster inside the same transaction that takes the money. A current member is charged the member rate; anybody else pays the standard one.

Two properties are worth understanding because they are what make it trustworthy. The price is derived on the server for both the quote and the confirmation, so the amount the card is charged is the amount the page showed — the buyer never names a price. And the check happens under the same lock as the seat, so a membership that expired this morning cannot be used this afternoon.

How does a member get onto the roster?

You put them there, by hand, in the console: a name, the reference and an expiry date, one member at a time. There is no CSV import and no synchronisation with anything, and nothing a buyer does adds them — not buying a seat, not buying a club pass, not buying a gift card. Revoking a member is a single action and takes effect immediately for any booking made afterwards.

Only the hash of the reference is stored, which is why the page cannot show you somebody's number back. That is a deliberate trade: the roster cannot be browsed or probed, and the cost is that you keep the authoritative list wherever you keep it today. For most wineries that means the roster here is a mirror of a few hundred current members, refreshed when the club changes.

• Add members in the console: name, reference, expiry.
• Set expiry dates rather than relying on remembering to revoke.
• Nothing on the buyer side ever writes to the roster.
• Only a hash is stored, so keep your authoritative club list where it already lives.

Can I run a members-only release?

Not as an enforced rule, and it is better to hear that here than to find out on release day. Membership sets a price, never a permission: once a tasting is on sale anybody with the link can book it at the standard rate. There is no invitation-only listing, no access code and no eligibility rule that can be pointed at the roster.

What wineries do instead is publish the release as its own event, send the link to members and to nobody else, and have the person on the door turn away anyone who should not be there. If the release genuinely must be closed, that is the shape: a quiet link, a member price that makes the intent obvious, and a human at the entrance. Anything stronger than that is a promise this software cannot keep.

What should stay in your club software?

Everything that recurs. bindro has no recurring charge anywhere in it — that is a deliberate platform decision rather than a missing feature, because payouts here settle per delivered event and there is no way to pay a winery for a subscription that is not attached to one. So dues, renewals, allocations, shipping, lapsed-member chasing and the club signup form all stay where they are.

The clean division in practice: your club platform owns who is a member and bills them; bindro owns what happens in the room and prices a seat for them. The only thing the two need to agree on is the membership number, which is why keeping the expiry dates honest in the roster is the whole of the integration work.

• Dues, renewals and allocations: your club platform.
• Shipping and its compliance: a DTC platform, never bindro.
• Who is currently a member: your club platform, mirrored into the roster.
• What a member pays for a tasting, and whether they were let in: bindro.