Checkout System

The checkout system is designed in a modular fashion to support many different checkout workflows. The idea is similar to the way an operating system kernel functions, passing control from one process to the next and determining which process to give control of the system to.

To begin, here is some terminology as it relates to the various classes provided by SpeckCheckout:

• SpeckCheckout\Strategy\AbstractCheckoutStrategy - this is the object that contains all of the checkout steps and the information required in order to complete an order (shipping/billing address, payment method, order object, user information, etc.). It is persisted throughout the checkout and saved with the user's session data. For a usage example, see SpeckCheckout\Strategy\BasicCheckoutStrategy
• SpeckCheckout\Strategy\Step\AbstractStep - this abstract consists of two main children -- Off-Site and On-Site steps.
• SpeckCheckout\Strategy\Step\AbstractOffSiteStep - this step will provide a redirect URL and parameters for the checkout service to redirect the user to. This could be used for off-site payment or shipping information. It also accepts a response, which should be set then the user is redirected back to Speck Commerce.
• SpeckCheckout\Strategy\Step\AbstractOnSiteStep - this step allows you to redirect a user to a route defined by any module in your application. You may perform any set of actions before redirecting back to the checkout's main route.
• SpeckCheckout\PaymentMethod\AbstractPaymentMethod - these payment methods are a framework for creating on-site payment steps. Methods for paying via check, fax, phone, purchase order, and quote are packaged with SpeckCheckout and can be used as examples for on-site payment steps. These steps are currently utilized only by SpeckCheckout\Strategy\Step\PaymentInformation. Check config/module.config.php for an example of how to enable/disable different payment methods.

When the user is redirected to the checkout route (/checkout by default), the CheckoutController will call the checkout service to fetch the strategy to be used. At this point, it will determine the first step in the strategy's chain of steps and redirect the user to the URL or route defined in that step. When that step is finished with whatever processes it needs in order to consider itself complete, it should set its $complete property to true and redirect the user back to the checkout route (again, /checkout is the default).

For example, in the basic checkout flow provided by SpeckCheckout, the checkout processes begins at /checkout and the first step is SpeckCheckout\Strategy\Step\UserInformation. Once the relevant user information is collected (i.e. the user is logged in and has selected billing/shipping addresses), the UserInformation object is marked as complete and the user is redirected to the checkout route. At that point, the PaymentInformation step takes over and performs its logic.

The minimum components for an on-site checkout step are typically a SpeckCheckout\Strategy\Step\AbstractOnSiteStep and a controller (the OrderReview step is a good example of a simple case).

An off-site checkout step can be as simple as just a SpeckCheckout\Strategy\Step\AbstractOffSiteStep.

It is up to each checkout step to fill in the strategy object with relevant information, and it is up to the application developer to ensure that there the proper steps to fully populate the strategy. Otherwise, you may end up without all of the information necessary to complete an order.