> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How to ask customers for information at checkout

> Collect what you need to fulfil an order — checkout fields, internal fulfilment fields, customer attributes, and where the answers land.

<Card title="Open in TWICE Admin" icon="external-link" href="https://admin.twicecommerce.com/catalog/listings" horizontal>
  catalog/listings → Checkout Settings
</Card>

Some listings cannot be fulfilled from the order alone. The order says what was bought; it does not say what you need to know to hand it over.

What that is differs completely by operator, so read what follows as examples rather than a list to work from. Equipment fitted to the person needs their measurements. A used item may need the buyer to confirm they have read its condition report. A personalised sale needs the text to personalise. A catered booking needs to know about allergies. Your own list will look nothing like that one.

The **Checkout Settings** tab collects that. It holds three cards, and picking the right one is most of the work — they differ in who fills the field in and where the answer ends up.

## Prerequisites

<Warning>
  **Required permission:** listing manage rights. All four system roles hold them.
</Warning>

<Info>
  **Decide who answers, and whether the answer should outlive the order.**

  | You want                                                         | Use                                             |
  | ---------------------------------------------------------------- | ----------------------------------------------- |
  | The customer to answer, once per order                           | A **checkout field**                            |
  | The customer to answer, and the answer to stick to their profile | A checkout field of type **Customer attribute** |
  | Staff to record something during fulfilment                      | An **internal fulfilment field**                |
  | Every unit tied to a named person                                | **Always assign item to customer**              |

  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.
</Info>

## The Walkthrough

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.

    Then **Field name** (what the customer sees), **Placeholder** (optional hint text), and **Required**.

    Be sparing with **Required**. Every required field is a step between the customer and paying, and a field you merely find useful is not worth an abandoned checkout.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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

<AccordionGroup>
  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>

## Next Steps

<CardGroup cols={2}>
  <Card title="Checkout Settings tab" icon="list-check" href="/docs/catalog/listings/checkout-settings">
    The tab reference, field type by field type.
  </Card>

  <Card title="Customer attributes" icon="user-pen" href="/docs/customers/customer-tabs/attributes">
    The attributes a checkout field can bind to.
  </Card>

  <Card title="Multi-language content" icon="language" href="/docs/concepts/admin/translations">
    How field names and placeholders are translated.
  </Card>

  <Card title="Build a collection" icon="layer-group" href="/docs/guides/catalog/build-a-collection">
    The other side of merchandising — grouping what you sell.
  </Card>
</CardGroup>