Ahhhh .. the joys of development are again prevailing! ;-) The work involved from the third 3.0 alpha release onwards actually produces frontend changes that can be proudly shown rather than writing again about the backend changes for the new framework that was worked on in the MS3 -> 3.0alpha1 and 3.0alpha2 releases.
Not that the backend changes were not needed; it’s just more exciting to work on something where the results can not only be experienced (performance, security, optimizations, ..) but also seen!
Last week I was in contact again with some payment providers regarding test accounts and technical implementation documentation for the work involved in updating the payment modules for the 3.0alpha3 release. The contact made here will definitely strengthen during the next couple of weeks as the work involved here matures, and will also increase due to the amount of payment providers out there.
The first payment gateway I received a test account and technical documentation to was Switzerland based SaferPay. They have two methods to perform transactions over; the primary means is through a binary/executable file they provide that communicates with their gateway (similar to using cURL), and the second means is via SOAP. As I didn’t have sufficient documentation for the SOAP method I went ahead and played around with the binary/executable method. What I don’t like about this method is that PHP needs access to the exec() function, and that is passes the credit card number to the binary/executable as an argument. This can be dangerous for a shared server environment, and hope to have some implementation questions answered during the new week.
The SOAP method should address such issues for shared server environments, and think that those using the binary/executable file are on secured dedicated servers anyway.
The work made here and the addition of the SaferPay payment module is the first payment module that is able to communicate to its payment gateway after an order has been processed. This allows the store owner to perform transaction actions to an order via the osCommerce Administration Tool, and no longer relies on doing the same actions on the payment gateway administrative interface. This should however be considered a “luxury” feature and not a “payment gateway administrative interface” replacement 8)
The SaferPay gateway allows the osCommerce Administration Tool to “approve” and “cancel” a financial transaction to an order, and to “inquire” about it’s current status.
The default transaction method for the module is to keep the financial transaction on hold. That means the checkout procedure checks to see if there are sufficient funds on the credit card, and holds it until the store owner is ready to accept the payment and to ship the products ordered.
Attached is a movie demonstrating this. There is a new “Transactions History” tab added to the Order Edit page where the transaction history is shown. The statuses are still shown as numbers but will be replaced with textual equivalents similar to how the Order Statuses are implemented. (Please also note that this is not the final layout of the order edit page)
After the order has been processed, the financial transaction status of the order changes on the payment gateway from “Reservation” to “Payment” to “Cancellation Payment”, performed via the osCommerce Administration Tool. The “inquiry” transaction action is also automatically performed after the financial transaction status changes to provide more information to the store owner on the same page. This will end up being a parameter for the payment module as it requires two requests to the payment gateway to be made, which slows things down by .. err.. 1 request ;-)
I’ll keep the blog up to date on the progress made here with this and the other payment modules.





