Take orders by form instead of a cart
A shopping cart assumes fixed products, fixed prices and payment up front. Plenty of businesses don't work that way: a bakery taking cake orders for Saturday, a print shop pricing by quantity. For them, an online order form website that collects exactly what's needed, and lands in a spreadsheet or channel you already watch, is the better tool. Anticode builds that form and can total the order on the server.
When a form beats a cart
| Your situation | Better fit |
|---|---|
| Each order is made or packed to order, and you confirm before taking money | Order form |
| Customers order in quantities, with prices that change by volume | Order form with a total worked out from the fields |
| Most orders come from regulars who pay on account or by invoice | Order form |
| You need a collection or delivery slot agreed before you commit | Order form |
| Fixed items, fixed prices, paid at once, shipped by post | A shop, or a payment link to a product list at your provider |
The form also lets you say no. A cart takes payment for an order you might not be able to fulfil; a form lets you check capacity, ingredients or stock first, then confirm and ask for payment.
Fields that make an order usable
Every field you add costs completions, so ask only for what you'd otherwise have to email back about. For a typical made-to-order business that means:
- Name, email and phone. Phone matters for orders: something always needs a quick check.
- What they're ordering. A choice from your range, or a short description for custom work.
- Quantity, as a number field, so it can be used in a total.
- Options that change the price or the work: size, finish, flavour, personalisation text.
- When they need it, and whether it's collection or delivery. If delivery, the postcode.
- Notes, for allergies, access instructions or anything you didn't think of.
Put your lead time and order cut-off right beside the date field ("orders close Wednesday at noon for weekend collection"). It saves more back-and-forth than any other line on the page.
Totalling the order on the server
Published Anticode pages run no scripts, so there's no live calculator ticking up as someone types. Instead, a site function can run when the form is posted. The simplest kind is a formula: arithmetic over the form's fields, worked out on Anticode's server, such as quantity times unit price plus a delivery charge, with a lower unit price above a set quantity. Because it runs on the server, a visitor can't change the arithmetic in their browser. The total appears in the heading and message on the visitor's thank-you page, and a formula can refuse an order with its own message, such as one below your minimum quantity. Formulas work on numbers only, so an option written as words (a size or a flavour) can't change the price unless you give it a number field, or use the webhook route below.
If the total depends on something only you know (today's stock, a customer's account price) a site function can instead make a signed HTTPS call to your own endpoint, such as a Google Apps Script or a small server you run. Each call carries an HMAC anticode-signature header so your endpoint can check it really came from your site. Anticode never runs your code itself. The site functions feature page and formula functions explain both.
Where orders go
Each order is saved to your project, sealed at rest with AES-256-GCM, and can be emailed to you. From the dashboard you can also send each one to:
- Google Sheets
- One row per order, through an Apps Script web app. Good for a running order book you sort by date.
- Airtable or Notion
- A table you can move orders through: received, confirmed, made, collected.
- Telegram, Slack or Discord
- A message the moment an order lands, useful in a kitchen or workshop where nobody is watching an inbox.
- A webhook
- Anything else you already use, such as an order system that accepts incoming requests.
Each order is sent to a connector once, without retries, so it's worth keeping the email copy on as a backstop. The guide on form submissions to Google Sheets shows the setup.
Taking payment after you confirm
A form doesn't take money. When you confirm the order, send the customer a payment link from your own provider, such as a Stripe Payment Link made for that amount or a PayPal request, or take payment on collection. If some items always cost the same, the page can also carry buy buttons. An account has one payment link, from Stripe Payment Links, PayPal, Gumroad, Lemon Squeezy, Shopify or Whop, and every buy button opens it, so for several fixed-price items point it at a product list or multi-item checkout at your provider.
What this setup doesn't do
- No cart, checkout or payment inside the form. Payment happens later, through your provider.
- No order status for customers. There are no customer accounts on published sites, so updates go by email or phone.
- No stock levels or capacity limits. The form can't close itself when you're fully booked; change the page in a sentence ("orders are closed until Monday") when you need a pause.
- No automatic confirmation email to the customer. Anticode can email you; reply to the customer yourself or from a tool connected by webhook.
Questions people ask
Can the customer see the total before sending the order?
Not as they type, because published pages run no scripts. The formula works out the total on the server when the form is posted and shows it on the thank-you page.
How many orders can a free site take?
Free sites show a monthly allowance of submissions (100 by default); the rest are held until you upgrade. Paid plans are on the pricing page.
Can I use this for wholesale orders?
Yes. A trade order form with account name, product codes and quantities, sent to a spreadsheet, is a common use. Keep trade prices off the public page if they're confidential.