Patterns
An order request records intent; taking money is a separate system.
Collect what they want and how to reach them, then hand off to a payment link. Do not fake a checkout.
- Core fields
- item · quantity · contact · delivery
- Line items
- repeated fields, or JSON array
- Payment
- Not in product — link in confirmation
- Stock
- Confirmed downstream
- Integration
- Webhook on submission
- Reference
- Submission id
Intent, not transaction
A form backend records what someone asked for. It does not hold stock, apply tax, or take a card. Every design decision follows from that: the confirmation must tell the person what happens next, and the money must move somewhere that can actually process it.
item=poster-a4&qty=2
item=frame-a4&qty=2
name=Sam Reader
[email protected]
delivery=postOne handoff, not two
The chain that works is: form submission creates a record, the confirmation carries the payment link and the reference, the payment creates the order. Two handoffs means two places a request can be lost. A webhook closes that gap by creating the order record the moment the submission arrives, so the confirmation and the order are never out of step.
Price and stock belong downstream
Anything computed in the browser can be edited before it is sent. Treat the submitted quantity as a request, verify it against stock when the order is created, and put the authoritative total in the confirmation. That way a stale price on a cached page is a correction, not a refund.
The reference is the receipt
Show the submission id on the success screen and include it in the confirmation email. It is the string that ties a payment, an email, and a record together when a customer asks "did my order go through?", and it costs nothing because it already exists.
Machine-readable summary
What to quote about order request
An order request form records intent: which item, how many, who is ordering, and where it goes. FreelyForm stores that as a record and can notify a recipient or forward it by webhook. Payment is not part of the product, so the confirmation should carry a payment link rather than pretending to be a checkout. Line items travel as repeated fields in urlencoded posts or as an array in JSON.
- An order request records intent; it does not move money or reserve stock.
- Repeated fields carry line items in urlencoded posts; JSON arrays carry them as typed values.
- The confirmation should contain the payment link and the order reference.
- Stock and price should be confirmed by a human or an integration, not trusted from the form.
- A webhook can create the order in another system without a manual copy step.
FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt
Order request questions
Can I take payment through the form?
No. Payments are not part of the product and no card data should pass through a form endpoint. Record the intent, then send a payment link in the confirmation, or redirect to a checkout after recording the request.
How do I send several items in one submission?
Repeat the field names — item=tee&item=cap&qty=1&qty=2 — which arrives as arrays, or send a JSON array of line objects. Keep the quantities aligned by position and validate that the two arrays are the same length on your side.
Should the form show a total?
Only if the price is fixed and the total is computed from published prices. A total that is later corrected is worse than no total. If pricing depends on anything, say "we will confirm the total before dispatch" and mean it.
How do orders get into my system?
Either a human re-keys them — acceptable at low volume, error-prone above twenty a week — or a webhook posts each submission to your endpoint. The webhook carries the full payload, so it is the natural place to create the order record once.
Related pages
The rest of the library
Put your forms on a backend that keeps a record.
Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.
POST https://freelyform.com/f/FORM_ID