payinOPERATIONS MANUAL

Latest articles

Stripe Checkout custom fields: collect business choices and read the final answers

Choose suitable Checkout questions, keep stable keys and option values, and capture completed answers without confusing defaults, inventory or payment readiness.

Published; sources checked:

Hosted Checkout custom fields: type and limit selection, optionality, localization, typed completed values and correction snapshots. Excludes metadata propagation, inventory implementation, addresses and invoice customization.

Choose a question, not a product configurator

A developer selling clothing asked whether Checkout custom fields could collect sizes and enforce stock limits for each option. That is a real integration need, but also a warning about putting product decisions too late in checkout.[3] This guide separates a small business questionnaire from catalog selection and explains how to read the customer's completed answers. It does not cover metadata propagation.

Recommended decision: use a custom field for a simple, non-sensitive instruction that does not determine the price or reserve scarce inventory. For size-dependent stock or paid upgrades, resolve the product selection in your application before creating Checkout. A dropdown answer should not be treated as an inventory reservation or an instruction to charge more.

Budget the fields before building the form

Stripe permits up to three custom fields, excludes setup mode, and supports text, numeric and dropdown inputs. Text supports up to 255 characters, numeric fields up to 255 digits, and dropdowns up to 200 options. Stripe warns against collecting personal, protected, sensitive or legally restricted information this way.[1]

Write down each question's operational purpose and who consumes its answer. Choose dropdowns for a controlled set of instructions; use text only when a fixed list cannot express the answer. Fields are required by default; set optional=true deliberately for information the order can proceed without.[1] Define what an omitted answer means before making the field optional.

Separate machine identifiers from display labels

Each field needs a unique key. The API specifies an alphanumeric key of up to 200 characters. Dropdown options have separate customer-facing labels and machine values; option values must be unique, alphanumeric and at most 100 characters.[2] Keep those identifiers stable when rewriting customer-facing copy.

Illustrative configuration: an order-wide packing preference uses key=packing, type=dropdown, and values standard or minimal, both offered at the same price. Localize the labels yourself: Stripe does not translate custom-field labels, although the Session locale can match their language.[1] This is a design example, not an executed request.

Read the completed value, not the default

Stripe sends completed custom fields in checkout.session.completed. Default values merely prefill the payment page.[1] In the event's Session, locate the field by key, inspect type, and read dropdown.value, text.value or numeric.value. Numeric answers are strings containing digits, not numeric JSON amounts.[2]

  1. Resolve the completed Session to the intended internal order.
  2. Build a key-to-answer map rather than depending on array positions.
  3. Check the expected type and allowlisted dropdown value; distinguish an omitted optional answer from an unknown value.
  4. Store the answer snapshot with its Session identifier and your question-schema version.

These are recommended application controls. Keep answer capture separate from authorization to ship: a complete Session can still have payment processing in progress.[4] Do not release an order simply because its packing choice is present.

Handle corrections without silently rewriting history

Stripe documents Dashboard lookup and editing of custom-field values, plus export of those values. For subscription-originated purchases, it documents finding the creating Session using the subscription filter.[1] Therefore, do not treat a later Dashboard value as necessarily identical to the completion-time answer.

Recommended correction policy: preserve the original snapshot, record an authorized correction separately, and check whether packing has started before changing the work order. Do not assume a Dashboard edit updates your database. Route unfamiliar keys or unavailable options for review instead of silently replacing them with defaults.

Acceptance checklist

  • Change a prefilled packing option and verify the consumer reads the submitted value.
  • Leave an optional field blank and confirm the documented fallback.
  • Reorder fields, translate labels and replay the event without changing the order twice.
  • Exercise an unknown value, a missing required business answer and a post-completion correction.
  • Keep an unpaid order pending even when all answers are present.

These checks are proposed, not performed. This is documentation research for hosted Checkout, not a live-account test or a PayIn capability claim.

Sources and dates

Retrieved September 23, 2026. Official sources do not state publication or update dates. They do not establish country-specific account eligibility; no universal regional availability is claimed. The community question demonstrates qualitative demand, not current product behavior or search volume.

More guides