Detecting throw away and virtual Credit Cards [closed]

Closed. This question is off-topic. It is not currently accepting answers. 开发者_C百科

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 10 years ago.

Improve this question

The type of business I run allows customers to get results before they pay. I take their credit card information when they sign up, and afterwords anywhere from a week to a month charge them for my services. Most of the time this goes smoothly, but occasionally people will try and game the system by using virtual credit cards, and throw away debit cards (like you might buy at Wallmart).

I've done some research and found http://en.wikipedia.org/wiki/List_of_Bank_Identification_Numbers, but it's not a complete list. Is there anyway to identify where the cards come from; specifically virtual and throw away cards.

Or has anyone had any experience with this issue, and might be able to give me some ideas for combating this problem?

---

The pre-auth will not solve this issue. Throw away cards will pre-auth successfully, so don't allow a way to differentiate between temporary cards and long term cards.

Pre-authing itself has a number of issues, the main one being that each card issuer will hold the pre-auth value for a varying amount of time, anywhere from 2 days to 30 days. This can lead to issues where you either pre-auth too frequently (which really annoys the customer, because it looks like money is constantly dripping from their account) or not frequently enough (so that the pre-auth drops off and you have no guarantee the funds are available when you actually want to take settlement)

Unfortunately the issue you face is something you just need to cope with, or change your business model! In fairness ANY type of card could run into issues with your current model. There is no guarantee that a long term card will have funds available constantly, or not be cancelled (due to card being lost for example) or expiring.

Can you imagine walking into a shop and being told at the till, "thanks, but dont pay us now - just leave your card details and we'll collect from you at the end of the month". It would be ripe for abuse. Sorry to be so blunt but you either need to factor that abuse into your costs, or find a different model. One alternative may be to make an upfront charge for 'credits', which are spent as the service is provided, then infrequently perform a repeat authorisation/settlement to top up the credits (and put the account on hold if the auth declines). You'd need to make sure your service provider uses the Visa Account Updater service, and the Mastercard Automated Billing updater. These services allow for repeat authorisations by automatically updating cards that have expired, or been replaced with the new card details. Any cards that have been cancelled will drop off and decline.

---

Put a hold (Authorization) transaction on the amount, and renew it every x days as required until you decide to keep it or release it

Not all CC service providers support hold transactions however, so may be easier to bill the full amount initially and offer a full refund if not satisfied

Remember you should NOT be storing CC numbers, only transaction references from your CC service provider

Use a full service payment provider like paymentexpress to get access to hold services etc

---

You could also put funds into an escrow. Money is drawn from the account and put in escrow and then when the job is done, both parties agree payment should go through and you get paid. Simple.

---

You're doing it wrong, but it is actually a lot simpler than the two proposed solutions have described.

First, you'll never get a comprehensive list of card types. I've been creating credit card processing software for many years and the best processors can do is give you a general list per processor. The list they provide generally only classifies the cards as things like consumer level 1 cards or variations of level 2 or 3 cards (Fleet, P-Cards, etc). So unless you're dealing with sending line item details with settlements, you don't need to deal with this. (Believe me, you don't WANT to deal with it....it is pure chaos.)

What you need to do is have a process where you put an authorization hold on the funds at the time of delivery of information. This subtracts the amount that the card holder can spend on the card and reserves it for you to collect. While you have that hold, it is unlikely that you will have a problem collecting the money. This is not a pre-authorization; a pre-authorization only gives you a general idea that the card is valid but does not reserve the funds for you to collect later.

There are then two ways you can collect the money:

• Use a processor that performs a host capture. This means that at a certain time of day, all your outstanding authorizations will be settled automatically. This sounds ideal for you if you are delivering electronic information at time of authorization.
• Have your own daily process that submits transaction for settlement to the processor (aka terminal capture). Using this way, you can decide when to collect the money if perhaps there is some delay in the delivery of the items purchased. (For example, maybe you have to manufacture the purchased item.)

Either way, your customers can use whatever card type they want and they only get charged once their purchase is delivered. They can even cancel their card immediately after the purchase, but they won't be able to get around the reservation against their OTB (open to buy) that you've placed on their funds. So even if they've used a virtual card or a cash card, they will only be able to withdraw the funds minus the amount of your reservation.

And, contrary to popular belief, you can store the credit card number. It just means that you have a higher bar to hurdle for PCI compliance. In your case, a tokenization solution might lower this bar a bit. There are several processors that offer this, but that is a lengthy discussion for another thread.