Please let us know who referred you.
This code will then be inserted in your checkout page, right under the "almost done" heading on the default checkout template (above the password entry, terms of service, and the main checkout button). Go ahead and load up your checkout to see what you just added. It should look something like this:
{{ https://i.ibb.co/5KLtPvy/foxycheckout.png |Thanks to Corganics.com for beta testing 2.0. That's why they're on our screenshots :)}}
Note that the HTML we've entered here can be anything at all, but this example is using the same structure as the default template. That way it automatically gets the appropriate styling.
Also note the use of ''data-fc-error-for'' on the container div and ''data-fc-required'' on the input which will automatically make that field required for checkout and color the container with an error class if the customer attempts to checkout without adding a value there.
{% set options = ["Social Media", "Advertising", "Online Search", "Word Of Mouth", "Other"] %}
This array sets out what options are present in the dropdown - so can be edited to add or remove options as required.
{% set options = ["Social Media", "Advertising", "Online Search", "Word Of Mouth", "Other"] %}
How did you hear about us?
==== A Radio Inputs Example ====
This example uses a similar approach as above, using a line of twig code at the top to set the values of the radio buttons as an array:
{% set options = {"Monday": "Monday - First Delivery", "Wednesday": "Wednesday - Second Delivery", "Friday": "Friday - Third Delivery"} %}
This array sets out what options are present in the radio inputs - setting both the value for the input ("Monday") and the label shown to the customer ("Monday - First Delivery") - so can be edited to add or remove options as required.
{% set options = {"Monday": "Monday - First Delivery", "Wednesday": "Wednesday - Second Delivery", "Friday": "Friday - Third Delivery"} %}
What day would you like to receive your delivery?
{% for option, label in options %}
{% endfor %}
==== A Checkbox Example ====
This is a quick example of a standalone optional checkbox field for the checkout.
Special note is that this also includes a hidden input with the same name as the checkbox included just above it in the HTML. This ensures that a value is always passed for the attribute with the transaction. A HTML form only accepts a single instance of a given input name, and a checkbox is only submitted if it's checked. With that in mind - if the checkbox isn't checked, then the hidden input is passed with the transaction. If the checkbox is checked though, then as it's the second input with the same name, it will be the value passed with the transaction.
==== A Multilingual Example ====
If your store is making use of [[..:template_sets|Template Sets]] to offer [[..:i18n|multilingual]] functionality on your store, you will also want to have your custom checkout fields show in the respective languages too. Here's a quick example of achieving that with the referral field from the first example above.
You would obviously need to expand this to match the different languages you offer on your store, as selected in the template sets language dropdown. This example assumes that the default template set uses English, but there are also template sets using German and French.
{% set referral_label = "Referred by... (required)" %}
{% set referral_description = "Please let us know who referred you." %}
{% if language == "german" %}
{% set referral_label = "Empfohlen von... (erforderlich)" %}
{% set referral_description = "Bitte teilen Sie uns mit, wer Sie empfohlen hat." %}
{% elseif language == "french" %}
{% set referral_label = "Référencé par... (obligatoire)" %}
{% set referral_description = "Veuillez nous indiquer qui vous a référé." %}
{% endif %}
{{ referral_description }}
==== What to name your fields ====
You can name your fields anything you want, but **we recommend using the underscore (''_'') for spaces**, and capitalizing your input names as you'd like them displayed. For all receipts, we will convert underscores to spaces for you.
For example, if you have '''', it will be displayed in your receipt (and email receipts) as ''Update List''.
==== Maintaining custom field values ====
With 2.0, our Twig templating system re-renders sections of the page at different points of the checkout process as customers trigger changes on the page. If a custom field is re-rendered, that would mean that it would be removed and re-added to the page, and wouldn't contain any data the customer had entered into it.
To maintain the value, you need to add some Twig logic to put it's value back when it's rendered. You can do that like this:
{% set options = ["Social Media", "Advertising", "Online Search", "Word Of Mouth", "Other"] %}
**If your field name includes accented characters, or if you're setting it up as a hidden field (one prepended with ''h:'')**, then you'll need to access it in a slightly different way using Twig's global ''_context'' object. This is because the colon or accented characters in the field name changes how it needs to be referenced, as a string rather than an object. If you had a field with a ''name'' of ''h:hidden_field'', you would access it as ''_context['h:hidden_field']'' in Twig.
==== What about Receipts and the Datafeeds? ====
The custom fields will be inserted at the bottom of your receipt (after checkout), as well as in any emails that include receipt placeholder.
Custom checkout fields are included in all API responses and the XML datafeed.
==== A Note about Checkboxes ====
**Checkboxes do not post** if they are unchecked. This is standard HTML form behavior, but it's worth noting, especially if you're using checkboxes for your XML datafeeds.
==== Required Fields ====
If your custom field needs to be required on the checkout, simply appending ''data-fc-required'' as an attribute to the element will facilitate that for you on the checkout. As an example, in an input that might look like this:
Here's some code to turn on phone requirement if there are shippable items in the cart. Place it in the footer section of the template configuration custom code option. If you need to set the phone field as always required - you can do that from the required fields template configuration option within your stores administration.
==== "Sensitive" Custom Checkout Fields ====
By default, all custom checkout fields will be emailed as part of the email receipt sent to both the customer and the store's email address.
Please enter your Secret Account ID:
"Sensitive" fields are displayed in the admin's transaction view, and are sent in the XML, but are not emailed.
Adding the following Twig code before the input in the page would prepopulate the input with a value that was passed through the cart as a hidden session attribute by appending it with ''h:'', like ''h:Referred_By'':
{% if Referred_By is not defined %}
{% set Referred_By = "" %}
{% for key, custom_field in custom_fields %}
{% if key == "Referred_By" %}
{% set Referred_By = custom_field.value %}
{% endif %}
{% endfor %}
{% endif %}
==== Passing Custom Fields to the Custom Shipping Code ====
Include a data attribute of ''data-fc-shipping-custom-field'' to capture the information from a customer on the checkout related to the shipping. Review [[https://wiki.foxycart.com/v/2.0/shipping#passing_custom_fields_to_the_custom_shipping_endpoint|this link]] for complete information on custom fields (''fx:custom_fields'') in custom shipping code or endpoint using ''data-fc-shipping-custom-field''.
===== Pre-Populating the Checkout with Customer Information =====
Though we generally recommend [[.:sso|Single Sign-On]] and synching [[.:customers|customers]] via [[.:api|the API]], there are certain situations where you may want to pre-populate the customer's billing or shipping fields without using SSO or the API.
Within that function, you can either return ''true'' or ''false'', which will either allow the checkout or block it respectively.
So for example if you had an age input and needed to ensure that only someone aged 18 or over can checkout, that code might look like this:
This type of setup can be expanded to show and hide error messages similar to how FoxyCart does with the default fields also.
===== Customising which Credit Card types are allowed on your Checkout =====
In some situations it is necessary to not allow certain credit cards to be used on a store, a common example being the need to prevent American Express cards due to a payment gateway restriction. You can customize that in the template configuration page in the admin.