I'm using this authorize.net AIM class to communicate Credit Card info to the Payment gateway:

http://www.micahcarrick.com/04-19-2005/php-authorizenet-aim-interfacing-class.html

This works fine, but I wanted to add another layer to this. Before these values get CURL'd over to Authorize.net, I'm dumping these values into a MySQL database. All the values are dumping in as expected, except the Credit Card #. I use a series of dummy cards provided by the script that will test the gateway's response code, but the number that dumps into the database is not the number I put into the input field. Maybe it's some kind of encryption, but I don't see that in the class.

So, these numbers:
370000000000002 - AMEX
6011000000000012 - Discover

All turn into this number in the database: 2147483647

Anyone know what's going on here? Thanks!

Regards,
Matt

    Hi!

    What's the field type you are saving the credit card number in?

      Hey,
      The Credit Card field is an "INT" field with a max of 40 characters.

      Regards,
      Matt

        Is it possible that number is a phone number and it is getting put in the wrong field along with all dashes and or parenthesis being removed because it is an integer field?

          I'm not asking the user for a phone number. And not only that, the number that is showing in the database is always the same even when I change all the fields, so I'm starting to believe this value is not coming from my form input.

          Regards,
          Matt

            The values are being inserted into the database before being cURLed to Authorize.net, right?

            So, the number being inserted also can't be coming from Authorize.net, correct?

            Which would mean the number being inserted has to be coming from your script unless the database field type was date, datetime, timestamp, or something like that in which case a value would be inserted regardless.

            I would set up an empty page to post to and echo all the variables in the form just to see what the responses are, and if my credit card number is echoed fine I would have to conclude that somewhere in the script the value for that variable is being changed prior to being inserted in the database. So, I would probably move my insert statement up and see if that helps...if the statement makes it to the top and it is still being inserted incorrectly, I would know that there is a wrong variable's value being inserted into the database instead of the one I wanted to insert.

            It's difficult because I don't know your script, and I certainly know how it is to have an unexplainable mishap and you look over your code to finally discover that you typed $crditcardnumber instead of $creditcardnumber (for example). However, without actually viewing the script, there's not much else I can do except walk you through a debug process.

              Credit card numbers are not integers, they're just strings of digits (it makes no sense to add them, increase them, or order them). The INT type is the wrong one to use. Certainly not an INT type like the one you're using that can only store integers in the range -2147483648 .. 2147483647. (That "size" thing MySQL gives you is just for cosmetic purposes and has nothing to do with the value stored.)

              Still, storing credit card numbers? Why? You're not handling the transaction, authorize.net is; you've got no use for the things.

              Even if you do have a legitimate reason to be harvesting credit card numbers, unless you're compliant with the necessary security practices demanded by the credit card companies you can easily find yourself being blacklisted by them (at best).

                If you want to have an account based store and simplify things for your customers, some may appreciate not having to have their credit card "in hand" each time they want to make a purchase.

                PayPal stores your credit card number and if you make a purchase through PayPal without having enough on your account to cover the purchase, PayPal automatically takes it from your credit card.

                There are all kinds of reasons for storing a credit card numbers.

                  Gee, you know I'd never have been able to think of any of those for myself.

                  ryneaux wrote:

                  If you want to have an account based store and simplify things for your customers, some may appreciate not having to have their credit card "in hand" each time they want to make a purchase.

                  Standard security tradeoff: cheapness, convenience, and effectiveness. Cheap and convenient is weak; effective and cheap is inconvenient; effective and convenient is expensive. If you make it more convenient to use either the cost of implementing it goes up or it becomes less secure.

                  PayPal stores your credit card number and if you make a purchase through PayPal without having enough on your account to cover the purchase, PayPal automatically takes it from your credit card.

                  Irrelevant in this case: the transaction is being processed by another payment provider.

                  There are all kinds of reasons for storing a credit card numbers.

                  NO, really? No wonder there are all these requirements that credit card companies demand of anyone who wants to store the things. Of course, I'm sure matt6805 is already aware of all this, since it's part of the contract with Authorize.net.

                    Ok, that was it! Changing the DB field type to "Varcar" is producing the results I'm looking for. What I'm doing is storing all the users info so the next time they come back to my payment form, they can enter their email address, their record is pulled, and all their info is pre-populated in the form.

                    Is there a more secure way to do this? The form is using SSL, and so I assume the data being dumped into the database is secure from eavesdropping correct?

                    I appreciate your help!

                    Regards,
                    Matt

                      I have ran a web design/development company for 9 years, we accept credit card payments directly without processing through a gateway of any kind. All invoices for clients are available online through our own created accounting system for as long as they have done business with us, including each and every credit card they used to make a payment so that it is referred to upon their invoice for their own records.

                      There aren't any problems, never have been and never will be, and the credit card company hasn't once asked us about our accounting system or wanted to check the security of it. The only time you will have any problems is if it becomes a pattern that there is fraud or theft from a credit card that had previously been used on your site/system. At which point there would be an investigation to find the person within the company or a hole in your system. The only thing the credit card company cares about is that their card is being used by people through you (because with time they will give you discounted rates) and that you aren't responsible for theft/fraud.

                      However, in my experience the majority of applications attacked are open source apps as they can easily be picked to pieces in search of weaknesses.

                      As for "Weedpacket" I certainly didn't want to upset you and it seems that my attempts to help or be of assistance to Matt have stepped on your toes, so I apologize for any pain or suffering I (or my suggestions) have caused you. I am guessing that I have invaded your territory and I will leave now.

                        ryneaux;10911419 wrote:

                        As for "Weedpacket" I certainly didn't want to upset you and it seems that my attempts to help or be of assistance to Matt have stepped on your toes, so I apologize for any pain or suffering I (or my suggestions) have caused you. I am guessing that I have invaded your territory and I will leave now.

                        I believe that Weedpacket's intent was good; he was merely trying to stop someone from violating standard security protocols already established. If everyone based their application models on Weedpacket's security recommendation, maybe there would be less fraud in the first place.

                        Do you also wait until the first time your database gets dropped and/or exposed before you start sanitizing all user input in your query strings? I only ask, because it seems like you're arguing that you should wait until your database is compromised resulting in credit card fraud, and only then should you consider all of this "security" mumbo-jumbo.

                          Wow, it always amazes me how arguments break out on message boards. Weedpacket, thank you for your help and although you may be correct on all your points, you're clearly coming off as a prick 🙂

                          Your tone (even though text), is obnoxious. It counter productive, and doesn't help anyone or foster productive discussions. We're not all PHP security masters here. In fact, most of us are here to learn and don't need to be abused by someone with 18,000 + posts.

                          "Gee, you know I'd never have been able to think of any of those for myself."
                          That's really not necessary.

                          I'm stepping out of this thread. I appreciate everyones help 🙂

                          Regards,
                          Matt

                            matt6805 wrote:

                            "Gee, you know I'd never have been able to think of any of those for myself."
                            That's really not necessary.

                            No; probably not, and I apologise. Of course there are reasons to store credit card numbers. I never said there weren't. If I was offended it was by the implication that I didn't know this. If I hadn't known it I wouldn't have known about the DSS - the very existence of which implies it (and how do you think I know about it?) - and I wouldn't have had anything to say on the subject and therefore wouldn't have said anything. Hence the DUH! response: what sensible reason could there have been to tell me something I so obviously already know (the post obviously wasn't directed at you, since you're the one wanting to do it in the first place, so obviously you had a reason for doing it)? What's that supposed to prove? By maybe I'm reading too much into it and it's just a matter of my post not being read carefully enough.

                            There are responsibilities attached, to the practice, and given the requirements that have to be satisfied, they have to be very good reasons to justify it. That was the point of the post and that was what ryneaux totally missed.

                            As for "We're not all PHP security masters here." No, we're not. But if you're storing credit card numbers you do need a security professional involved somewhere in the process. And should such a person come along, which would you prefer: one that says the amateur is wrong and what they're wrong about, and puts them right, or one that keeps quiet for fear of hurting their feelings? Besides, what did I ever do to you?

                            Even though you've already left the thread, I will answer your question by referring you to the links I gave earlier. The short answer is no, just using SSL is not enough. That encrypts the traffic between the server and the client and has absolutely nothing to do with the database.

                            bradgrafelman wrote:

                            I only ask, because it seems like you're arguing that you should wait until your database is compromised resulting in credit card fraud, and only then should you consider all of this "security" mumbo-jumbo.

                            If Visa decides to charge the full $500,000 fine (or Euros or whatever) for the incident it might help concentrate the mind.

                              Write a Reply...