Nur Bares ist Wahres
The checkout procedure has been worked on again to meet the requirements of some payment modules, with the ordering process now being split up into numerous class methods. The logic has returned to the order class (now osC_Order) after being moved over to the checkout/process content module.
This provides a level of flexibility where it is no longer required to go through the checkout/process page to process an order, and can now be done practically anywhere.
The class methods now used to process an order currently consists of:
osC_Order::insert()
osC_Order::remove()
osC_Order::process()
osC_Order::sendEmail()
The new logic now creates the order in the database via the insert() method before contacting the payment gateway for the transaction to occur. This allows the correct order ID to be passed with the transaction request to the gateway, and only processes the order if the transaction was successful. (This replaces what I blogged about previously regarding the random and unique order transaction ID)
For payment modules that require no external interaction, such as Authorize.net, the calls to insert() -> process() -> sendEmail() are performed in the payment modules process() method.
Payment modules to date have had before_process() and after_process() class methods which has now been replaced with one single process() method.
The execution is different for payment modules that do require external interaction, such as PayPal, where the order is inserted into the database on the checkout/confirmation page, and processed at a later stage.
This behaviour was introduced with the official PayPal IPN payment module contribution made for the 2.2 Milestone 2 release, and does have some drawbacks due to technical related issues.
As most community members are aware, if a customer makes an order through the normal PayPal payment module and does not hit the last continue button on PayPal’s site to return back to the store, the order would not have been created in the database and the store owner receives a payment email from PayPal without an order to reference it to. This problem was addressed with the PayPal IPN contribution where the order is inserted on the checkout/confirmation page and processed on the callback request PayPal makes to the online shop that is performed when the payment has been confirmed by the customer.
The reason the order is created on the checkout/confirmation page and not when the customer returns to the store after paying at PayPal or when the callback request from PayPal is received, is incase the customer does not hit the last continue button on PayPals site to return back to the store, and incase the session validation features of osCommerce prevent the callback request from resuming the session of the customer (when the session ID exists in the callback request URL).
The negative aspect of this approach is that if the customer did not confirm the payment at PayPals site, an order entry would still exist in the database marked with the order status of “Preparing”. Logic exists in the osC_Order class to replace orders marked as “Preparing” when the customer visits the checkout/confirmation page multiple times (incase they wanted to add a product to their cart at the last minute) to avoid the orders database table being flooded with “Preparing” order entries.
The drawback here is the possibility of the order still being deleted (replaced) even if the customer confirmed payment at PayPals site. This can happen only if the callback request is delayed and if the customer does not hit the last continue button at PayPals site to return to the store normally, but uses the browsers back button (or a bookmarked link) to return to the store and goes through the checkout procedure again to make another order.
This situation would be rare though and have confirmed with several people directly that they had not experienced this with the official PayPal IPN payment module contribution for 2.2MS2.
These are just some examples of the technical issues involved when working on the payment modules, the checkout procedure, and again on the payment modules if one needs special requirements 
An addition to the checkout procedure is a re-introduction of the credit card class that was removed a while ago. The Credit Card Types Administration Tool page is now combined with the new credit card class, where each credit card contains a perl based regular expression pattern to match against provided credit card numbers. Two new parameters are provided to the store owner to control the pattern matching behaviour, where it can be enabled or disabled for server side matching (through PHP) and on the client side with javascript.
The benefits of perl based regular expressions (preg) over posix based regular expressions (ereg) is that the same pattern can also be used for client side javascript matching.
In addition, the credit card payment modules now share a relationship with the Credit Card Types where specific credit cards can be enabled for specific payment modules.
This is shown nicely at the end of the attached movie, demonstrating the post transaction actions again with Authorize.net and PayPal.
Now that my development branch is stable again, I’ll be able to forward a pre3.0alpha3 version to the payment service providers to start the certification phase. A page on the support site will be added next week to show the progress made here, and will mention it in a blogging entry as soon as it is ready for public viewing.
Here is a second movie demonstrating the post-transaction actions of 3.0 for your viewing pleasure 