Open in TWICE Admin
catalog/listings → Checkout Settings
Prerequisites
Decide who answers, and whether the answer should outlive the order.
A customer attribute is the one worth thinking about in advance. It writes to the customer’s profile, so a returning customer’s details are already on file the next time they order. A plain text field asks again every time.
The Walkthrough
1
Open Checkout Settings and decide on assignment first
Open the listing and go to Checkout Settings. The top card is Always assign item to customer — configure if the item should be always assigned to a customer or not. If enabled, we will always ask for customer name in the checkout.Turn it on for anything personal to the person using it: sized equipment, lift passes, course seats. Leave it off for a van or a marquee, where the order has one customer and the goods are not divided between people.Turning it on adds First Name and Last Name to the checkout fields table automatically. They are not editable and you cannot remove them individually — they come and go with the switch.
2
Add a checkout field
On the Checkout fields card — collect additional information from customer during checkout — click Add fields. A drawer opens.Type comes first, because it changes the rest of the form:
- Text field — free-form.
- Number field — numeric.
- Checkbox — one on/off. Use it for acknowledgements.
- Select field — a dropdown you define.
- Customer attribute — binds to an existing customer attribute. See the next step.
3
Use a customer attribute when the answer belongs to the person
Choosing Customer attribute replaces the name field with a picker of your existing customer attributes. The value is written to the customer’s profile rather than living only on the order.Anything that is a property of the person rather than of this particular order belongs here — measurements, a date of birth, a driver’s license number, a certification level. Ask once, and the answer is on the profile for every future order.One constraint the picker does not enforce. It offers every customer attribute, but only some formats can render at checkout. Text, number, boolean, date and datetime work — a date renders as a text input. Select, multiselect and formula attributes do not, and a field bound to one renders nothing at all on the storefront while the checkout still expects a value for it.So if you need a dropdown, build it as a Select field here rather than pointing at a select attribute. This step is where that decision gets made, and it is not recoverable by editing the field later.
4
Build the options, if it is a select field
Choosing Select field opens an options editor. Add option adds a row; the trash icon removes one. At least one option is required and names must be unique.Write the options as the answers you want to act on. “Beginner / Intermediate / Advanced” is a field your team can act on without reading it first. A free-text “experience level” is a sentence someone has to interpret at the counter.
5
Add internal fields for what staff record
The third card, Internal fulfillment fields — only visible to staff and can be used to guide manual steps during fulfilment — takes the same field types except Customer attribute.Use it for what your team fills in rather than the customer: the exact configuration a unit went out with, the serial number of the one that shipped, a grading note taken at dispatch, a prep checklist item.These never appear to the customer, at any point.
6
Translate what the customer will read
A checkout field’s Field name and Placeholder are translatable, but not while you are creating it. Save the field, reopen it, and a translate icon appears at the end of each of those two inputs.Two things do not translate: a Customer attribute field renders the attribute’s own name, so translate the attribute instead; and Select field option names are served in the source language in every checkout.Internal fields are staff-facing and are not translatable.
How do I know it worked?
Add the listing to a cart on the storefront and go through to the additional details step. Every non-internal field should be there, in order, with required ones marked. A field that is configured but does not appear is the customer-attribute format problem from step 3. That is the failure mode worth testing for deliberately, because nothing in the admin flags it — the field looks perfectly well configured in the table. Then place a test order and open it in admin. The answers appear against the line item they were collected for. Fields backed by a customer attribute also show up on the customer’s profile, which is the quickest confirmation that you picked the attribute-backed type rather than a plain one. Internal fields appear on the order for staff and are absent from the storefront entirely.Troubleshooting / Common Pitfalls
A field I configured never appears at checkout
A field I configured never appears at checkout
Most likely cause: it is a Customer attribute field bound to a select, multiselect or formula attribute. Those formats have no checkout representation, so the input renders nothing — while the checkout step still counts the field among those it wants a value for.What to do: replace it with a Select field and define the options here. Do not rely on the picker to prevent this; it offers every customer attribute regardless of format.
The field is there but asks the same returning customer every time
The field is there but asks the same returning customer every time
Cause: it is a plain Text or Number field. Those live on the order only.What to do: if the answer is a property of the person rather than the booking, switch to Customer attribute. Existing orders keep their answers either way — see below.
I edited a field and old orders still show the old wording
I edited a field and old orders still show the old wording
Working as designed. What is stored on an order is a snapshot of what was filled in — the field’s name, type and value as they were at the time. Editing or deleting the field afterwards does not rewrite orders that already collected it.What to do: nothing. It is what makes an old order still readable. It also means renaming a field does not retroactively fix a confusing label on past orders.
I cannot remove First Name and Last Name from the table
I cannot remove First Name and Last Name from the table
Working as designed. They are not real fields — they are added by Always assign item to customer and shown as non-editable rows so you can see what checkout will ask for.What to do: turn the switch off if you do not want them. There is no way to keep assignment and drop the name.
Customer attribute is missing from the type list
Customer attribute is missing from the type list
Cause: you are adding an internal fulfilment field. Internal fields deliberately exclude that type — an internal field is staff-recorded, and writing staff input onto a customer’s profile is not what the type is for.What to do: if the value belongs on the customer, it needs to be a checkout field.
Checkout has too many steps and customers are dropping out
Checkout has too many steps and customers are dropping out
Cause: usually required fields collected per item rather than per order. Fields are defined per listing, so a five-item order asks five times.What to do: review what is genuinely required to fulfil. A “special requests” box is rarely worth a required flag. Anything that is a property of the person rather than the item is better as a customer attribute, which is asked once and remembered.
Where do I set the deposit?
Where do I set the deposit?
Not here. The booking deposit is on the Pricing tab, not Checkout Settings — a common wrong turn because both feel like checkout concerns.
Next Steps
Checkout Settings tab
The tab reference, field type by field type.
Customer attributes
The attributes a checkout field can bind to.
Multi-language content
How field names and placeholders are translated.
Build a collection
The other side of merchandising — grouping what you sell.