COD with a CC field to start.
Might I recommend you use the checkout_confirm.php page to add the form like my soon-to-be-released authnet aim module. Rather than bruces post-confirm page method.
The confirm_checkout page already supports it and it works great.
Also, I had a thought.. CC modules all have a common "validation" check for a multitude of CC checks
- Valid numbers
- Valid dates
- Valid number algorithms
Perhaps this could be common across CC modules. I can show you the one I used that I found online. It's pretty common amongst other ecommerce stores as well
Sounds like you know what you're on about with this one.
What's the difference between checkout_confirm.php and the post method?
The question is, what happens with the details? Store in the database? Sent by email? Both? Something else?
What about security implications? Is it our realm to be concerned about them, it leave it up to the end user.
I'm going to need a working solution this week.
What's the difference between checkout_confirm.php and the post method?
The question is, what happens with the details? Store in the database? Sent by email? Both? Something else?
What about security implications? Is it our realm to be concerned about them, it leave it up to the end user.
I'm going to need a working solution this week.
post not meant as "$_POST" but "after".
Bruce has payment module that goes:
Cart->Shipping->Payment->Confirm->CreditCart form->Success/Fail
But a much better method (IMO) is to use the checkout_confirm page as it was designed and save a step.
Just like paypal, its just a form. So use visible fields to display the fields you want.
The fields, as well as what you do with them, is all handled by the extension/payment controller file, so you can do it by email or db or anything you like and not have to change any opencart files.
Security wise, I think if you only store half the number in the db, and email the other half to the store admin email, it's ok. That is how I've seen it done on other carts.
I will check the authorize.net aim module into the svn contrib area and you can see how I set the form up. All the processing stuff is working great. Could use a little spring cleaning but it works perfect. I just want to add support for displaying the error messages during a failure scenario. I pondered about offering the ability to save the cc data to a db table. While that would be a major security thing, it would be configurable and up to the store owner to deal with it. Sometimes it can be useful to have the number for follow up and problems.
Also, be sure to take a look at the "ValidateForm" function, as that is something that would be good as its own lib file, common amongst all CC payment processors as it is universal for all credit card pre-validation (before sending to processor)
Bruce has payment module that goes:
Cart->Shipping->Payment->Confirm->CreditCart form->Success/Fail
But a much better method (IMO) is to use the checkout_confirm page as it was designed and save a step.
Just like paypal, its just a form. So use visible fields to display the fields you want.
The fields, as well as what you do with them, is all handled by the extension/payment controller file, so you can do it by email or db or anything you like and not have to change any opencart files.
Security wise, I think if you only store half the number in the db, and email the other half to the store admin email, it's ok. That is how I've seen it done on other carts.
I will check the authorize.net aim module into the svn contrib area and you can see how I set the form up. All the processing stuff is working great. Could use a little spring cleaning but it works perfect. I just want to add support for displaying the error messages during a failure scenario. I pondered about offering the ability to save the cc data to a db table. While that would be a major security thing, it would be configurable and up to the store owner to deal with it. Sometimes it can be useful to have the number for follow up and problems.
Also, be sure to take a look at the "ValidateForm" function, as that is something that would be good as its own lib file, common amongst all CC payment processors as it is universal for all credit card pre-validation (before sending to processor)
Last edited by Qphoria on Mon Feb 02, 2009 11:35 am, edited 1 time in total.
Something like this: http://pear.php.net/package/Payment_Process ?
Either way, I'm looking to have a solution by Tuesday night, if not Thursday night at the very latest, so if you can help with this, that'd be very useful to me.
Either way, I'm looking to have a solution by Tuesday night, if not Thursday night at the very latest, so if you can help with this, that'd be very useful to me.
Hmm not really, I mean maybe. I'm talking more in terms of validation. I did wonder how much of it could be set up for the rest of the processing stuff, and then just the destination url, username, and pass could be changed and viola.. but that doesn't really apply to you offline thing. I'll upload the contrib to svn and explain when i get to workhm2k wrote: Something like this: http://pear.php.net/package/Payment_Process ?
This is what my client said, which seems the same as normal really:
With regards to validation, try the following:
http://stackoverflow.com/questions/1747 ... ard-in-php
http://www.zen-cart.com/forum/showthread.php?t=46903
http://pear.php.net/package/Validate_Finance
http://pear.php.net/package/Validate_Finance_CreditCard
If we were to use the pear package, it'd be a stripped down version anyway.
I'd expect he'd want all these details to be sent directly to him via email so he can process them immediately, and so that once he's deleted the email, their details are safe, rather than being in a database.Concerning the credit card payments, we normally ask for the card holders name on the card, large 16 digit number, expiry date on the front and the last 3 digit security number on the back
With regards to validation, try the following:
http://stackoverflow.com/questions/1747 ... ard-in-php
http://www.zen-cart.com/forum/showthread.php?t=46903
http://pear.php.net/package/Validate_Finance
http://pear.php.net/package/Validate_Finance_CreditCard
If we were to use the pear package, it'd be a stripped down version anyway.
Really I think you need to allow for a configurable email address on the module, in case you want the credit card details sent to a different email address than what is set in the admin area.
As a fall back you can use config_email, if nothing is configured.
Make it so!
As a fall back you can use config_email, if nothing is configured.
Make it so!
You talk about security, but how secure is sending CC information by email? Considering that email is sent as plain text and the number of packet sniffers out there, I would think that sending CC information by email is VERY insecure. Or, do you intend applying some sort of encryption to these emails?
Modules for OpenCart 2.3.0.2
Homepage Module [Free - since OpenCart 0.7.7]
Multistore Extensions
Store Manager Multi-Vendor/Multi-Store management tool
If you're not living on the edge ... you're taking up too much space!
Typically half the card number is emailed, the other half is stored in the db. But the specs I was given for the client were to have it all emailed for now so that is how I made it.
I agree with the separate email. I can add that easily, but what do we want to do about the security of the card num?
we could even send 2 emails, but that can get confusing. i think the half and half method would work, but open to other ideas.
I agree with the separate email. I can add that easily, but what do we want to do about the security of the card num?
we could even send 2 emails, but that can get confusing. i think the half and half method would work, but open to other ideas.
Both database and mail have security risks.fido-x wrote: You talk about security, but how secure is sending CC information by email? Considering that email is sent as plain text and the number of packet sniffers out there, I would think that sending CC information by email is VERY insecure. Or, do you intend applying some sort of encryption to these emails?
Storing CC details in the database means that if your db gets breached, the intruder instantly has all of the cc details.
Sending by email is vulnerable to "man in the middle" snooping, however, once the email is read and deleted, the details are gone.
Considering CC details are "throw away" they shouldn't really be stored, they should be used, then destroyed.
This is why for now I'd opt for a pure mail solution, unless anyone has a better suggestion.
I'm not keen on "emailing" credit card details. Too risky for me though I know some store owners want it that way.
Viart records (or used to record) the cc details in the database "encrypted". My memory of Viart is dim but it was along the lines of -
admin can choose to store the full number or not store the last 4 digits in the db.
(Can't remember if there was also an option to not store the number at all and what happens if it's not stored).
admin then logins and retreives the encrytped data from a page that has code for decryption
My question was - but what if someone hacks into admin. I suppose admin can always delete the details after processing the order
I think the last 4 digits were emailed to admin if admin chose not to store the last 4 digits.
Sorry, my memory on this is vague
In France, there was someone working on offline CC using blowfish for encryption. Don't know if they ever got it working.
Are there any PCI compliant issues to be addressed ? I dunno.
Viart records (or used to record) the cc details in the database "encrypted". My memory of Viart is dim but it was along the lines of -
admin can choose to store the full number or not store the last 4 digits in the db.
(Can't remember if there was also an option to not store the number at all and what happens if it's not stored).
admin then logins and retreives the encrytped data from a page that has code for decryption
My question was - but what if someone hacks into admin. I suppose admin can always delete the details after processing the order
I think the last 4 digits were emailed to admin if admin chose not to store the last 4 digits.
Sorry, my memory on this is vague
In France, there was someone working on offline CC using blowfish for encryption. Don't know if they ever got it working.
Are there any PCI compliant issues to be addressed ? I dunno.
The problem with any kind of encryption is you have to decrypt it at the other end.
If it's for email, it's not going to be very practical.
The PCI compliance, it seems has been discussed at length over at oscommerce: http://forums.oscommerce.com/index.php?showtopic=273891
Obviously, their regulations don't apply over here in the UK, but we'll have similar ones anyway. It probably also makes sense to comply anyway.
Another method would be to not store details such as the CVV or last 4 digits of the card at all, anywhere, and simply force the store owner to call the customer to confirm them, allowing them to complete the order and payment as if it was taken over the phone.
If it's for email, it's not going to be very practical.
The PCI compliance, it seems has been discussed at length over at oscommerce: http://forums.oscommerce.com/index.php?showtopic=273891
Obviously, their regulations don't apply over here in the UK, but we'll have similar ones anyway. It probably also makes sense to comply anyway.
My concern is that with database, if the store owner forgets to delete the entries after processing and they get hacked, you're screwed, where as with mail, people can only hack the ones that are currently being sent, or have not been deleted yet.If you are PCI compliant you are alowed to store the following info:
- Account Number
- Cardholder Name
- Expiration Date
- Service Code
The following info you are NOT allowed to store even if you are PCI compliant.
- Magnetic Strip
- CVV/CVV2
- Pin Data
Another method would be to not store details such as the CVV or last 4 digits of the card at all, anywhere, and simply force the store owner to call the customer to confirm them, allowing them to complete the order and payment as if it was taken over the phone.
Yer, I agree. That's why I abandoned the offline credit card methodhm2k wrote: My concern is that with database, if the store owner forgets to delete the entries after processing and they get hacked, you're screwed,
Viart offered this method from what I rememberAnother method would be to not store details such as the CVV or last 4 digits of the card at all,
Don't store the cc last 4 digits and email the last 4 digits to admin
Can't remember about the CVC but it could be emailed with the last 4 digits
Admin can then login to database to get the rest of the info
Cubecart uses or used the encryption method from what I saw over a year ago.
To set this up properly, you'd probably need a new table for storing the credit card details wouldn't you?
Upon receiving credit card details, the system will store the details in the database.
In the database the last 4 digits of the card number will be replaced by "xxxx", and the CVV will not be stored.
The email should contain the following:
A direct link to a page where the user can view the stored credit card details once they login.
The last 4 digits of the credit card number.
The CVV.
Any other details that could not be stored in the database.
Once you have used the credit card details, you should be able to click a button on the page that deletes the entry.
All entries older than 30 days should be automatically deleted.
You can then delete the corresponding email.
Issues:
* More work for your device - especially if you're using a mobile device, you'd now have to open a browser as well as your mail client.
* More paper - people are lazy, if details are on two pages, they will print both pages if they want to print them at all.
* Security through obscurity - Just because we're separating the data into two, doesn't mean that it's any more secure, just obscure. It's "less likely" to get breached because not all the details will be presented at once, however if someone wants them enough, they are going to be able to get them regardless of what you do.
Upon receiving credit card details, the system will store the details in the database.
In the database the last 4 digits of the card number will be replaced by "xxxx", and the CVV will not be stored.
The email should contain the following:
A direct link to a page where the user can view the stored credit card details once they login.
The last 4 digits of the credit card number.
The CVV.
Any other details that could not be stored in the database.
Once you have used the credit card details, you should be able to click a button on the page that deletes the entry.
All entries older than 30 days should be automatically deleted.
You can then delete the corresponding email.
Issues:
* More work for your device - especially if you're using a mobile device, you'd now have to open a browser as well as your mail client.
* More paper - people are lazy, if details are on two pages, they will print both pages if they want to print them at all.
* Security through obscurity - Just because we're separating the data into two, doesn't mean that it's any more secure, just obscure. It's "less likely" to get breached because not all the details will be presented at once, however if someone wants them enough, they are going to be able to get them regardless of what you do.
Yes, I agree with all the issues raised
Options:
* Email - if they can subscribe my "new" email address to a Viagra email list after only one week of using the new email account, then I don't trust them.
They are also using the Contact Form to automate sending Viagra emails. I don't trust them.
* Storing the details in the dbase - I don't trust them
* Half and half - too much work for us lazy store owners
* Phoning customers for the details - too expensive in time.
The closest solution I found out there that I was comfortable with is the encrypt/decrypt method.
The whole topic gave me such a headache that I abandoned the Offline CC idea
Options:
* Email - if they can subscribe my "new" email address to a Viagra email list after only one week of using the new email account, then I don't trust them.
They are also using the Contact Form to automate sending Viagra emails. I don't trust them.
* Storing the details in the dbase - I don't trust them
* Half and half - too much work for us lazy store owners
* Phoning customers for the details - too expensive in time.
The closest solution I found out there that I was comfortable with is the encrypt/decrypt method.
The whole topic gave me such a headache that I abandoned the Offline CC idea
Who is online
Users browsing this forum: No registered users and 34 guests
