cancel
Showing results for 
Search instead for 
Did you mean: 

CIM - Display card type, expiration date, and name on card

I don't have any specific coding questions about this at the moment. Mainly I am interested in wether or not this is PCI compliant.

 

From what I gathered by reading other topics about displaying the expiration date, the right way to do it is to store the expiration date separately from the CC number. In cases where a user may have multiple payment profiles would I be allowed to store each expiration date with each payment profile ID in my own table?

 

In addition, would I also be allowed to store the card type and name on the card (in cases where the BillTo name is different than the name on the card)?

 

I see that the name on card and card type aren't stored so I would only be able to display them from my own database. Would this be an okay way to store things?:

 

[TABLE users]

  userID : 1234

  email : john@doe.com

  userProfileID : 4321 (Authorize.net ID)

 

[TABLE paymentProfiles]

  paymentProfileID : 12 (Authorize.net payment profile ID)

  userProfileID : 4321 (Authorize.net ID)

  nameOnCard : John Doe

  expDate : 1212

jdallen88
Contributor
1 ACCEPTED SOLUTION

Accepted Solutions

Authorize.net doesn't require the name on the card, as far as I know. All you should need is card number and expiration date, neither of which should be stored locally. You can retrieve a masked version of the credit card number from Authorize.net billing profiles, this should be sufficient for allowing customers to identify which billing profile is which. You can just mark the profile as expired (in your own db) when it fails to go through the first time, and send them a notification that their card has expired and they need to update it.

View solution in original post

8 REPLIES 8

I forgot to mention, the reason I want to store the card info is so the customer can see the details when viewing their account. In instances where they need to change their expiration date it would seem silly to show that we also forgot the name that was on the card and need that field refilled as well.

jdallen88
Contributor

Authorize.net doesn't require the name on the card, as far as I know. All you should need is card number and expiration date, neither of which should be stored locally. You can retrieve a masked version of the credit card number from Authorize.net billing profiles, this should be sufficient for allowing customers to identify which billing profile is which. You can just mark the profile as expired (in your own db) when it fails to go through the first time, and send them a notification that their card has expired and they need to update it.

I see, so the only thing I should store is the profileID from Authorize.net? And you're right, the name on the card isn't required but is there any reason for using it other than user familiarity with forms (most web services I use ask for it). If I don't save the name on the card I will probably just drop it then.

 

In my situation, since I am doing a subscription based service with CIM and will be running a daily cron job to determine when accounts need to be charged, would it be a good solution to run an auth_only one month prior to their due date and then send an expired card notice that way?

I suppose that would be one way to do it, but I think authorize transactions can only be captured within a week or something liike that, so if you do it a whole month in advance, you'll generate an extra transaction fee every month and that'll add up. Better to do it within the time limit, so if their card is still good you can just capture and move on and you'lll only get charged once. Also note that if you bill on the first of every month, it may be expired now when it wasn't expired a few days before, so you'll have to charge on the last day of every month rather than the first day to be safe.

Thanks for clearing things up for me. Yeah, I would want to make sure the dates aren't too far apart and the service is charged yearly on the day they signed up. I suppose it wouldn't hurt to check if the card is expired a few weeks before the due date and maybe even a month ahead in case it checks on the 30th or something like you mentioned.

 

On a similar note to securely managing data, are there any problems with transmitting form data (name, address, credit card number, expiration date, etc.) through AJAX and returning error messages for invalid card numbers, duplicate payment profiles, etc? I'd like to catch and display all the errors before the user is allowed to submit the form.

The only way to catch -all- the errors is to submit the form and see what happens. AJAX won't really help you there. You don't need AJAX for basic field validation either. To answer what I think you're trying to say, it's okay to access the form values with Javascript so long as you're very careful to not print them to the screen or shuffle them from hidden fields to visible fields or anything stupid like that. You can even transmit the data via POST (not GET) using AJAX as long as the page you're posting to is secured with SSL, it's no more dangerous than posting to it by submitting a form. The only question is why you'd want to mess with AJAX here.

Using AJAX just seems like a logical solution to me, but I may be a bit biased because I do use it in many situations. Currently my form does basic validation (checks to see if the fields are completed, checks if the expiration date if is in the past, etc.). Then, if that validates, the data is sent to another secured page via AJAX which only listens for form data and a few variables. One variable accepts a type of action such as "delete", "add", "update", "purchase" for payment profiles and then passes the form data to the requested function. The function always ends with writing the error which is then made visible on the original form page... unless the form is submitted successfully then the user would be taken to a page that shows the transaction was successful.

 

If there's another way to do this I would be interested to know.

Usually you just submit the form, have the page pass the data to Authorize.net internally, then if there's an error, display the error along with the filled-out form (minus credit card data, for security reasons). If there's no error, you of course display a success message. You can achieve more or less the same mechanics with AJAX, I suppose, but I prefer to not leave things reliant on the browser, simply because (a) you can't guarantee Javascript will always run properly and (b) hackers will turn off Javascript or modify the Javascript code to suit their purposes.