Documentation You are here: start » v » 0.7.0 » checkout

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
v:0.7.0:checkout [2011/05/11 09:08] – [Checkout Template Customization] foxybrettv:0.7.0:checkout [2017/04/26 07:02] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== The Most Efficient One-Page Checkout Available ====== ====== The Most Efficient One-Page Checkout Available ======
  
 +===== What Is the Checkout? =====
 +When we refer to the "checkout" we refer to the page (or pages, in other systems) where the customer enters their billing and payment information, and where they submit their order for processing. In general, [[.:cart|the cart]] comes before the checkout, and [[.:receipt|the receipt]] is displayed when a successful checkout is processed.
 +
 +===== How and Why FoxyCart's Checkout Is Different =====
 One of the major piece we wanted to simplify and improve upon when we started FoxyCart was the checkout page. In addition to making it a very dynamic one-page checkout, we also revolutionized (big hypey word, we know, but we feel it's true) the way customers choose between a guest checkout or creating an account. One of the major piece we wanted to simplify and improve upon when we started FoxyCart was the checkout page. In addition to making it a very dynamic one-page checkout, we also revolutionized (big hypey word, we know, but we feel it's true) the way customers choose between a guest checkout or creating an account.
  
-The checkout is also highly flexible, and can be modified in a variety of ways.+No longer will your customers be presented with inputs for their email and password, only to submit the form and be told that they don't have a user, and that if they'd like to register they can click the teeny tiny link in the bottom right. Odds are they don't care about registering; they just want to buy your wares as quickly as possible. Our unique approach automatically determines whether the customer has an account, and also presents easy options to checkout as a guest user if desired (and configured for your store). 
 + 
 +The checkout is also highly flexible, and can be modified in a variety of ways. HTML, CSS, and JavaScript are all available for you to perform advanced customizations both of the design and the functionality.
  
 ===== Checkout Template Customization ===== ===== Checkout Template Customization =====
 <wrap tip>The checkout can be quickly, easily, and automatically styled to match //your existing site's templates//.</wrap> This is care of "AutoMagiCache". There are screencasts, examples, and lots of documentation about [[.:templates|customizing your checkout template]]. And really, it's quite easy and automatic, so we strongly recommend reviewing the screencasts. A customized checkout can significantly boost conversion rates, so it's likely well worth your time to style your FoxyCart-powered checkout to match your site. <wrap tip>The checkout can be quickly, easily, and automatically styled to match //your existing site's templates//.</wrap> This is care of "AutoMagiCache". There are screencasts, examples, and lots of documentation about [[.:templates|customizing your checkout template]]. And really, it's quite easy and automatic, so we strongly recommend reviewing the screencasts. A customized checkout can significantly boost conversion rates, so it's likely well worth your time to style your FoxyCart-powered checkout to match your site.
  
-===== Adding Custom Checkout Fields ===== 
  
-==== Overview ====+===== Errors On the Checkout ===== 
 +==== "Hard" Errors ==== 
 +Any "hard" errors will be displayed for your customers (and in your store's error log), and will generally be supplied by your payment gateway for things like a declined card, a mismatched billing address, or other issues that impact payment. See [[:primer:errors|Errors and What To Do About Them]] for more info.
  
 +==== "Soft" Errors ====
 +FoxyCart's checkout also employs JavaScript validation to provide for quick feedback if a required field is left empty, if a shipping option is unselected, an email address malformed, or etc. These errors will not show up in your store's error log.
 +
 +==== Other Errors and Unexpected Behavior ====
 +Because the checkout is complex, there are a variety of things that can go wrong if you're customizing things. If things aren't happening as expected...
 +  * Check for JavaScript errors using [[http://getfirebug.com/|Firebug]] or the comparable debugging system in your browser of choice.
 +  * Check for required fields you may have hidden via CSS.
 +  * Make sure your checkout template has a doctype, and is free of major validation errors.
 +  * [[http://forum.foxycart.com/|Post on our forum]] for additional help.
 +
 +
 +===== Adding Custom Checkout Fields =====
 +==== Overview ====
 Sometimes it is necessary or desirable to include additional input fields on checkout, such as: Sometimes it is necessary or desirable to include additional input fields on checkout, such as:
   * Checkbox to require Terms of Service agreement.   * Checkbox to require Terms of Service agreement.
Line 79: Line 99:
  
 ==== What to name your fields ==== ==== 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. 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.
  
Line 85: Line 104:
  
 ==== What about Receipts and the Datafeeds? ==== ==== What about Receipts and the Datafeeds? ====
- 
 The custom fields will be inserted at the bottom of your your receipt (after checkout), as well as in any emails that include the ''^^receipt^^'' placeholder. The custom fields will be inserted at the bottom of your your receipt (after checkout), as well as in any emails that include the ''^^receipt^^'' placeholder.
  
 Custom checkout fields are included in all XML datafeeds from version 0.3. Custom checkout fields are included in all XML datafeeds from version 0.3.
 +
 ==== What if I'm using multiship and I need a custom field per shipto? ==== ==== What if I'm using multiship and I need a custom field per shipto? ====
- 
 No problem! Just wrap your custom fields in ''^^multiship_custom_begin^^'' and ''^^multiship_custom_end^^'' and you're good to go. No problem! Just wrap your custom fields in ''^^multiship_custom_begin^^'' and ''^^multiship_custom_end^^'' and you're good to go.
  
  
 ==== A Note about Checkboxes ==== ==== 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. **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.
  
Line 136: Line 153:
  
 <wrap important>You should not be collecting passwords using custom fields,</wrap> as they will be stored in cleartext and not hashed in our system. Though we work hard to keep our systems secure, it's just not a good idea to store passwords without a strong hashing algorithm. <wrap important>You should not be collecting passwords using custom fields,</wrap> as they will be stored in cleartext and not hashed in our system. Though we work hard to keep our systems secure, it's just not a good idea to store passwords without a strong hashing algorithm.
 +
 +
 +===== Pre-Populating the Checkout with Customer Information =====
 +Though we generally recommend [[.:advanced:sso|Single Sign-On]] and synching [[.:customers|customers]] via [[.:advanced: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.
 +
 +Pre-populating is done by passing in [[.:cheat_sheet#customer_information_pre-population|specific customer fields]] to [[.:cart|the cart]]. Once the customer fields have been passed into the cart, they will remain there just like [[.:session_variables|session variables]], and when the checkout is loaded the values will be inserted into the appropriate fields on the checkout. Note that this does //not// impact the user's ability to change the data, nor does it impact the customer's ability to checkout as a guest or to create an account.
 +
 +
 +===== Other Checkout Actions =====
 +The checkout is primarily used to pay for new purchases, but there are certain other situations that arise that are still handled through the checkout. It's important to understand when your checkout can be used for other purposes so you can design and style accordingly.
 +
 +==== Subscription Cancellation ====
 +{{ :v:0.7.0:checkout.sub_cancel.png?direct&200|An example of a subscription cancellation checkout page}}
 +If you're doing [[.:products:subscriptions|recurring billing]] you may likely be using ''sub_cancel'' links in your [[.:emails|email receipts]], which will allow your customers to follow a ''sub_token'' link with ''sub_cancel=true''. This will immediately redirect the customer to your checkout, but it is a highly streamlined checkout experience geared only towards allowing your customer to cancel their subscription. As you can see in the example to the right, the checkout includes just three main pieces:
 +  - The normal email + password authentication section.
 +  - The cart.
 +  - The button that is normally labelled something like "checkout" or "confirm your order", but is now labelled "Cancel My Subscription". (This text can be modified in your store's [[.:i18n|language section]].)
 +
 +It is important to note that the password is still required in order to confirm the cancellation. This is to prevent an unauthorized user from modifying a subscription they aren't supposed to be modifying.
 +
 +==== "Update Info" Requests ====
 +If the ''cart'' parameter is set to ''updateinfo'', the cart  will immediately redirect to the checkout in "updateinfo" mode. Simply put, this will process an empty transaction, thus allowing the customer to update their password, address(es), or payment info. This updated information will be sent in a [[.:advanced:transaction_xml_datafeed|transaction datafeed]], but the [[:gateways:start|payment gateway]] will not be contacted during this checkout.
 +
 +The ''updateinfo'' process can be useful in certain situations, but especially if you're handling subscriptions you'll likely want to use the ''sub_token'' rather than the ''updateinfo'' approach.

Page Tools

Site Tools