Suggestion/Request - Manual/Offline Credit Card Handling Like Zen Cart's

23 replies [Last post]

Mon, 06/02/2008 - 21:05

maitaijim

Offline

Joined: 06/02/2008

Juice: 7

Zen Cart's manual credit card module is perfect for established brick & mortar businesses that want to process transactions offline. It splits the card number and stores the outside eight digits and expiration with the order and sends the inside eight digits in an email.

For example a restaurant that wants to sell physical gift cards and or a couple of t-shirts on their website may not want the added expense of a payment gateway (or Paypal even for free).

Including this type of credit card processing would provide Ubercart users a way to process cards offline without the temptation of storing the whole card number with the order.

Thanks,
Jim

Tue, 06/03/2008 - 08:51

#1 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15422

Re: Suggestion/Request - Manual/Offline Credit Card Handling Li

Hmm... something like this could be made to work as a payment gateway module w/ the current CC system. I've had it recommended to me before but had to focus most of my core development efforts in the area on the CC system as it stands now.

Thu, 09/25/2008 - 23:51

#2 View page

Jaclyn

Offline

Joined: 09/25/2008

Juice: 36

wondering about offline credit card

I am curious if you all have thought about creating a module (as has been recommened in the past) that emails the credit card info, so that we can run credit cards offline. I really want to use Ubercart's system, but am nervous because it would be best for us to just use our offline store merchant account, and I would prefer not to store credit card numbers on our website, because of the risk and liability.

Fri, 09/26/2008 - 10:31

#3 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15422

Re: wondering about offline credit card

I'm not sure there's much less risk in e-mailing the numbers, but as far as I understand it, it would still violate the PCI security standards for CC data storage. I don't have any plans to work on something like this, but I imagine a module could be written that would work w/ UC in CC debug mode to e-mail the data upon checkout and clear it from the DB.

Wed, 12/10/2008 - 19:01

#4 View page

Blackguard

Offline

Joined: 10/24/2007

Juice: 47

Re: Re: wondering about offline credit card

I'm converting a Zen cart site to Ubercart and I'm going to have to write such a module.

This is what the zencart manual credit card processing module does :

Write the first four and last for digits of the card number to the database.
Email the middle eight digits to the store admin.

I'd really appreciate a quick outline of how to use the ubercart hook system or documentation to such an outline, or even just pointers to the module I need to hook into to accomplish such a task.

Tue, 02/17/2009 - 16:47

#5 View page

eroxors

Offline

Joined: 04/17/2008

Juice: 33

Re: Re: Re: wondering about offline credit card

Any luck yet?

Tue, 06/03/2008 - 10:48

#6 View page

goodeit

Offline

Joined: 05/28/2008

Juice: 319

Re: Suggestion/Request - Manual/Offline Credit Card Handling Li

This is a great idea! I could use this for sure.

Wed, 04/01/2009 - 22:50

#7 View page

TOPGUN

Offline

Joined: 04/01/2009

Juice: 2

Manual/Offline Credit Card Handling

I would be happy to contribute to the cost of a module that can handle this job.

Thu, 05/28/2009 - 01:41

#8 View page

dbeall

Offline

Joined: 05/28/2009

Juice: 2

This type of module would boost ubercarts usage. It is my first requirement for a cart system. The card numbers could be transmitted in several emails or some similar method.. I am not a programmer, but a module that performs this task would most certainly be worth some fee.
I will keep checking back to see when it's available.
Thanks, dave

Tue, 01/12/2010 - 14:09

#9 View page

echoleaf

Offline

Joined: 08/03/2008

Juice: 220

Re: .

Has there been any development here? I have a client looking for this exact thing - receiving notifications w/ cc numbers for offline processing. I do understand the compliance issue, but for a real brick & mortar store I need to be able to offer something like this.

Tue, 01/19/2010 - 13:08

#10 View page

John_

Offline

Joined: 01/19/2010

Juice: 3

Re: Re: .

I am also looking for this functionality...any progress?

Thanks

Tue, 01/19/2010 - 18:13

#11 View page

Jonny

Offline

Joined: 01/19/2010

Juice: 11

Re: Re: Re: .

Before you implement something like this you really should read the PCI standards, which you have to comply with as part of your card processing agreement, as it is a clear and blatant breach.

If you got caught doing it you'd most likely have your agreement terminated on the spot and if there was a security breach and the card data was used fraudulently the potential financial penalties are extreme.

Its just not worth the risk for the sake of saving a bit of money.

Sat, 02/27/2010 - 19:34

#12 View page

wigglebum

Offline

Joined: 01/04/2009

Juice: 10

I'm in

Another ZenCart to Ubercart conversion here that REALLY misses this functionality. I only process EFTPOS/CC via a mobile EFTPOS unit (screw paying 500merchant+x00SSL per year when my onlinee sales may not exceed that).

If people are willing to pay for the module's development, I'm willing to have a crack at developing it. Given Ryan's suggestion of developing it as a faux payment gateway, it shouldn't be too hard. Finding the time will be my challenge.

Sat, 02/27/2010 - 20:11

#13 View page

Online

Joined: 11/05/2007

Juice: 3369

Re: I'm in

Pay attention to what Jonny says in #11, because he's 100% correct:

Before you implement something like this you really should read the PCI standards, which you have to comply with as part of your card processing agreement, as it is a clear and blatant breach.

If you're going to implement this despite your legal agreement with your processor, keep it to yourself. DON'T publish the code, because that will only cause others to unknowingly put themselves and their customers at risk. Enabling this would be highly irresponsible.

<tr>.

Sat, 02/27/2010 - 20:24

#14 View page

wigglebum

Offline

Joined: 01/04/2009

Juice: 10

Re: PCI

There was another thread on here between Ryan and a couple of others where it was highlighted (on about page 6 of the PCI's specs from memory), that it is not a breach of the PCI standard to store encrypted credit card details after completion of an order - only to store card authorisation data (e.g. PIN, CVV - don't know why anyone would EVER store PIN anyhow).

Of course storing part enrypted in the db and part (probably unencrypted in an email in someone's account somewhere) probably makes it a bit grey - perhaps slap PGP on the email?

Fri, 03/12/2010 - 17:34

#15 View page

goodeit

Offline

Joined: 05/28/2008

Juice: 319

Re: Re: PCI

I would be interested in others' interpretations of the PCI Standards, but I read it as stated above: as long as you are not storing the "sensitive" data (e.g. CVV) then it is not non-compliant to store the data. Even using 'debug mode' would seemingly be compliant, as the information that is kept is encrypted, and then purged after "processing". Coupled with an SSL certificate, it appears to be a viable, compliant way to do business.

disclaimer: PLEASE do your own research. I am still very new to this myself and could very well be wrong in my interpretation above. etc etc etc.

Does anyone agree/disagree with this interpretation?

Fri, 03/12/2010 - 19:46

#16 View page

adamo

Offline

Joined: 02/17/2009

Juice: 229

Re: Re: Re: PCI

Everyone processing credit cards should read the PCI DSS and do a self assessment. There are different requirements for different situations. Some rules always apply. It's never acceptable to store a CVV in any format, even encrypted. It is acceptable to store the last 4 digits of a card number in plain text. It's simpler if you can get away with not storing full card numbers. If you store full card numbers there are all kinds of additional rules that apply... Mostly just good security standards, but they are strict. You need to keep audit logs of all access, encrypt the card numbers, have a 3rd party company do periodic security scans, file integrity monitoring... However, if you are encrypting the card number with a public key on the server, but the private key necessary for decryption has never been stored on the server, then I think technically you are not storing the card storing the card number on the server at all. Without the private key all you are storing is a bit of gibberish text.

I've written a module that uses GnuPG for encryption. It encrypts the card number immediately using your public key. The private key is never stored on the server. On your private/internal computer(s), you have GnuPG installed and set up with your private key. When you view an order through the admin interface on the website, a small Java applet will load in one of the order panes. The applet will check for your GnuPG exec and keys in the most common locations. If it can't find them you can specify the locations and it will store the info in a permanent cookie. When the applet has these things it will show you a pass phrase prompt. You enter the pass phrase for your private key, hit enter, it calls GnuPG to do the decryption, and (via JavaScript) alters the order page to show the full card number. All of this is being done on the local machine, so the server never sees the private key, pass phrase, or decrypted card number. I am planning on releasing it but there are some things I need to tidy up a bit first and it needs to be documented and disclaimers written, etc, etc. If people are interested in this (maybe want to help test?) I'll probably get it released sooner. It doesn't make it easy to charge card numbers, since you have to view each order, enter the pass phrase (you can paste it), and hit enter to get the card number. It is possible for the applet to decrypt any number of credit card numbers on a page, so it would be possible to create a page listing all of your pending orders with CC information. We have a separate application that we use to import web orders into our local system, and then we charge them from there.

Sat, 03/13/2010 - 01:01

#17 View page

Online

Joined: 11/05/2007

Juice: 3369

Nice adamo! I wrote a similar

Nice adamo!

I wrote a similar module a few years back, but I used OpenSSL instead of GnuPG for several reasons. First, because Ubercart sites usually need OpenSSL anyway to do https, second I didn't want to have to deal with downloading and installing yet another third-party package, and third because I had also re-written Ubercart's internal CC encryption to use OpenSSL. Likewise, I didn't use an applet, but did all the decryption in JavaScript on the client side. It worked, but turned out to be unacceptably slow to do this in JavaScript, ~15 seconds to decrypt with a 2048 bit key.

I would be very interested in seeing your code posted as a project on Drupal.org. I will gladly help test/debug. I suggest you digitally sign your applet with a real certificate, otherwise that becomes the weak link in this very strong system (someone with access to your server file system could replace the jar file with malicious code that kept a record of all the decrypted CC numbers, while at the same time behaved properly so you'd never know it).

<tr>.

Sat, 03/13/2010 - 15:37

#18 View page

adamo

Offline

Joined: 02/17/2009

Juice: 229

Re: Nice adamo! I wrote a similar

Nice. OpenSSL is probably a better way to go. I probably would have gone that route, but I wrote the original applet and PHP code a couple of years ago (for a non-Drupal site) and I didn't really know much about encryption but I had used GnuPG a bit. There were some other reasons specific to the situation as well. I looked at some sample JavaScript decryption solutions at the time but they were all very slow. The Java applet works well. Once it's cached it doesn't take any time to load at all, and it decrypts card numbers instantly. One problem with using GnuPG is that the applet needs to execute a local copy of GnuPG to do the encryption (it actually does work in Windows, Mac OS, and Linux), and for it to be able to do that the applet needs to be Trusted. A trusted applet can do anything it wants on your local system, so if someone replaces the jar file it could be a very very bad thing indeed. I would definitely like to have it signed with a real certificate. Unfortunately they are pretty expensive. Maybe if enough people are interested in it I can get some help with that. On the other hand, I plan on distributing the Java source as well, so anyone can build it and sign it with their own self signed certificate. I would like to support OpenSSL as well, or possibly switch it over to OpenSSL entirely. Not sure but maybe that way the applet would not need elevated security privileges. I'm wrapping up another project now but I'll try to get it ready for Drupal.org in the next couple of weeks. I'll be looking forward to your feedback.

Mon, 03/29/2010 - 10:04

#19 View page

veganline

Offline

Joined: 08/22/2009

Juice: 24

Mals-e commerce

Just a thought: installing mals-e commerce order forms, which are just html, would take your shopkeeper's customers to a free secure server. The shopkeeper gets the order by email or special download software and logs-on to read the card numbers. If there are several of them at a time, it's quicker to get the paid-for version of mals download software called mOrders for $95. This takes the numbers to an encrypted database on the shopkeeper's machine. Either way, the shopkeeper gets order emails and can set automatic acknowledgement emails, and can download the orders to mals software.

The shopkeeper keeps the computer itself secure & deletes information after a reasonable time.

Downsides:
~client has to keep data secure...
...and delete in a reasonable time, and risk human error like charging a customer twice. (Which I've done!) As a shopkeeper they're presumably trusted by their card processing company to do this already, rightly or wrongly.

~the system will continue selling stock that has sold out.
A stock database is not included and is hard to link-in.
The shopkeeper doesn't have to charge the card if it's a manual system, but it's still better for shopkeepers who can change their web site quickly or keep stock topped-up easily. A restaurant selling cards and T shirts could just keep plenty in stock.

~not an open source modular system.
Various work-arounds have tried to link it to accounting systems & stock control systems, but it's an obscure thing to try to do and I've personally never done it. These links and work arounds are themselves not usually open source nor designed to link to open source software.

~buyers have to jump between different websites to order, putting off some.
The two or three page order form is called ww8.aitsafe.com/ rather than your choice of domain name.

~a paypal button does about the same.
This makes mals excessively complex for someone who would use paypal. Differences are the price for card processing that the shopkeeper may be paying on different systems, and ways of dealing with telephone or walk-in customers - specially for someone who has a good cheap system for walk-in customers that's linked to other things.

~if the client is using mals, there's less need of a content management system to make their web site, still less Ubercart.
Good to use one anyway, perhaps, for the free themes and modules and to save having to change later.

Upsides:

~free use of the mals' secure server

~no recurring costs

~if it's not PCI compliant, there are hundreds of Mals users who will probably spot this first

I hope nobody minds me jumping into this thread like this. I'm not from a programming background. Just thought it might suit some shopkeepers like myself who like a gradual move from processing all their own card payments to using Ubercart. My own choice was not to mix the two systems up and make the whole jump at once, but your clients might be different.

Mon, 04/19/2010 - 21:06

#20 View page

moby

Offline

Joined: 10/05/2008

Juice: 156

this looks like a excellent option

Ive been pndering about encrypting for offline processing..

Would love to see a module for this.

Mon, 03/29/2010 - 13:05

#21 View page

sanguis

Offline

Joined: 05/15/2009

Juice: 78

I have done this

and to the best of my knowledge it meets PCI compliance settings.
contact me for details.

Left Click Computers
www.sanguisdevelopment.com over 6 years of custom eCommerce experience
on irc I am sanguisdex

Mon, 04/26/2010 - 23:52

#22 View page

weta1

Offline

Joined: 12/07/2009

Juice: 18

Ubercart and Mals Ecom

Have been using Mals Ecom over a number of years for manually processing online orders and it has been great. Thanks Mal! Am now upgrading a number of sites to Drupal and integrating Ubercart. Would like to use the manual processing feature Mals offers (i.e. secure gateway but with cc number emailed when orders received) as several site have relatively low volume and do not justify full payment gateway fees. However, unable to find a free option to do this, as there appear no modules linking Ubercart to Mals (or easy solution for a non developer). Are there any obvious solutions I may be missing? Thanks!

Sun, 05/23/2010 - 08:47

#23 View page

moby

Offline

Joined: 10/05/2008

Juice: 156

so w offline encryption this passes PCI?

Hi Sanguis.

So if we created a module that did something similar to mals ecommerce.

emailed/transferred an encrypted version of the card details to an offline host.
(this means that the c/c number is not stored on a public server.. ?)

this host has the sofware to decrypt (public/private key)

then we manually process the payment,

and the sotware deletes the corresponding credit card data from the offline host.

would this satisfy the requirements?

	Shopping cart
	View your shopping cart.

	User login
	Log in using OpenID: What is OpenID? Username or e-mail: * Password: * Remember me Log in using OpenID Cancel OpenID login Create new account Request new password

Ubercart

Navigation

Shopping cart

User login