When the Best Checkout Is No Checkout

A florist with three branches asked me for an online store. I built one with no payment gateway, no card form, and no checkout page in the conventional sense — and it converts better than the version I originally proposed.

This is not a general recommendation. It is a case for actually looking at how your client sells before you reach for the standard architecture.

What I found by following a real order

Before writing anything, I traced a real order end to end. It went like this: a customer sees an arrangement on Instagram, sends a message asking if it is available today, asks for a photo of what is actually in the shop, agrees a delivery time, and pays the driver on arrival.

Nothing in that sequence is a payment problem. Every step is a confidence problem — is it fresh, is it really what the photo shows, will it arrive in time for the event.

A card form solves none of that. Worse, it introduces a new objection at exactly the wrong moment: pay a stranger up front for a perishable product you have not seen.

Cash on delivery is not a workaround here

It is worth being blunt about the market context. In Egypt, cash on delivery remains the default for a large share of online purchases, and WhatsApp is where commerce conversations already happen. Building for card-first behaviour would have meant designing for a customer that mostly does not exist for this shop.

The correct move was not to fight that. It was to remove every step that existed only to support a payment we were not taking.

The build

The cart works exactly as you would expect: browse a branch, add arrangements, choose delivery details. The difference is the final button. Instead of a payment step, it composes a complete, correctly formatted Arabic message and hands it to WhatsApp:

طلب جديد — فرع الإسكندرية
———————————
• باقة ورد أحمر — مقاس كبير × 1
• صندوق ورد مشكّل × 2
———————————
التوصيل: اليوم بعد ٦ م
المنطقة: سموحة
الاسم: ...

The owner receives a structured order in the app he already has open all day. He confirms availability, sends a photo of the actual arrangement, and agrees a time. The conversation that was going to happen anyway now starts with all the details already correct.

What this bought

No abandoned carts at the payment step, because there is no payment step.

No PCI surface, no gateway fees, no chargebacks. For a small business, the compliance and cost savings alone are meaningful.

Fewer wrong orders. The message is generated, not typed by a customer from memory, so branch, quantities and delivery notes arrive correct.

Zero training. The owner did not learn a dashboard to process orders. He kept using WhatsApp.

What it costs

I am not going to pretend this is free. You lose automated payment reconciliation, and revenue reporting depends on the owner recording what was actually collected. You depend on a third-party messaging platform. It does not scale to hundreds of daily orders without a human bottleneck, and it would be wrong for a business selling nationally at volume.

For a three-branch florist doing tens of orders a day, every one of those trade-offs is acceptable. That is the whole point — the architecture matched the business, rather than the business being asked to match the architecture.

The default e-commerce stack encodes assumptions about a market. Before you adopt it, check whether your client's customers actually live in that market.

The transferable lesson

The interesting question is never "which payment provider". It is "what is the customer's real objection, and does my checkout address it or add to it".

Sometimes the answer is a card form with saved payment methods and one-click purchase. Sometimes it is a well-formatted message to a person who will pick up the phone. Deciding which requires spending an hour watching how the business already works — reliably the most valuable hour in the whole project.