Your store keeps selling, whatever happens to us

Before you put anything between your customers and your checkout, one question is worth asking: what happens to my store if this vendor has a bad day?

Here is our answer, in plain terms, and how the system is built to guarantee it.

Most waiting rooms stand in front of your store

The usual setup is that your traffic runs through the vendor: you point your domain at them, or switch on a feature inside the network you already use. From then on, every click a customer makes passes through their system before it reaches yours.

That design works — but it makes your store downstream of somebody else. If they have an outage or performance blip, so do you.

Dropify is built the other way around

We split the job in two:

1. We decide who gets in. Who is in the queue, what number they hold, when it’s their turn — and when it is, we issue them a cryptographically signed pass.

2. Your store checks the pass. A small component — our WooCommerce plugin, or a lightweight edge connector — verifies each visitor’s pass locally on your own infrastructure, using cached epoch keys, without calling our servers.

That last part is the core design property: on a normal page load, nothing on your site talks to us. We’re involved when someone joins the queue and when they’re admitted. We’re not involved every time a customer browses a product.

If we go offline, you keep selling

Our primary directive: a problem on our side must never stop your store from taking orders.

The WooCommerce plugin keeps its own durable copy of your policy and epoch keys in WordPress options. If our brain goes offline, your plugin carries on exactly as configured — the queue keeps running, admitted customers keep checking out. The only thing you lose until we return is the ability to change settings in the console.

If an unresolvable network situation occurs, the plugin errs on the side of letting the shopper browse rather than locking them out. A store that briefly admits a few extra shoppers recovers; a store that stopped taking money does not.

There is one intentional exception: compromised key revocation fails closed. If you explicitly revoke a key, we do not quietly fall back to accepting it during network instability.

No DNS change, and your traffic never routes through us

Neither piece requires touching your DNS settings, and neither puts us in the path of your everyday traffic.

• The WooCommerce plugin runs on the hosting you already have. There is nothing to point anywhere.
• The edge connector runs on your own Cloudflare account via route rules ([[routes]]). It never learns your origin server’s direct IP address, because it never needs it.

Two halves, two jobs

For a major drop, the edge connector and the WooCommerce plugin work together:

The edge connector keeps the crowd off your server. Everyone still waiting gets their response manufactured directly on Cloudflare’s network — your hosting never sees them. Twenty thousand people can wait without your server answering a single polling request, saving full origin capacity for admitted shoppers.

The plugin ties each admission to an order. It sees what the edge cannot: the cart, the checkout, and payment confirmation. One admission means one order — nobody who cleared the queue once walks away with five orders across multiple tabs.

They also cover each other: if something slips past the edge, it meets the plugin’s local verification at your store.

You can read every line, and run in shadow mode first

Both pieces are open source. Before running our code next to your checkout, you or your agency can inspect every line.

Furthermore, the WooCommerce plugin starts in observation mode upon activation: it watches real traffic and records what decisions it would make without blocking anyone, allowing you to verify its behavior before a single customer is affected.

On an ordinary day, nothing of ours stands in your way — and on our worst day, your store keeps selling.