Skip to content

Checkout Fields

Some products need information from the purchaser before you can fulfil them: a student's name for a personalized item, artwork for an ad, a dedication message for a program tribute.

Checkout fields let you define exactly what to ask for, per product. You build them in the Custom checkout fields section of the product form.

This replaced three fixed options

Older versions of myShop had three checkboxes — school entry, student name entry, and purchaser-provided images. Those are gone. Anything they did, checkout fields do with more control, and you're no longer limited to one of each.

Free purchases

When a promo code reduces a shopper's cart total to $0, they can complete the order without entering card or PayPal information. The order is still recorded in Track Orders and in exports, so free samples, complimentary tickets, and fully sponsored purchases stay part of your records.

The cart must actually total $0 after its discount. A promo code that only reduces the price still takes the shopper through the normal payment process.

The six field types

Type Use it for
Short text A name, a jersey number, a short line of copy
Description / message Longer text — a dedication, special instructions
Image / file upload Artwork, logos, photos, a completed PDF
Website A sponsor's URL for an ad or program listing
School Which school the purchaser is associated with
Student's name The student the purchase relates to

Configuring a field

Each field you add has:

  • Label — what the purchaser sees. Write it as a question or an instruction: "Student's name as it should appear on the jacket" beats "Name".
  • Placeholder — an optional hint shown in the empty box. Good for format examples.
  • Required or optional — required fields block checkout until filled.
  • Ask the purchaser — how often the field appears: for each item, once for this product, or once per order. See How often each field is asked.
  • Display order — the order fields appear in.

Text-style fields (short text, description, website, school, student's name) also take a character limit. Use it where space is physically constrained — embroidery, a program line, an engraving.

File uploads

Upload fields have one extra setting:

  • Allowed file types — restrict to the extensions you can actually use (jpg, png, pdf). Worth setting: it stops you receiving a file your printer can't open.

The maximum file size is 10 MB, which comfortably covers print-resolution artwork. That limit is set by myblueboard and isn't something you change — the product form shows it so you know what purchasers are held to. A purchaser who picks a larger file is told immediately and asked to choose another.

Uploaded images preview as thumbnails when you review the order, as long as they're a browser-renderable format (JPG, PNG, GIF, WebP, BMP). Anything else — including HEIC, which is what iPhones produce by default — shows as a download link instead. If you need thumbnails, exclude HEIC from your allowed types so purchasers convert before uploading.

Repeatable fields

Turn on allow multiple and set a maximum instances number, and purchasers can add more than one response to the same field.

This is what makes memorial pages, sponsor listings and multi-name orders work: one "Name to honor" field set to allow up to ten instances, rather than ten separate fields.

By default, fields are captured per unit purchased — someone buying three personalized items is asked for each item's details separately, so you get three sets of answers rather than one. You can change that per field; see below.

How often each field is asked

By default a field is asked for every item purchased. Someone buying three personalized jackets is asked for three names. That's right for anything specific to the individual item, and wrong for anything that's the same no matter how many they buy — asking a purchaser to type the same school four times is how you get four slightly different spellings.

Ask the purchaser controls this, per field:

Setting The purchaser is asked Use it for
For each item Once per item — quantity 2 asks twice A student's name, a dedication, artwork for one specific ad
Once for this product Once, whatever the quantity Anything that applies to the whole line: a homeroom, a delivery preference
Once per order Once for the entire cart Details that don't change between products — their school, a family name

Once per order is shared across products. If someone has four different hoodie sizes in their cart and every one of them asks for a school, they answer once, in an About your order box at the top of checkout — not four times.

Two things worth knowing about it:

  • If two products in the cart ask the same question and only one marks it required, it's treated as required. The product that needs an answer still gets one.
  • The answer is recorded against every product in that order that asked for it, so it shows against each item in Track Orders and in your exports.

Changing this setting affects future orders only. Orders already placed keep the answers they were given.

Where responses show up

Responses attach to the order and appear in Track Orders alongside the rest of the order detail. They're also included in exports — both the per-product CSV and the submissions ZIP, which bundles every uploaded file with a manifest tying each one back to its order.

If a required field comes back empty

Required fields are enforced at checkout, so in normal use you get an answer. If one does arrive empty — a purchaser on an unusual browser, an upload that fails mid-payment — the order still completes rather than failing after the purchaser has paid, and their confirmation invites them to supply what's missing.

Check for blanks before you start fulfilling a batch. The per-product export is the fastest way to spot them: an empty cell in a Response: column is a purchaser you need to chase.

Editing and removing fields

You can edit a field's label or remove it later, and historical orders stay readable. Each response stores a snapshot of the label and type it was collected under, so an order from last season still shows the question as it was asked at the time — not the question as it reads today.

That means renaming a field is safe. It does not rewrite history, and it does not corrupt past orders.