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
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.
Bruce has payment module that goes:
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)
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 ?
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
If we were to use the pear package, it'd be a stripped down version anyway.
As a fall back you can use config_email, if nothing is configured.
Make it so!
Modules for OpenCart 18.104.22.168
Homepage Module [Free - since OpenCart 0.7.7]
Store Manager Multi-Vendor/Multi-Store management tool
If you're not living on the edge ... you're taking up too much space!
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.
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.
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
- 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.
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.
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.
* 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.
* 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
Users browsing this forum: No registered users and 2 guests