Checkout : Email Module for process through SSL on same site
|
chris.rhodes@pr...
Joined: 2009-08-25
Posts: 3 |
Posted: Tue, 2009-08-25 22:56
|
|
My idea is to extend the current checkout module by accepting credit card information directly on the same site over HTTPS by doing the following: 1) Collecting customer information. If anyone has already done this, or has links to other development (I have searched) on a similar module, I would appreciate help. The code will be up for grabs once I am done. Thank you, |
|
Posts: 804
You don't want to use email for credit cards. Email is not encrypted and would be like sending a post card in the mail.
Posts: 4338
It would be a new payment module (probably based on checkoutemail) that you would want to write, not to extend or alter any of the existing modules. In general I can help with the checkout-specific stuff but:
1. lvlthunder is correct that sending credit card details by open email is verging on the criminally stupid and -
2. Wherever you store the emails with the full credit card details would need to comply fully with the PCI DSS
3. emailing unencrypted credit card details probably violates PCI DSS anyway
My very very strong suggestion is to use Paypal or Google Checkout to accept payments - when your turnover reaches the point that a different payment processing system would be cheaper then consider a different system.
Posts: 3
Please read through all of the steps I mentioned in the original post. I never said all of the credit card information would be sent in an e-mail. I realize this is playing with fire, and that is the reason I want to divide the data into two separate parts. I do not want to store all of the information in the same place unencrypted (e-mail or database).
To clarify a few things:
1) All of the credit card details would never we sent purely over e-mail. Part of them would be in an e-mail (ie. first 8-digits of CC and CVV#). The other part would be stored in the database with the order (ie. last 8-digits of CC and Exp. Date).
2) The current implementation of the checkoutemail is using a JavaScript hack to place the CC details in the Comments fields. I want to move away from this ASAP!
3) The client already does enough processing through his current processor through a terminal for a better rate than Paypal or Google. Online orders are secondary. Hence the reason for implementing this method.
4) This is already being done commercially with Photo Cart.
5) The new module will be open source.
Thank you.
Posts: 4338
Hi Chris,
Nobody's got any power to stop you doing whatever you like - we're just saying that sending any kind of credit card details over email is a really silly idea. But it's not our opinion that counts; it's up to you (your client, really) to comply with the PCI DSS requirements and any other stipulations of his/her card processor, or not, at their discretion. Thy will carry the can for the consequences if and when it goes wrong. Again, whether you're already doing it by some other method, on some other website, or whether you decide to release your code for re-use - doesn't change any of that.
If you're a competent php programmer, and you've experience with the Gallery API, I can help you with the checkout-specific portions of what you need to know, as I said. It's straightforward.
Posts: 3
If I came across crass, in my last response please accept my apology. I feel competent enough in PHP, but perhaps not the API.
I've tried to poking around in the database, changing the structure, etc. Ideally I would like to have specific fields and add additional values and fields to the templates which map back to the database. A good place to start for me, is how can I change the current Checkout E-mail module to another name so it can be included in the module tree?
Also, how much trouble will it be to navigate the user to the form using SSL and then back to standard HTTP after checkout is complete?
Thank you for all the help!
Posts: 4338
G2 provides a specific way to specify (and alter) db tables, I think there are some docs in the developer's section.
Yes... study the difference between a G2 map, and a entity, two different ways to store stuff in the db.
You need to search/replace *every* occurence of the module title in any of the files ... also if it's checkoutemail that you're modding then you'll need to alter the interface declarations in the right way to avoid collisions. Sometimes it's in camelCase, too, sometimes all in lower-case. Important to maintain that distinction where it exists (or at least, tidy).
I didn't take checkout on until I'd written three or four different modules (from the ground up) - the first attempt into any new API always comes out as a load of cr*p when you look back, so might we worth writing a couple of different modules, playing with maps, entities, installation code etc until you get the hang of it?