VirtueMart handles the whole checkout process in the cart object. The cart object keeps all important information which characterise the shopper, products and selected options. This data is stored in the session.
The checkout process is handling the contract of sale. The checkout button indicates that the cart is only offering a contract. But using the confirm button means that the shopper signs the contract. This behaviour reflects the juristic process and complies with updated laws.
For registered shoppers that Login - if they have items in their cart and do not complete the checkout process - the cart data is stored and will be retrieved when next they login. This feature can be of great benefit to store owners, as their valued registered customers (who are not able to complete their order at a single visit) do not have to add all the products again on their next visit.
When viewing the cart a check is performed to ensure that all checkout requirements are met.
- If all requirements have been met a "confirm" button is shown
- If items still need to be selected or completed (e.g. Billign address) a "checkout" button is shown. The "checkout" button directs the shopper to the right steps to complete the missing information.
When the "One Page Checkout" is enabled in the vm configuration/checkout tab, the customer is only redirected to the Billing address input (as the other elements required for selection or input are shown on the Checkout page). Due user interaction, the cart may check in the background if all requirements are met and directly display the confirm button.
Shipping and Payment methods
The cart loads all published methods (e.g. Payment and Shipping) and checks the configured conditions.
Should the method/s and their configuration/s result in no method being available for this cart (e.g. cart weight does not match any shipping methods, posibbly due to a weight range configuration), it shows an error message with link to the configuration.
When only one method is matched, it is autoselected.
If more than one method is matched, the configurations "Enable Automatic Selected Shipment" or "Enable Automatic Selected Payment" options can be used to auto select you preferred method. To ensure that the user makes positive choice from the options displayed, do not configure these options.
Shopperfields display
The shopperfields have the attribute "show in cart", which makes it easy to extend the cart for any purposes. If two checkboxes are required and the second checkbox is checked, the js of the cart checks automatically in the background, if all requirements are meet and can directly display the confirm button.
For templaters and developers
The loaded cart object keeps all important information and is accessible in the layouts. It is usually available with $this->cart.
Sometimes the cart is not prepared, if this occurs, just use prepareCartData().
Cart update actions are now handled by the "updatecart" task in the controller. The reason is that almost any selection can influence another value or decision, so it is always necessary to recalculate and reload the whole cart.
Order creation during the checkout and further handling
When a shopper confirms an order in the cart, an order is created to be able to send an ordernumber to the payment provider. This also ensures that the price is fixed and stored in the order tables. This order has an internal status of "Pending" or code "P". When a cashier tells you in a physical store the amount to pay, he also already created a full order. All the calculation need for an invoice must be done and the same ways for the invoice. The order status P is fundamental for the correct functioning of the order system and should not be used for something else (if you do you are likely to run into problems sooner or later).
Regardles of whether your payment method directs the customer to an external payment page or if the payment completion is within your website, the user can always exit the process without actually completing the payment, as a result the order within your store will remain as "Pending". So it is important to keep an eye on the Pending orders.
If a customer does not complete the payment for whatever reason and continues to change or retry to complete their order in your store it is useful to consider using the "Pending" order that they last created (as this is unlikely to be paid).
Depending on the timing of the user interaction with your store, (VM considers the last hour to be significant - by default - there is a hidden config option for this time period) if less than this set time the "Pending" order will be deleted.
If the cart is loaded or from the session, VM deletes the saved ("Pending") order data with that orderId.
If this is a new session VM checks if there is an order for the same customer_number with order status P created within the last hour and if there is one, it will be deleted.
Unsucessful orders can still be seen by administrators in VM admin listings, but multiple attempts to complete an order can result in only one order being stored in the database.
You may have business processes in place to contact and attempt to take payment for such orders etc.
There is an hidden config to fine tune the time to search for a Pending order of a shopper.
The hidden config "reuseorders" can be configured with DateInterval format. The default format is PT30M for 30 minutes. (https://en.wikipedia.org/wiki/ISO_8601#Durations)
For shopowners that want to see all user order confirmations without reusing them, just set as the value as hidden config to 0. This may be useful to identify potential payment processor issues, or due to internal business processes where reuse of orders may cause issues.