views:

281

answers:

3

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?

+4  A: 

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

TFD
What is a hold transaction?
Steffan
@Steffan http://en.wikipedia.org/wiki/Authorization_hold
The Matt
Aka AUTH transaction
Byron Whitlock
+2  A: 

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.

PaulG
The pre-auth time frame should be specified in your merchant contract. It will be specific number of days for each card vendor (visa, matercard, amex etc)
TFD
Sorry, but thats not true. Each card **issuer** varies the number of days they hold cards, so (using UK example) Barclays Visa card may be 7 days. HSBC Visa card may be 10 days. Even so, pre-auth doesnt solve the issue of cards becoming invalid
PaulG
PaulG is correct about the pre-auths. They vary by card issuer, not merchant account provider.
John Conde
A: 

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.

Nathan
I think Steffan was describing that he provides a service up-front, by only wants to take settlement weeks or up to a month later. He wants to ensure that the funds will be available at that later point. The authorization hold you describe will drop-off after x days.
PaulG
Yes but I was pointing out if he is delivering the goods before getting paid then he's doing it wrong. Delivering the goods before securing payment generally requires another set of workflows. This is generally known as purchase on account and requires establishing a formal relationship between purchaser and seller. This includes a credit check, risk scoring and so forth. Many business don't do this anymore because they can use credit cards instead to outsource all this relationship management. This means authorization up front to secure payment BEFORE delivery of goods.
Nathan
The amount could be several hundred dollars, and potentially worse case scenario (if it takes a while to complete the service) could take up to 6 months. I'm thinking that there isn't much we can do, but do a better job pre-screening customers the best we can.
Steffan
You're having the classic problem of authorization horizon. This is technically incompatible with the way credit cards work. Many people have typically worked around this with a re-authorization background process. Up to this point, it has been messy at best. With PCI limitations, it gets really messy because you have to store the credit card number. The new capabilities of full reversals can help improve the re-authorization part, but you still have to have some background process that does the refreshing of the authorization.
Nathan

related questions