We're a Dutch company that resells the LightSpeed Retail POS system: [url removed, login to view]
An important part of this POS system is an eCommerce module that works with a product from the same company called 'LightSpeed webstore'. The code of this webstore platform can be evaluated here: [url removed, login to view]
This is the basic workflow for the webstore ordering process:
- Client orders something through the webstore
- Client pays through webstore
- Webstore creates a MySQL entry with order information
- POS system (Mac) connects to webstore database every * minutes
- POS system automatically converts MySQL entry into an actual order that is created inside the POS system
As we're selling this product to the Dutch market our clients require the use of the Dutch payment system called iDEAL. We have chosen to offer iDEAL payments through the Dutch payment partner 'Mollie'. Information on the Mollie iDEAL API can be found here: [url removed, login to view] (English and Dutch). You can find more information about iDEAL here: [url removed, login to view]
We currently already own a functional iDEAL module for LightSpeed webstore that uses the Mollie API but we want to have it refined an cleaned. The current code exists out of 3 PHP files. Two files are the actual code of the module and consist out of only 128 lines of code. The third file is a standard Mollie configuration file that has 467 lines of code. You'll receive these files once we've started working with you. For now you can look at the attached file which contains the documentation for building payment modules for LightSpeed webstore.
What we want:
1. CLEAN: Clean the 128 lines of code. We believe that the previous developer was rather sloppy when it comes to clean coding.
2. ADD: Move the variables 'mollie partner id' and 'order description' to either a [url removed, login to view] file or allow users to configure it through the Web Store admin panel by utilizing the 'public function config_fields($parentObj)' php function (Explained in the attachment).
3. FIX: The return trigger doesn't look at the payment status. If the user cancels the payment process and returns to the webstore, the order is still created in the system.
4. ADD: Once the payment has been made, the system creates the order. Add the payment as a deposit to the order. This is possible and should be explained in the attached file.
5. MOVE: The second file with code ([url removed, login to view]) currently resides in the root directory of the webstore. Move this to the appropriate location (custom_includes/payment).
6. RENAME: Users have the ability to add more than one custom payment module. Rename the files of the iDEAL module so they'll never conflict with other files. Possibly add the 'ideal_' prefix.