| Author |
 Topic  |
|
Barney Stone
Administrator
USA
6279 Posts |
 Posted - 11/09/2009 : 5:00:59 PM
|
I would like to get a conversation started about PA-DSS (security certification for software such as shopping carts and order management systems), PCI (certification for merchants) and the whole idea of storing credit card numbers.
We have come to the conclusion that the need for storing credit card account numbers at all is quickly coming to an end. All but one of the payment gateways that we integrate with offer the ability to use "tokens" in place of account numbers if you have to issue a credit or place an additional charge against an account. The account number is only used for the initial charge or authorization. After that, everything can be done with the token (or whatever that gateway calls it). No account numbers are stored, and tokens should be useless if they fall into the wrong hands.
And yes, I repeat, the tokens CAN be used for additional charges in the future. Typically there is a 6 to 12 month limit on how long they can be used. After that, you would have to contact your custom and get the account number again so you can be issued a new token.
Some of the gateways (Authorize.net, JetPay) charge a few cents per transaction for the use of their tokens. Most others (ECHO, PayPal, Payflow Pro, QuickBooks Merchant Services, USAePay, etc.) do not charge extra for them.
Using tokens should dramatically reduce the risks involved with credit card processing, and make both PA-DSS (for software developers) and PCI (for merchants) much easier to achieve and maintain. Our tentative plan as we move forward is to only support combinations of shopping carts and gateways that will work that way. (This is for the future - nothing will be changed or dropped without plenty of notice and time for merchants to make any necessary changes.)
Comments, anyone? |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
chrisjohnson
Member
USA
177 Posts |
Posted - 11/09/2009 : 5:09:50 PM
|
| We are a Yahoo store. We use the Yahoo API for online orders and PayPal for our phone orders. Does Yahoo support tokens? If not, are they planning to use tokens in the future? |
 |
|
|
ocpxc02
Senior Member
USA
570 Posts |
Posted - 11/09/2009 : 5:41:51 PM
|
We're currently using Miva with Authorize.net. If tokens would be supported for this combo, we would have no issues with the change (we would actually prefer it over the current process of storing card numbers).
I have not seen any information from either Miva or Authnet regarding the use of tokens, so any info you have would be appreciated.
Thanks,
Paul |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 11/10/2009 : 10:14:52 AM
|
| We are just starting to collect information from the shopping carts (Yahoo, Miva, etc.). I will post info here as I receive it. So far, 3DCart has responded with strong support for the concept. They already support tokens for Authorize.net, and are adding support for Cybersource and USAePay. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
LoganR
Starting Member
USA
1 Posts |
Posted - 11/10/2009 : 1:55:42 PM
|
| We have been moving this direction for some time and strongly support the concept. It would be our preferred model of card processing. |
Logan Rhodehamel
AbleCommerce |
|
|
|
Rick Wilson
Starting Member
USA
1 Posts |
Posted - 11/10/2009 : 2:31:40 PM
|
I run day to day operations at Miva Merchant and Barney and I spoke about this topic this morning and it's certainly the direction we're moving.
We're in the process of releasing our initial support for Tokens on the CHASE Paymentech Orbital gateway but will add this to all of our supported gateways over the coming year as the gateways support it and we're updating them.
That would include:
CHASE Paymentech Orbital
IGS (Innovative Gateway Solutions) from Intuit
PayFlow Pro
Authorize.net
First Data Global Gateway
I'm sure most if not all of the third party module providers will follow suit as well. |
|
|
|
ocpxc02
Senior Member
USA
570 Posts |
Posted - 11/10/2009 : 5:02:16 PM
|
quote:
[i]Originally posted by Rick Wilson[/i]
[br]I run day to day operations at Miva Merchant and Barney and I spoke about this topic this morning and it's certainly the direction we're moving.
We're in the process of releasing our initial support for Tokens on the CHASE Paymentech Orbital gateway but will add this to all of our supported gateways over the coming year as the gateways support it and we're updating them.
That would include:
CHASE Paymentech Orbital
IGS (Innovative Gateway Solutions) from Intuit
PayFlow Pro
Authorize.net
First Data Global Gateway
I'm sure most if not all of the third party module providers will follow suit as well.
Good deal. Anything to slide Authorize.net up on your list would be appreciated.
Paul |
|
|
|
geckoday
Member
339 Posts |
Posted - 11/11/2009 : 10:49:02 AM
|
This is great to see Stone Edge and the cart vendors moving this direction. PCI-DSS is making it nearly impossible for the small merchant to get away with storing credit card numbers any more. I have already modified my cart software and Stone Edge to completely eliminate storing of credit card numbers and to even eliminate them from flowing through my web site greatly simplifying my PCI compliance work. And I still can recharge a card for shipping upgrades and reorders. Having been through this change there are a couple of things I'd like to suggest make it into this feature:
Store the masked credit card number to the full extent allowed by PCI and still have it not considered a card number. IOW keep the first 6 digits and the last 4 digits. The first 6 digits is the Bank Identification Number (BIN). This identifies the bank that issued the card and is needed for Maxmind fraud checking. The last 4 is needed, as it is today, for printing on receipts, verifying card to charge with the customer, etc.
Allow using reference transactions where the gateway supports it instead of a vault. A vault is nice if you really want to store all of a customers information in the gateway. Sharing that data and having one place to update it between Stone Edge and the cart sounds attractive. But, it comes at a price - both in dollars and performance. A vault means getting charged $0.05 or whatever per vault transaction on top of your normal credit card fees we all work to minimize. It also means waiting for those gateway transactions in your cart checkout and in Stone Edge. OTOH, referencing a prior transaction to create a new transaction means no new transactions to be paid for or waited for. Customer name and address information is handled the same as today. Its too bad that many gateways don't support reference transactions.
Add support for the Network Merchants gateway. This gateway isn't generally sold under its own name, rather it is rebranded by payment processors. A lot of processors offer it (Braintree, Premier Payment Systems, Alpha Card Services and a bunch more) and it has some nice features. A couple of key ones for those trying to minimize handling and storage of card numbers are:
- Reference transactions (not in their doc yet but works great)
- Ability to serve page from your server that securely posts card data to their server. Takes your web site out of PCI scope without the customer getting a form to fill in on another site)
- Support for Magtek Magnesafe encrypting card readers so swiped card information is encrypted before its sent to your POS system (not in doc yet, extra cost).
|
Ralph Day
Snow River
http://www.snowriver.com
Order Manager Version 5.916
Access 2003 SP3 w/hotfix
|
Edited by - geckoday on 11/11/2009 10:52:04 AM |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 11/11/2009 : 10:59:46 AM
|
Ralph -
Thanks for the feedback. We will definitely include an option to store the first 6 and last 4 digits of account numbers. I will pass your other comments on to our programmers. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
ocpxc02
Senior Member
USA
570 Posts |
Posted - 11/11/2009 : 11:15:01 AM
|
Ralph -
Those are good points. And, I hadn't thought about MaxMind needing this info. How about when you need to actually call the bank for verification? I'd think they would always need the full account number. How is this tackled?
Paul |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 11/11/2009 : 11:31:02 AM
|
quote:
[i]Originally posted by ocpxc02[/i]
[br]Ralph -
Those are good points. And, I hadn't thought about MaxMind needing this info. How about when you need to actually call the bank for verification? I'd think they would always need the full account number. How is this tackled?
Paul
Good question. I do not know the answer to that, but I will pass it on to our programmers. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
kevin
Administrator
USA
2668 Posts |
Posted - 11/11/2009 : 11:38:34 AM
|
| It is my understanding that the processing banks will be the maintainers of the full card information. Anyone below that tier should only store the first 6 and last 4 digits for bank and customer identification. Should it be necessary to have access to the full card number, this should be done via the Processor's Admin panel. I'm sure that the processor will require some type of validation that the user is sufficiently priviledged to access this information. |
Kevin Smith
Stone Edge Technologies, Inc.
920 Germantown Pike
Suite 112
Plymouth Meeting, PA 19462
610-994-3699 x112
kevin at stoneedge dot com |
|
|
|
ocpxc02
Senior Member
USA
570 Posts |
Posted - 11/11/2009 : 11:52:13 AM
|
quote:
[i]Originally posted by kevin[/i]
[br]It is my understanding that the processing banks will be the maintainers of the full card information. Anyone below that tier should only store the first 6 and last 4 digits for bank and customer identification. Should it be necessary to have access to the full card number, this should be done via the Processor's Admin panel. I'm sure that the processor will require some type of validation that the user is sufficiently priviledged to access this information.
So, not even the gateway will have the full number? Getting the info from the processor is going to be a royal PITA when manual verifications are required (unless banks will work with businesses when just the BIN+last 4 digits are known).
Ralph - Since you are just storing the BIN+last 4 right now, how are you handling any manual verifications (or do you just not do them)?
Paul |
|
|
|
geckoday
Member
339 Posts |
Posted - 11/12/2009 : 10:40:02 AM
|
Kevin is correct about how its supposed to work. Some gateways have the capability to show you the full card number when needed usually at an additional transaction cost. This is how the Network Merchants gateway works if your processor enables it and I'm fairly certain Authorize.Net does not support showing full card numbers. If your gateway doesn't support showing the full number or your processor doesn't enable it you will need to call your card processor to get the full number or to call the bank on your behalf.
Strangely, some card processors will balk at giving you the card number. For some reason, they will trust you not to write down every card number you get via POS or phone orders but giving you an occasional card number for a legitimate need is considered too dangerous even though its not prohibited by PCI-DSS (unless you are trying to qualify for SAQ A which you can't if you do card present anyway).
My processor falls into that last camp although I haven't pressed them to enable the ability to see full card numbers in the NMI gateway yet as we don't do manual verifications very often. So far, I have only needed the full card number once to force capture a voided transaction the customers bank refused to release the auth on and I got that directly from the customer. Yesterday I thought I was going to need to call American Express on some suspicious transactions (larger overnight ship orders not going to the billing address) but I looked the customer up on whitepages.com and called the cardholder directly. If your business requires more regular bank verification calls then you should make your expectations clear with your processor and/or gateway before eliminating card number storage. |
Ralph Day
Snow River
http://www.snowriver.com
Order Manager Version 5.916
Access 2003 SP3 w/hotfix
|
|
|
|
TimLevine
Senior Member
USA
660 Posts |
Posted - 11/12/2009 : 1:24:52 PM
|
| My Controller points out that a rather frequent occurrence for us is a scenario wherein a customer will initially place their order in our shopping cart using a credit card and then (usually as result of an addition, return, exchange, ect.) will call us up and have us manually enter a 2nd credit card number and place part of their order on the 1st credit card and the balance on the 2nd. Obviously, we'd like to make sure the ability to handle situations like this are supported in a token-based schema. |
Timothy B. Levine
Marketing Director/IT Manager
Earth Sun Moon Trading Company
111 N. Center St.; Grove City, PA 16127
ph. 724.458.1687 x311
fax. 724.458.4920
www.inkpixi.com
www.earthsunmoon.com
and the extensive SQL code that I promised to post at the conference is complete and can be found here:
http://www.stoneedge.net/forum/topic.asp?TOPIC_ID=7010 |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 11/12/2009 : 2:04:54 PM
|
Tim -
That would be no problem. The Order Manager will still be able to accept credit card numbers for new payments at View Orders, Manual Orders and POS. But once the payments are submitted, the account numbers will not be stored (except for first 6 and last 4 digits). |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
rjmosher
Starting Member
1 Posts |
Posted - 11/12/2009 : 8:46:25 PM
|
Barney,
We are at that cross roads of continuing with our present Payflow Pro gate way into 2010 for PCI-DSS compliance or saving a great deal of money if the Payflow Pro Link option is possible. Able Commerce has a third party option with NC Software Inc. which might work for our shopping cart, still working on that. My question is do you have any options for Payflow Link to interface with Stoneedge. |
Bob Mosher
Bellingham,WA |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 11/13/2009 : 10:04:44 AM
|
quote:
[i]Originally posted by rjmosher[/i]
[br]Barney,
We are at that cross roads of continuing with our present Payflow Pro gate way into 2010 for PCI-DSS compliance or saving a great deal of money if the Payflow Pro Link option is possible. Able Commerce has a third party option with NC Software Inc. which might work for our shopping cart, still working on that. My question is do you have any options for Payflow Link to interface with Stoneedge.
No, we do not plan to support Payflow Link. There are too many issues with trying to use it from a desktop application like the Order Manager. However, Payflow Pro does support tokenization (using their Transaction ID). We should have support for that early next year. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
solanums
Junior Member
83 Posts |
Posted - 11/13/2009 : 10:50:58 AM
|
I wish that Stone Edge made it more obvious if card information is being stored or not. I would like to see a form that combines all gateway and card storage settings, and is very clear about what's being stored and how to change these settings. The current scattering of parameters related to masking and storage is confusing to me.
That said, I think that tokens are the way to go. We're using Authorize.net and Pinnacle Cart, and if tokens are ever an option for us we'd probably implement them. However, most important to us is a clear and easy method to disable card storage across the board, and then selectively enable options such as storing first 6/last 4, etc. |
Access 2007 SP2
Windows XP Pro SP3 & Vista Business x64 SP2
Server Standard 2008 & MSSQL Server Express 2008
OM Enterprise 5.900 |
|
|
|
wabatson
Starting Member
1 Posts |
Posted - 01/07/2010 : 5:57:35 PM
|
When talking about the below processors/gateways supporting tokens, what about the original capture of the credit card number. Doesn't the original capture of the card pretty much touch most of the PCI compliancy issues?
Authorize.net, JetPay, ECHO, PayPal, Payflow Pro, QuickBooks Merchant Services, USAePay, etc.
For example I ahve a web server connected to a back end DB. A users connects via IE or Firefox and get a credit card form from the web server. The form then gets posted. The real card number goes through the network to your web server. Maybe it doesn't get stored in the DB but you still have to address all the compliancy issues for the network and web server. Is this the case with the token solutions above or am I missing some black magic. We have solution that uses a third party web page to collect the card number and then we obtain the token which we used for the life cycle of the trasnactions. In this case the card number never comes to our network or web servers. We are using a vendor called ProPay to acheive this. Is there someway to acheive the same with the processor/gateways mentioned above?
|
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 01/08/2010 : 09:47:31 AM
|
Those are valid questions. As far as the Order Manager is concerned, orders will either originate in a Web shopping cart or in the Order Manager itself. For Web orders, the shopping cart will have to deal with handling the credit card numbers and getting the tokens, and will have to get its own PA-DSS certification. The orders imported from the cart into the OM will no longer include credit card numbers (once this new system is in place). So for those orders, the OM will have only minimal security concerns.
For charges that originate in the Order Manager, there will be a new, secure system to collect the account number, pass it to the gateway, then either erase the entire account number, or just keep the first 6 and last 4 digits of it. That system will require PA-DSS certification, and we are working on that now. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
davidd
Starting Member
1 Posts |
Posted - 02/02/2010 : 4:04:33 PM
|
Any updates since January?
Casual browsing of the site (nice redesign btw) yields no updates, roadmaps, or announcements about when SEOM will be PCI compliant. Perhaps I'm not looking hard enough?
I'd like to switch from Mail Order Manager, but if there aren't any signs of progress towards PCI compliance, I may have to make the unfortunate upgrade to Dydacomp's already PCI-compliant software. |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 02/02/2010 : 4:25:57 PM
|
| The only update is that we are working on it now, and making good progress. We hope to have a Beta release with it out next month. We will be applying for certification around that time. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
mwalls59
New Member
USA
17 Posts |
Posted - 03/11/2010 : 2:48:03 PM
|
We are going to relaunch our site soon using Magento. We currently use Authorize.net, however we would like to switch to USA EPay. I have two questions:
1. Once available, will the new token payment system work with Magento / USA EPay combo?
2. Once available, will the new token payment system work with Magento / Authorize.net (CIM) combo?
As an aside, I spoke with someone at USA EPay about their Magento module...they wrote one for themselves here:
http://wiki.usaepay.com/merchant/support/carts/magento
I asked about us using Order Manager to capture additional charges, or to change the amount we charge a customer, and they said that this was something easily possible through their SOAP API. just thought I'd throw that out there...you guys probably already know about it!
Thanks,
Matt |
Edited by - mwalls59 on 03/11/2010 3:58:11 PM |
|
|
|
tstamplis
Junior Member
USA
56 Posts |
Posted - 03/11/2010 : 9:21:19 PM
|
| Ditch the Credit Card storing! Small merchants don't have the means to secure their network to PCI compliance standards! If nothing else, make it an "option" so us smaller companies can turn off storing of cc numbers. We use 3dcart which I don't think passes full cc numbers to SEOM anyway, but even for manual orders, I would prefer that once the card is processed, it is "forgotten". Not only for PCI compliance, but it is best practice these days to be able to list in your privacy policy statement that you do not retain credit card information. It just makes good sense all the way around! |
|
|
|
Barney Stone
Administrator
USA
6279 Posts |
Posted - 03/12/2010 : 09:00:35 AM
|
quote:
[i]Originally posted by mwalls59[/i]
[br]We are going to relaunch our site soon using Magento. We currently use Authorize.net, however we would like to switch to USA EPay. I have two questions:
1. Once available, will the new token payment system work with Magento / USA EPay combo?
2. Once available, will the new token payment system work with Magento / Authorize.net (CIM) combo?
As an aside, I spoke with someone at USA EPay about their Magento module...they wrote one for themselves here:
http://wiki.usaepay.com/merchant/support/carts/magento
I asked about us using Order Manager to capture additional charges, or to change the amount we charge a customer, and they said that this was something easily possible through their SOAP API. just thought I'd throw that out there...you guys probably already know about it!
Thanks,
Matt
Matt - Because the work is still in progress, I can't give you definite answers. For Magento/Authorize.net/CIM, most probably. For Magento/USAePay, possibly, but maybe not until a later release. |
Barney Stone, President
Stone Edge Technologies, Inc.
610-994-3699 ext. 111 |
|
|
|
Topic |
|
PA-DSS, PCI, Storing Credit Card Numbers, etc.
