FlashdropAn Algerian cash-on-delivery landing page

The problem & workflow

Choose variant and delivery → validate customer fields → submit to PHP with an idempotency key → server validates again → demo accepts or Telegram confirms → interface displays the server order number.

Key features

• Responsive product imagery and conversion layout
• Algerian phone validation and wilaya/municipality fields
• Home/office delivery, colour, size and quantity totals
• Form recovery, loading states and retry handling
• Server-side Telegram order delivery and explicit offline demo mode

Architecture & decisions

• Moving the bot token out of browser code changes the trust boundary: the browser sends an order, while the server owns provider credentials.
• Server allowlists are derived from the actual variant and delivery controls. Browser validation alone is bypassable.
• A locked hashed submission record avoids resending a successful request. An uncertain provider outcome is held for reconciliation rather than silently retried.
• Successful local backups contain only receipt IDs and timestamps. Draft form recovery remains local and should be cleared on shared devices.

Inside the source

• index.html
• api/order.php
• api/options.json

A checkout shaped by Algerian cash-on-delivery ordering

I built Flashdrop around the Algerian cash-on-delivery order workflow.

Flashdrop is a focused product landing page with an order workflow. Phone validation, wilaya and municipality choices, home or office delivery, product variants and quantity totals turn a visual page into an operational intake form. Local form recovery supports a visitor returning after an interruption.

The release retains the design and moves Telegram submission to a small PHP endpoint. A bot token in browser JavaScript can be copied by anyone loading the page; server-side configuration keeps that credential outside the public assets. The server repeats validation because browser controls can be bypassed.

Distinguishing a retry from another order

Duplicate submissions need more than a loading spinner. An idempotency key binds a submitted payload to a receipt. Repeating the same key returns that receipt, while changing its payload produces a conflict. Private receipt storage and locking support this boundary; provider uncertainty must not be silently shown as a successful delivery.

The public demonstration accepts synthetic orders without contacting a real Telegram channel. Stock, offers, countdowns and reviews are presentation content, not evidence of actual commercial activity. Live provider-failure and retry integration remain follow-up checks before using it for real customers.

Project status

Focused Algerian COD landing page with an order workflow; stock, reviews and offers in the portfolio demo are presentation content.

PHP 8.1+ with cURL is required for live Telegram calls. Demo mode defaults to 1 and needs no provider key. For live mode export DEMO_MODE=0, TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID server-side; keep ORDER_STATE_DIR outside the public document root and writable only by the service. Use the options in api/options.json and a fresh idempotency key per distinct order.