
Checkout Application
The number of steps during the checkout procedure has been drastically reduced with the new Checkout Application. The checkout procedure no longer starts at the shipping page but now heads directly to the confirmation page which takes care of all dependencies for the order.
The new Checkout Application is simply accessed with:
index.php?Checkout
and works exceptionally well with the flexible Product Types implementation to gather all the information required to complete the order.
Product Types
Each product (or product variant) is assigned a Product Type group which define certain conditions that must be met when a Product Type action is called. Examples of Product Type actions are:
| AddToShoppingCart | Called when products are added to the shopping cart |
| PerformOrder | Called when the Checkout Application is initialized |
Each Product Type action is assigned one or more modular conditions which are checked in the specified order and return either true or false depending on the condition to meet. Failed conditions can optionally execute an onFail() function to help pass the condition. Example conditions are:
| RequireBilling | Passes true if a billing address and billing method is available |
| RequireShipping | Passes true if a shipping address and shipping method is available |
| RequireCustomerAccount | Passes true if a customer is logged in with their account |
| RequireStock | Passes true if sufficient stock is available |
Most, if not all, products would need the RequireBilling condition for the PerformOrder action. Physical products for shipping would obviously also need the RequireShipping condition, whereas digital products would not.
Want to force a customer account for orders? That’s possible with the RequireCustomerAccount condition. Should customers be logged in to add certain products to their shopping cart? No problem. Simply assign the AddToShoppingCart action and the RequireCustomerAccount condition to its Product Type group. Done.
Creating new conditions is amazingly simple with developing new modules that check on the conditions to meet.
Here is how the RequireCustomerAccount condition module is developed:
<?php namespace oscommerce\OM\Site\Shop\Module\ProductType; use oscommerce\OM\Registry; use oscommerce\OM\OSCOM; use oscommerce\OM\Site\Shop\Product; class RequireCustomerAccount { public static function isValid(Product $OSCOM_Product) { $OSCOM_Customer = Registry::get('Customer'); return $OSCOM_Customer->isLoggedOn(); } public static function onFail(Product $OSCOM_Product) { $OSCOM_NavigationHistory = Registry::get('NavigationHistory'); $OSCOM_NavigationHistory->setSnapshot(); osc_redirect(OSCOM::getLink(null, 'Account', 'LogIn', 'SSL')); } } ?>
Easy.
Intelligent Checkout
The Checkout Application intelligently gathers the information required to process the order. Both RequiredShipping and RequiredBilling would be common conditions to meet for the PerformOrder action, and would operate with the following workflow:
- If no shipping address is defined, automatically use the default customer address if one exists or present the new address form.
- Automatically select the cheapest shipping method available for the order.
- If no billing address is defined, use the shipping address.
- Automatically select the first payment method available for the order.
- Present payment method on the confirmation page (eg, credit card details).
- Provide links to change the shipping address, shipping method (eg, Express Shipping), billing address, and payment method on the confirmation page.
- Process the order once confirmed.
For a customer that is logged in, all information required for the order is already available and is directly taken to the checkout confirmation page. For guests, the minimum checkout flow is 2 steps with the shipping address form and confirmation page.
There is still plenty of room for improving the user experience as described previously with <a href="http://blogs.oscommerce.com/2009/12/16/london-public-meet-up/”>mockups of how the Checkout Application can function.
We look forward to extending this flexibility in future releases to also properly support services that are sold with recurring billing.
Community Feedback
Feedback to this blog entry can be posted on the following topic in the community support forums:
<a href="http://forums.oscommerce.com/topic/358932-oscom-v30-framework-optimized-for-php-v53/”>http://forums.oscommerce.com/topic/358932-oscom-v30-framework-optimized-for-php-v53/

July 13th, 2010
administrator 






