Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Manually processing CC - Split Credit Card E-Mail Address not working


J_Fyrebird

Recommended Posts

My client is manually processing credit cards - his preference.

 

Anyway, with the recent upgrade to osC v2.3.1, the credit card payment module (the 'default' module) is now no longer recognizing that an email address has been set for the option "Split Credit Card E-Mail Address". In the file cc.php, lines 164 - 173 are as follows:

 

function before_process() {

global $HTTP_POST_VARS, $order;

 

if ( (defined('MODULE_PAYMENT_CC_EMAIL')) && (tep_validate_email(MODULE_PAYMENT_CC_EMAIL)) ) {

$len = strlen($HTTP_POST_VARS['cc_number']);

 

$this->cc_middle = substr($HTTP_POST_VARS['cc_number'], 4, ($len-8));

$order->info['cc_number'] = substr($HTTP_POST_VARS['cc_number'], 0, 4) . str_repeat('X', (strlen($HTTP_POST_VARS['cc_number']) - 8)) . substr($HTTP_POST_VARS['cc_number'], -4);

}

}

 

From what I can tell, everything is correct... but it seems to have stopped working. The email entered in the Admin side, is a valid email account.

 

As i said, previously, this was working correctly.

Link to comment
Share on other sites

@J_Fyrebird

 

Unless your client is PCI DSS compliant, he CAN NOT legally process credit cards. If YOU or anyone (another developer) aids him with being able to process credit cards you (and anyone else) can be held legally responsible for the illegal activity. Having said that, I don't think you will find support for your question on this forum.

 

 

 

Chris

Link to comment
Share on other sites

@J_Fyrebird

 

Well, there are no differences in the mail handling function between v2.2 and v2.3.1, I would guess it is the database tables that are the issue. If you would like detailed help, please post the site URL (to verify PCI DSS compliance) and I would be happy to help you with the tables and queries.

 

 

 

Chris

Link to comment
Share on other sites

  • 2 weeks later...

@J_Fyrebird

 

Well, there are no differences in the mail handling function between v2.2 and v2.3.1, I would guess it is the database tables that are the issue. If you would like detailed help, please post the site URL (to verify PCI DSS compliance) and I would be happy to help you with the tables and queries.

 

 

 

Chris

 

I realize I'm new here, and all, but really, I feel I must protest a particular point.

 

PCI DSS is **NOT** a LAW, it is a standard. Every time you bluster about the "illegality" of manually processing cards I cringe.

 

Visa and other issuers are not government agencies. They are businesses. At worst, violation of PCI standards is a breach of contract, a civil matter, and the "fines" involved are from Visa/MC/etc, not your local state/provincial governments. Furthermore, they are for *breeches* and not for solely being non-compliant, as I understand.

 

Finally, the PCI standards prohibit the *storage* of track data and CVV numbers. A PCI compliant manual processing solution *is* possible, but the way you carry on about the "illegal" nature of manually processing credit cards, folks seem to assume the loudest mouth is the wisest, or more likely, they just would rather not get involved in a urination contest with you over it.

 

Misuse of credit card information *is* illegal, but misuse would be, for example, taking the captured information and fraudulently using that to make charges.Misuse is *not* taking the information and using this information from your own customer to process a sale they have agreed to in the first place.

 

When I take orders over the phone I need the CVV to process. I don't store the number. When a customer emails me the information, I delete the email after I have processed it. While the email route may not be "compliant" it's not "illegal" and I curtail my risk of a breech by deleting the information after I've processed the order.

 

Please, stop trying to the the PCI "police."

 

If you still feel that PCI is a law, please post for me the federal or provincial statutes (for Canada) or the U.S. equivalent.

 

Cheers.

Link to comment
Share on other sites

Several states in the US have made it into LAW. inc. Washington, Nevada and Minnesota

Link to comment
Share on other sites

@@mrbyte

 

I don't claim to be the PCI "police'. However, I have worked with several clients in several states that received Federal warnings after their sites were audited and failed PCI compliance policies. As Nick Mentioned above, there are several states in the USA and almost ALL of the provinces in Canada that now have LAWS regarding the handling of credit card information. I am confident that within the next year or so, that ALL states in the USA will have a law in effect governing the handling of electronic information collected. These laws will become common in an effort to fight credit card fraud.

 

I have been doing this for over 10 years, please don't preach to me about current policies. If you are MORE qualified than I am to speak on the subject, please state your credentials and post any relevant links that would contradict the information I have provided.

 

 

Chris

Edited by DunWeb
Link to comment
Share on other sites

http://www.pcicomplianceguide.org/security-tips-20090227-pci-compliance-law.php

 

"Is PCI compliance a law? The short answer is no. The long answer is that while it is not currently a federal law, there are state laws that are already in effect (and some that may go into effect) to force components of the PCI Data Security Standard (PCI DSS) into law. In addition, there is a big push by legislatures and industry trade association to enact a federal law around data security and breach notification.

n 2007 Minnesota established the “Plastic Card Security Act” which states that any company that is breached and is found to have been storing “prohibited” PCI data (e.g., magnetic stripe , CVV codes, track data etc) are required to reimburse banks and other entities for costs associated with blocking and reissuing cards. This law also opens up these companies to private lawsuits. Currently, the law does not affect Level 4 merchants (less than 20,000 transactions a year).

 

Massachusetts recently announced that it will introduce a new law, 201 CMR 17.00, which pulls some important concepts from the PCI DSS. For example, the law has requirements around limiting data collected, requiring written security policies and data encryption. This law would apply to any company who has customer data (or handles it) from customers based in Massachusetts. Recently, compliance enforcement of this law was pushed back until 2010, but unlike previous laws, this one does not have a stipulation that excludes Level 4 merchants from complying with the legislation.

 

Currently none of these state laws mentioned above specifically call out PCI compliance, but the parallel is obvious. More and more states are requiring notifications of customers upon a data breach and as time goes on, the definition of what data is considered personal information will expand to include credit card numbers.

 

Will we ever see adherence to PCI compliance called out specifically as a law? It is unlikely, but nothing is outside the realm of possibility. The government typically moves slowly and PCI compliance is still an evolving state. It will be difficult for legislatures to keep up with all the necessary technology changes. It is more likely that as time goes on, more and more states will classify credit card information as personal information and find punitive measures to make companies with negligent/non-existent security accountable. In the future there may also be direct financial incentives to companies with high security postures and PCI compliance is a great step towards becoming secure."

 

The odds are 98% of OSC users are exempt.

Link to comment
Share on other sites

@@mrbyte

 

A little light reading for you...

 

 

Approximately 46 states have strict Security Breach Notification Laws
http://www.pcicomplianceguide.org/

 

From the same source http://www.pcicomplianceguide.org/security-tips-20090130-security_vs_pci_compliance.php

 

With the advent of the new year, Nevada becomes the first state to explicitly mandate compliance with the Payment Card Industry (PCI) Data Security Standard (PCI-DSS) by businesses that accept credit or debt cards. Nevada Senate Bill 227 (the Nevada Act), which was signed into law in May 2009, takes effect January 1, 2010. The law amends Chapter 603A of the Nevada Revised Statutes to require that any data collector doing business in Nevada that accepts a payment card in connection with a sale of goods or services, must comply with the current version of the PCI-DSS, as adopted by the PCI Security Standards Council no later than the date for compliance set forth in the PCI-DSS or by the PCI Security Standards Council.
http://techrazorblog.com/2010/01/01/another-step-towards-mandatory-pci-compliance-and-heightened-encryption-standards/ https://www.leg.state.nv.us/75th2009/Bills/SB/SB227_EN.pdf

 

 

In 2007, Minnesota became one of the first states to adopt a set of enforceable standards that protect credit card data. Since then, Nevada, Washington and Massachusetts have also adopted similar laws. Many other states are currently looking at similar legislation. While it may not be law in your state yet, it most likely will be soon. Regardless, these regulations are still enforced by the banks and by the card brands (Check with your merchant bank for additional deadlines).You may also be assessed a monthly non-compliance fee from your current merchant account provider.
http://www.naylornetwork.com/nay-adviser/articles/index.asp?aid=141516&issueID=25003

 

 

 

if you take the time to GOOGLE, you will find MUCH more about PCI DSS compliance. Your ignorance on the subject is astounding.

 

 

 

Chris

Link to comment
Share on other sites

PCI DSS compliance was incorporated into the Canadian Privacy Act in 2010. Click the link to learn more. The act governs ALL of Canada.

 

 

 

Chris

 

From what I found, reading past the definitions is that the CPA governs GOVERNMENT entities.

 

The other stuff you quoted, obviously without reading, require reasonable safeguards to prevent breeches, require encryption for transmission of data, and set forth the responsibility in the event of a breech.

 

Again, nothing that prohibits the use of a manual card entry system.

 

So, while I'm partially incorrect in stating that PCI isn't law, you're also incorrect to state that manual entry is illegal.

 

 

@@mrbyte

 

I don't claim to be the PCI "police'. However, I have worked with several clients in several states that received Federal warnings after their sites were audited and failed PCI compliance policies. As Nick Mentioned above, there are several states in the USA and almost ALL of the provinces in Canada that now have LAWS regarding the handling of credit card information. I am confident that within the next year or so, that ALL states in the USA will have a law in effect governing the handling of electronic information collected. These laws will become common in an effort to fight credit card fraud.

 

I have been doing this for over 10 years, please don't preach to me about current policies. If you are MORE qualified than I am to speak on the subject, please state your credentials and post any relevant links that would contradict the information I have provided.

 

 

Chris

 

You may not "claim" to be the PCI police, but you act like it. As far as my qualifications, I haven't seen YOUR credentials, but I'm just a guy that's sick of the loudest mouth winning. Nothing you have quoted really does anything for your case; most of the material actually proves mine.

 

Cheers.

Edited by mrbyte
Link to comment
Share on other sites

The silence is deafening.

 

Now, to address the whole CV2 number problem, what I did in ZenCart's manual credit card module was to mangle the CV2 info. This is then emailed to the admin email address. Nothing in the email makes mention of the obfuscation of the CV2 number. I know the number is mangled, and I alone know what to do to unmangle it. After the CV2 number is mangled and emailed, it is not retained anywhere. Others wrote the module, I just added the mangle code.

 

Anyone looking at the code would know as well how to unmangle the number, however this is only to stop/delay someone that's managed to gain access to the admin and email of a given store. Anyone that installed this module would be informed as part of the install process.

 

I agree that a gateway is the best way, regardless of what my stance on PCI is. However, I also think that for a startup, that doesn't (yet) wish to pay the $20-50 monthly fees for a gateway, and already has a card-not-present enabled terminal, a manual option would be nice.

Link to comment
Share on other sites

If you save the info and process it manually then you are taking a large risk for saving some pennies.

 

Even if you are in a country (or state) where you currently are not required by law to follow the PCI regulations, you are still liable for sanctions and fines from your merchant account provider, Visa and Master Card.

 

And if someone manages to sift payment information from you and it is shown that you have been lax in handling customer payment data, then this will impact your business reputation as-well as open your for civil suits from your customers.

Link to comment
Share on other sites

If you save the info and process it manually then you are taking a large risk for saving some pennies.

 

Even if you are in a country (or state) where you currently are not required by law to follow the PCI regulations, you are still liable for sanctions and fines from your merchant account provider, Visa and Master Card.

 

And if someone manages to sift payment information from you and it is shown that you have been lax in handling customer payment data, then this will impact your business reputation as-well as open your for civil suits from your customers.

 

Which could happen even with paper records from phone/mail orders. If someone were to use a manual module and NOT delete the CV2 info after use, that itself is a PCI violation, clear as day. So, while I agree with you about the consequences of a breach, I still do not believe that PCI or the law prohibit manual processing of credit cards.

 

According to the PCI DSS requirement 3.2, the storage of sensitive authentication data after authorization is strictly prohibited. "After authorization" is the critical bit here. And I maintain that mangling the number as I described above, and using SSL and other encryption when receiving the email off of the email server used for the store's domain, by which I mean the email is not sent anywhere outside the host, covers the encryption requirements of PCI for data transmission.

 

Someone makes the purchase, admin get's the info, processes the transaction and deletes the sensitive info. Compliance preserved.

 

I agree that a gateway is the best way, regardless of what my stance on PCI is. However, I also think that for a startup, that doesn't (yet) wish to pay the $20-50 monthly fees for a gateway, and already has a card-not-present enabled terminal, a manual option would be nice.

 

I'm talking a limited amount of processing here, say under 10 transactions a month. At that level, it's more than pennies to be saved. Beyond that, yeah, just the possibility of fraud or erroneous data entry alone should be enough for a responsible store owner to get a gateway.

 

My main objection is the misleading tone taken by others when this question is even asked. It *is* misleading to say that manually processing cards is illegal, and I've proven it.

 

But I will also say that processing a large amount of transactions manually is insane, opens you to fraud, errors and shouldn't be done.

Link to comment
Share on other sites

1. Check that your merchant account agreement allows you to manually process payments where info has been collected online. HINT: In most cases it will be against your TOS.

 

2. If you wish to manually process payments with info collected online, do not use CVV2 you are not allowed to save it in any form. (even if you delete it after use)

 

In regards to Manual processing CVV2 is only for real time use, when the customer are talking to you on the phone or standing in front of you and you key it directly into the MOTO terminal.

 

Even if you follow 1 and 2 , if you are not PCi compliant you are even then liable for fines and sanctions from merchant account providers and credit card companies.

 

And in some countries and states/areas it is even against the law to handle payment data in an insecure way. (And this is an area which is only getting more and more regulated)

 

So the short version, if you are not PCI compliant use a 3 party payment provider instead.

 

That a online payment gateway to process cc is 20 usd a month is not a valid argument , you can get a PayPal account for free and with no monthly fees. (there are several other alternatives too without monthly fees)

Link to comment
Share on other sites

I'm not using the correct terminology, CVV, CVV2, CV2... Whatever the 3-digit "magic number" on the back is called. PCI 2, section 3.2 specifically says it can be saved long enough to process and get authorization, and then must be deleted. It further states that it can still be saved, in a safe and secure manner if there is a valid business case to be made for doing so.

Link to comment
Share on other sites

I'm not using the correct terminology, CVV, CVV2, CV2... Whatever the 3-digit "magic number" on the back is called. PCI 2, section 3.2 specifically says it can be saved long enough to process and get authorization, and then must be deleted. It further states that it can still be saved, in a safe and secure manner if there is a valid business case to be made for doing so.

 

No, CVV2, CVC2, CID, CAV2 falls under 3.2.2 which you are not allowed to store under any circumstances.

 

PCI DSS V2

 

Requirements:

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.

 

Testing Procedures:

3.2.2 For a sample of system components, examine data sources, including but not limited to the following, and verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance:
Edited by toyicebear
Link to comment
Share on other sites

I have been reading this thread with interest. Not really interest, but more astonishment. Why someone would run the risk of not being compliant is beyond me. The business owner must have little regard for their customer details and security. From a customers point of view, i would not trust anyone with my details unless i knew what they were doing with them.

 

I say if this person is so convinced that they are allowed to do what they are doing, lets post the business name and report them to the credit card company. They should have nothing to worry about as they comply.

 

What is even more astonishing is that someone is trying to help them do things like this. That must make them equally responsible should anything happen.( i think this could be the reason that the op is getting so little help.)

 

It really is about time that addons like these were wiped off the oscommerce site, that would stop so many people trying to install them, and would show that oscommerce is a responsible organisation.

REMEMBER BACKUP, BACKUP AND BACKUP

Link to comment
Share on other sites

@@14steve14

 

It really is about time that addons like these were wiped off the oscommerce site, that would stop so many people trying to install them, and would show that oscommerce is a responsible organisation.

 

I agree wholeheartedly !

 

 

 

Chris

Link to comment
Share on other sites

I have been reading this thread with interest. Not really interest, but more astonishment. Why someone would run the risk of not being compliant is beyond me. The business owner must have little regard for their customer details and security. From a customers point of view, i would not trust anyone with my details unless i knew what they were doing with them.

Unfortunaltey, there's no way for you to know. Even if a shop uses a module that collects credit card data, like authorize.net, that doesn't mean the shop owner is not storing the details. I see this quite often. But I don't tihnk it is because of their regard for their customers. It is just a business decision in that it makes it easier for them to handle adjustments. I'm not condoning it. That is just the way it is. I don't store cc data but I get requests from clients quite often saying something like, "I forgot to order this option. Just add it on and charge my card." It would make it easier on me if I could do that. Some shops do.

 

I say if this person is so convinced that they are allowed to do what they are doing, lets post the business name and report them to the credit card company. They should have nothing to worry about as they comply.

Some PCI companies only require the shop owner to state that if they are storing credit card data, that it is secure. And many shops owners assume their admins are secue since they have to login to get to it. So, in most cases, I don't think the shop owners that do this see any sort of problem with it.

 

What is even more astonishing is that someone is trying to help them do things like this. That must make them equally responsible should anything happen.( i think this could be the reason that the op is getting so little help.)

The whole purpose of PCI, in my opinion, was to pass the responsibility to the shop owner. If the shop owner agrees to take on that responsibility, then any subsequent problems should be on them.

 

It really is about time that addons like these were wiped off the oscommerce site, that would stop so many people trying to install them, and would show that oscommerce is a responsible organisation.

You would have to remove a lot of modules to do this. All one would have to do is enable the Check/Money Order and change the text to have the customer enter their cc data. Customers would do it, I'd bet.

 

I understand what you are saying and agree with much of it but many shop owners have real stores where they have credit card terminals. It is less expensive to use those when making a charge and easier in many cases so those shop owners want such an option. It isn't secure and won't pass PCI in most cases but the real world sometimes takes precedence over rules that are difficult to enforce.

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

You just can't fix stupid !

 

 

 

 

Chris

You're right, no matter how hard I try to fix you, you're still stupid, Dunweb.

 

I have the PCI spec in front of me, and 3.2 in it's entirety says:

 

3.2 Do not store sensitive data after authorization, even if encrypted. Sensitive data includes the data as cited in following Requirements 3.2.1 through 3.2.3

 

Now, do I need to continue, or are we all following along. Good. Note the note that says sensitive data may be stored if there is a business justification and it is stored securely?

 

Is it because you make so much money misinterpreting the standards? Or is it really just an inability to read, comprehend and understand basic English and how outlines and such work?

 

Either way, you are a profiteering blowhard.

 

As far as "Turning me in" go ahead. Good luck with that...

 

Cheers

Link to comment
Share on other sites

90% of addons need to be nuked.

 

------------------------------------------------

 

3.2, I believe (I cannot remember the exact words, and cannot be bothered to look), states that sensitive data is not to be stored. It is obvious to all that CVV is sensitive data...

 

Is there a note that says sensitive data may be stored if there is a business need and is secure? I can't remember that, but I'm sure there is if you say so.

 

I cannot foresee any shopkeep running osCommerce being secure enough to allow this. So it's really null and void, I'd say.

 

I've said before that a gateway is really the better way to do it, but it's been lost in the noise.

 

I quoted 3.2 above. That's straight off the PDF file from the PCI committee/council/whatever's website, and you can get it here: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

Link to comment
Share on other sites

Put on your reading glasses and read 3.2.2 and take note that outside of other card authorization information that CVV2 (card verification code) is specifically mentioned and that it should not be stored under any circumstances.

 

verify that the three-digit or four-digit card verification code or value printed on the front of the card or the signature panel (CVV2, CVC2, CID, CAV2 data) is not stored under any circumstance

 

For anyone who are still unsure they should contact their merchant account provider and inquire about manually processing of orders where the payment information has been collected online.

Link to comment
Share on other sites

Put on your reading glasses and read 3.2.2 and take note that outside of other card authorization information that CVV2 (card verification code) is specifically mentioned and that it should not be stored under any circumstances.

 

 

 

For anyone who are still unsure they should contact their merchant account provider and inquire about manually processing of orders where the payment information has been collected online.

 

Now flip over to the PA-DSS which adds a bit of clarification to PCI-DSS 3.2.2:

 

1.1.2 AFTER AUTHORIZATION (emphasis mine) do not store the card verification value or code (three or four-digit blah blah)

 

Aligns with PCI-DSS Requirement 3.2.2 (emphasis theirs...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...