There is a particular moment in a small fulfilment operation that exposes the relationship between payment and logistics with uncomfortable clarity: the moment when orders are packed, labels are printed, and you need to confirm that every payment has actually settled before you hand the box to the courier.

With card payments and bank transfers, the confirmation process is familiar even if imperfect. Funds appear in your account with a known delay. You learn to trust the pattern. With Bitcoin payments, the settlement confirmation follows a different rhythm, and that rhythm interacts with fulfilment timing in ways I did not fully appreciate until I was standing over a packed order, refreshing a block explorer, while the courier waited in the driveway.

The Fulfilment Window

Small batch fulfilment for flower orders, particularly bulb shipments, operates in tight windows. Bulbs need to be packed and shipped within specific temperature ranges. Cut flowers have even less margin, a day of delay can turn a premium product into compost. Seasonal demand creates surge periods where orders accumulate faster than they can be processed, and every hour of packing time matters.

Into this environment, introduce a payment method with a variable confirmation timeline. On a quiet network day, a Bitcoin payment confirms in ten to fifteen minutes. On a congested day, it might take an hour or two, sometimes longer if the customer's wallet selected a low fee. The question for fulfilment is: at what point do you consider the payment sufficiently settled to ship?

The Practical Threshold

After running through this question repeatedly with real orders, I have settled on a straightforward rule: one confirmation for orders under a certain value threshold, three confirmations for larger orders, and confirmed fiat conversion for wholesale orders.

The reasoning is simple. For a small retail order, the economic incentive for someone to attempt a double-spend attack (the theoretical risk of an unconfirmed or lightly confirmed transaction) is negligible. The cost and complexity of such an attack vastly exceeds the value of a box of tulip bulbs. For larger orders, particularly wholesale shipments worth hundreds or thousands of euros, the extra confirmation time is a small price for certainty.

Lightning Network payments sidestep this entirely. The payment is either confirmed or it is not. There is no waiting period, no ambiguity about confirmation count, and no race between the blockchain and the courier schedule. For retail fulfilment, Lightning is clearly the better fit.

Staging and Batch Processing

The practical solution that works best for our operation is staging. We batch orders by payment status.

Confirmed and ready. Card payments, bank transfers that have cleared, Lightning payments, and on-chain Bitcoin payments with sufficient confirmations. These orders are packed and labelled for dispatch.

Pending confirmation. On-chain Bitcoin payments that are broadcast but not yet sufficiently confirmed. These orders are packed but held until confirmation arrives. Typically this means a delay of twenty minutes to an hour.

Awaiting payment. Orders where the customer has placed an order but not yet initiated payment. These are not packed until payment is detected.

This staging approach means that Bitcoin payment orders are slightly delayed compared to card orders on average, but the delay is almost always under an hour. On busy fulfilment days, the time spent packing the next batch of card orders is usually enough for the pending Bitcoin payments to confirm.

Where Timing Gets Interesting

The intersection of payment timing and fulfilment creates a few patterns worth noting.

Morning orders, afternoon shipping. If your shipping cutoff is mid-afternoon, a Bitcoin payment received in the morning has plenty of time to confirm. This works perfectly for the overnight online order pattern where customers place orders in the evening and you process them the next morning.

Last-minute orders. These are the tricky ones. A customer places an order an hour before your shipping cutoff, pays in Bitcoin, and the transaction enters a congested mempool. You now have a fully packed order, a courier approaching, and an unconfirmed payment. The options are: ship anyway (accepting the risk), hold for the next shipping day (potentially upsetting the customer), or ask the customer to pay via Lightning or another method.

I have had this exact scenario twice. Both times the on-chain payment confirmed before the courier arrived, but the stress of not knowing was educational. Since then, I encourage Lightning payments for any order placed close to a shipping cutoff.

Pre-order and deposit patterns. For pre-orders where the shipping date is weeks or months away, confirmation timing is irrelevant. The Bitcoin payment can take hours to confirm without affecting fulfilment. This makes Bitcoin particularly well-suited for advance ordering, where the payment and the fulfilment are naturally decoupled in time.

Cash Flow Interaction

The fulfilment schedule also interacts with cash flow in a specific way. When you ship an order, you incur shipping costs. If you also pay your supplier for the products being shipped, you have two outgoing cash flows tied to each order. The incoming payment needs to have settled, in usable form, before or at the same time as these outflows.

With immediate Bitcoin-to-fiat conversion, the settlement timeline looks like this: customer pays in Bitcoin, processor converts within minutes to hours, fiat lands in your bank account within one to three business days. If you ship on Monday and the fiat lands on Wednesday, you are floating two days of shipping and product cost from your own working capital.

This float is identical to what card payment settlement creates, so Bitcoin is not uniquely problematic here. But it is worth understanding that neither system provides instant cash availability, and planning your fulfilment spending accordingly.

Workbench with neatly packed bulb orders in boxes alongside shipping labels and a roll of packing tape

What I Have Adjusted

Over months of running this dual-payment fulfilment setup, a few adjustments have improved the workflow:

Lightning as default for retail. I now actively suggest Lightning for any in-person or small online order. The instant confirmation eliminates the staging delay and makes the fulfilment process identical to card orders.

Confirmation alerts. I set up simple notification alerts for Bitcoin payment confirmations. Instead of manually checking a block explorer, I get a push notification when a payment confirms. This lets me continue packing other orders and respond to confirmations as they arrive.

Clear order communication. Confirmation emails to customers now include a note: "Your Bitcoin payment has been received and is confirming on the network. We will dispatch your order once confirmation is complete, typically within the hour." This sets expectations and prevents "where is my order?" messages.

Separate accounting for float. I track the settlement lag separately for Bitcoin and card payments, which gives me a clearer picture of actual working capital availability on any given day.

The Takeaway

Payment timing and fulfilment timing are always in tension, regardless of payment method. Bitcoin adds a variable to that tension, but it is a manageable variable once you understand the patterns and build your staging process around them. The key is not to treat Bitcoin payments as card-equivalent in timing, but to accommodate their actual settlement rhythm in your operational workflow.

For more on Bitcoin payment operations, see our Bitcoin Payments hub. For seasonal-specific considerations, see the guide on Bitcoin for Seasonal Businesses.