Post by Qphoria » Sun Feb 01, 2009 11:29 pm

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

Attachments

???
cc_confirm.jpg

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by hm2k » Mon Feb 02, 2009 5:34 am

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.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by Qphoria » Mon Feb 02, 2009 11:27 am

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)
Last edited by Qphoria on Mon Feb 02, 2009 11:35 am, edited 1 time in total.

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by hm2k » Mon Feb 02, 2009 5:23 pm

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.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by Qphoria » Mon Feb 02, 2009 9:55 pm

hm2k wrote: Something like this: http://pear.php.net/package/Payment_Process ?
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 work

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by hm2k » Mon Feb 02, 2009 11:48 pm

This is what my client said, which seems the same as normal really:
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
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.

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.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by hm2k » Wed Feb 04, 2009 7:14 am

Offline Credit Card module added to contribs SVN branch in r415, I will test it out, if it goes okay, I'll likely merge it into the core.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by hm2k » Thu Feb 05, 2009 6:21 pm

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! :)

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by fido-x » Thu Feb 05, 2009 6:51 pm

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?

Image
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!


User avatar
Expert Member

Posts

Joined
Sat Jun 28, 2008 1:09 am
Location - Tasmania, Australia

Post by Qphoria » Thu Feb 05, 2009 8:02 pm

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.

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by hm2k » Thu Feb 05, 2009 9:48 pm

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?
Both database and mail have security risks.

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.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by bthirsk » Thu Feb 05, 2009 10:36 pm

I'm no expert on database or database security, but I know some other carts use a separate
database for information like credit card as well as Password and user information.

Brent


User avatar
Active Member

Posts

Joined
Wed Sep 03, 2008 11:33 am
Location - Canada

Post by hm2k » Fri Feb 06, 2009 4:29 am

Although that could be done, it's far more difficult to setup.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by Qphoria » Fri Feb 06, 2009 5:39 am

It seems noone is keen on the half and half idea I keep spouting. This is how its done on osc and zencart.. just sayin.

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by jty » Fri Feb 06, 2009 12:06 pm

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.

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am

Post by hm2k » Fri Feb 06, 2009 6:53 pm

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.
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
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.

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.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by Qphoria » Fri Feb 06, 2009 8:58 pm

yea... so far my idea of half and half still stands solid. I think I'll go with that.

dbcardnum: xxxx52256323xxxx
dbexp: 09/10
dbcvv: 123

email: 4123xxxxxxxx9892

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by jty » Fri Feb 06, 2009 9:16 pm

hm2k 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,
Yer, I agree. That's why I abandoned the offline credit card method
Another method would be to not store details such as the CVV or last 4 digits of the card at all,
Viart offered this method from what I remember
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.

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am

Post by hm2k » Fri Feb 06, 2009 9:53 pm

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.

UK Web Hosting


User avatar
Global Moderator

Posts

Joined
Tue Mar 11, 2008 9:06 am
Location - UK

Post by jty » Sat Feb 07, 2009 12:41 am

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

jty
Active Member

Posts

Joined
Sat Aug 30, 2008 8:19 am
Who is online

Users browsing this forum: No registered users and 5 guests