How FairDrop Works

The problem with limited drops

When you release a scarce product, you're competing against automated buyers. A sophisticated bot can complete a checkout in under a second — by the time a real fan adds the item to their cart, it's gone. Storefront restrictions like CAPTCHA and queue pages slow bots down but can be worked around, and post-purchase cancellations are reactive and messy. FairDrop takes a different approach: prevent the purchase from completing at all, at the checkout layer, before an order exists.

Where enforcement happens

Shopify's checkout is the one point every buyer — human or bot — must pass through. FairDrop puts its enforcement there, using Shopify Functions: small pieces of logic that run inside Shopify's own checkout infrastructure, server-side. Because they run there, they cannot be bypassed by:

• Headless API checkout (direct API calls without a browser)
• Browser automation (Selenium, Puppeteer, and similar)
• Modified storefronts or third-party checkout apps
• Accelerated checkout flows (Shop Pay, Apple Pay, Google Pay)

The two Functions

FairDrop uses two Functions working together. The Validation Function checks whether the buyer is eligible — account status, VIP eligibility, passkey proof, and quantity limits — and either allows the checkout or returns a specific, buyer-visible error. The Payment Customization Function hides accelerated payment options for protected products, so every buyer goes through the standard add-to-cart → checkout path where the passkey flow runs correctly.

When enforcement runs

Turning a policy on and choosing when it blocks are two separate steps. Activating a policy makes it eligible to enforce; a scheduled window decides when it actually blocks checkout.

A window has a start, an end, and a timezone, and can run up to 30 days. Enforcement switches on 1 minute before the start time and switches off at the end time. You author the window while building the policy and can edit it until it starts — then it locks.

As the drop approaches, the policy moves through a short lifecycle: Ready (activated, no window yet) → Scheduled (window set, not started) → Active (enforcing right now) → Expired (window ended).

Monitor modeis available too — a free way to preview your rules by logging checkouts without blocking anyone. It's a before-the-window tool: turn it on ahead of time to watch real traffic, and when your enforcement window goes live it automatically takes over and starts blocking — even if you left Monitor on, so you can never miss your window. Because a live window always enforces, Monitor can only be turned on before the window starts.

A protected drop, start to finish

Say you're dropping 200 units of a limited sneaker with a policy that requires an account, a passkey, and a quantity cap of 1.

• Before the drop— you apply the policy to the variant. There's nothing buyers set up in advance; first-time buyers enroll a passkey inline the moment they add the item to their cart.
• Bots calling checkout directly hit the Validation Function and fail immediately — no account, no passkey proof.
• Real buyers complete a one-tap biometric check at add-to-cart and breeze through checkout (with a quick re-verify only if they lingered past the ~10-minute proof window).
• After the drop, the dashboard shows buyers stopped at the gate, the passkey-recovery funnel, and protected orders; the Events log records every gate stop and protected checkout for reconciliation.