Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 0 down vote favorite

I'm building a subscription-based website that needs to accept recurring payments. The concept is much like that of Netflix, but there is also a variation between the two.

  1. When a user attempts to sign up, ask for their credit card info and check to see if the CC is valid. Also make sure no credit card is linked to more than one user, so there will be a one-to-one mapping between a username and a credit card (one-to-many is fine too). If a new user attempts to register a CC that's already been stored, the registration fails.
  2. Give the user a 30-day trial period. Do not charge them if they don't want to continue their service
  3. Otherwise charge them

How could I achieve this? Is looking up credit card data to see if it's already on the system considered OK? I've been researching PayPal and Authorize.net, but I'm still not sure if I can do all the things above using a third-party gateway.

Also, does checking credit card validity (not talking about algorithmic checking) cost money? I don't want to pay whenever a spammer or a bot attempts to register an invalid card. This might be extremely costly.

I'm willing to go through PCI compliance scrutiny.

share|improve this question
1  
Hi Mark, welcome to IT Security. Your question as it stands is a bit too wide, and also most of it is not really a security question. The PCI compliance part is really the only part that is ontopic, but its not really a question... If you're asking something like "how should I save cc's in order to do recurring charges", that would probably be a good question, and probably what you should be asking here anyway.... – AviD♦ Jun 23 '12 at 22:15
Are you sure 1 is permitted by your merchant agreement? Most will not permit you to refuse a valid card for your own internal reasons. (Imagine what a nightmare it'd be for users to see a "FooCard" logo on a business and then have the business owner say, "Sure, we take FooCard, but not your FooCard.") WalMart had to take the credit card companies to court to get the right to do this even in limited circumstances. – David Schwartz Jun 24 '12 at 14:23
"I'm willing to go through PCI compliance scrutiny." - The fact you want to deny a credit card because its registered to another use, means you likely won' be compliant, and why exactly would you want to limit your customers to a single account? – Ramhound Jul 6 '12 at 14:36

2 Answers

up vote 1 down vote

Imo, this question doesn't exactly belong here as well but hey we're helpful people, right?

How do I verify a card's validity without making a charge on it? There's no way, but the charge can always be refunded. For example, what many companies like AreaNet do is that a 0.01$ charge is made on the credit card, and then the charge is refunded. This can be done automatically generally using the banking payment gateway's APIs. Since we're only programming it to refund all 0.01$ payments, it is not a security threat that someone can exploit and also helps us confirm the card.

Looking up to see if it's presently used? While many companies have been known to do this, they do it by storing the credit card information of their customer in plain text. Don't do that. Use a good undisclosed encryption algorithm with the key unique per user. However, before that remember to store a SHA hash of the true/original password in a mirror column next to the encrypted passwords. If the encryption algorithm is a custom variant then even better!

Every time you want to verify if a card is registered before, hash the input and run a simple "WHERE" queries in the hash equivalent column of the CC table. Whenever you want to use the CC, use the encryption algorithm along with the key to decrypt it and obtain the true information.

share|improve this answer
"Use a good undisclosed encryption algorithm with the key unique per user" - This is a horrible idea. The only good encrytion algorithm is one that has been verified to be secured by security experts. Using an undisclosed encryption algorithm is a guaranteed way of using a BROKEN encryption algorithm. – Ramhound Jul 6 '12 at 14:32
I think you're not getting my point in that case then @Ramhound Just because you do not publish what encryption your organization uses doesn't mean it's vulnerable. It's harder to crack hashes when you don't know what algorithm produces them, then even if it is a known one like SHA. I'm not asking to use a custom algorithm, just asking to keep the information regarded the standardized specific one private, hence the term "undisclosed" not "custom" or "private". – Rohan Durve - Decode141 Jul 6 '12 at 15:16
There is no reason not to disclose what algorithm you use. – Ramhound Jul 9 '12 at 11:23
I respectfully disagree. Disclosing details of the salting or salt+hashing mechanism you use can never be conducive to security, only harmful imo. – Rohan Durve - Decode141 Jul 9 '12 at 13:59
I guess my problem with your statement is that, there are only a few valid choices in a case like this, and its not that difficult to figure out once you have the information itself. – Ramhound Jul 10 '12 at 12:17
up vote -1 down vote

The procedure we use:

To first check that a card is valid, you can run Card Verification when storing it.

Card Verification relies on a series of nominal value (eg $1) Authorizations and those are usually followed up by a corresponding Void request.

To make sure that this credit card does not already exist in the vault, you can pass in the option to "Fail on Duplicate" when storing it.

share|improve this answer
1  
Hi Lisa, while the core of your answer is good, this is not a forum for promotion of goods or services, so I have removed those bits. – Rory Alsop♦ Jul 6 '12 at 0:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.