Redundant Credit Card Processing Solution?
RokaMoka asks: "As I type this, I'm on hold with Verisign Payment Services, our (only) merchant services provider. I run several e-commerce sites, and how shall I say... 'tis the season. At the moment, VPS is totally down, and I am losing thousands of dollars per hour. Does anyone have any experience in designing and supporting e-commerce solutions with multiple vendors for CC processing? What other networks are out there, and what has been the customer experience with them? What should the strategy be, load-balance or fail-over?"
I don't think that kind of thing should be your problem. It's like web hosting. Who has redundant web hosts? I don't. My provider's job is to provide a level of service.
Do you have a service level agreement? If not, you might want to look into negotiating one.
Taral
WARN_(accel)("msg null; should hang here to be win compatible\n");
-- WINE source code
If you were losing thousands of dollars per hour, would you really be "asking Slashdot"?
Rather than failing to authorize the CC when VPS is down store all the needed information in a table, queue, etc. This allows the user's transaction to complete and it allows you to authorize CCs in a batch process once VPS is back up. Obviously this is not how you should run all the time, just when VPS is down.
BTW: I would not ship anything until I successfully authorized and charged the CC.
Well... I'd think it's simple. Which is cheaper for you to run, load balance of failover?
The World Wide Web is dying. Soon, we shall have only the Internet.
"Thousands of dollars per hour" and you can't afford a direct merchant account with the various CC companies?
They will guarantee a much higher level of service than going through some 3rd party.
If you need to, hire someone to hook your mechant account to your web sites. Simple as that, you got the money.
The ratio of people to cake is too big
This is when people realize that the lowest bidder is not always the best choice.
All my clients use them, and I have heard them described several times in articles as the standard in e-commerce payment processing in the US.
Authorize.net
You're going to get killed in fees if you don't process a decent level of transactions through a backup processor when it does come into play.
As I type this I have a client who's CC processing has been down nearly 24 hours, and has resorted to a dial backup solution. Not exactly the way to process 5000+ orders a day. And to top it off they sent out a special email offer to 500,000 subscribers this morning, so they're dying as we speak, and if it's not resolved in the morning we may be switching providers in a hurry. Thank the stars that they choose their own provider...
Ignore the posts talking about why you don't need this, and SLA's. No SLA is going to replace lost revenues, and anyone who doesn't have a backup plan in place is just waiting to get burned.
This may be the only option. At a very high level, this would require two things. First that you have a merchant account with the various CC companies. Depending on what kind of business you are in, this could be very easy, or very hard. More difficult would be the software itself. You "talk to" the CC company through one of a few Processor networks.. And those networks only allow certified systems to talk to them, and getting a system certified is, I suspect, close to impossible.
Fortunatly, there are more then a few libraries/servers. RedHat once had such a system, and based on their referral, I once played with MCVE, from Main Street Software. I left the job before anything came of the project; I diddnt go very far with it, but it was infinitly better then a Java system, whose name I dont remember, that I also played with (Dammit, its Java. I should be able to run it under Linux just fine, asshats.)
MCVE bindings are included in stock PHP, which I think is a reasonable vote of confidence.
While doing it yourself would not really remove the SPOF, it would bring it under your control. While the system you build may be technically less secure then one of the third-party-processors, it would also be a smaller target. Your own system wouldnt be effected by a vendetta DDOS against a TPP.
I think, in the grand scheme of things, that the politics of getting merchant accounts with the CC companies would be easier then the technical implementation.
It's true that there are some regions and/or users who are unable or unwilling to use paypal. However there are also some users who would prefer to use it when given the chance. So they cancel each other out in my opinion.
Paypal is easy to set up and they have an automatic notification system that you can hook into to fufill all your needs.
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
...and even beyond credit cards. There's e-gold, Norfeds, even faxing a check direct. CCs just cost you money, any way you look at it. It's *handy* to have a CC vendor,and as you can see it can also cause a problem, but it's also handy to store your loot and work with your loot in something besides federal reserve note digits being handled by the CC company loan sharks that isn't dropping daily in worth. In case you ain't seen it, the US funny money printing press buck is sinking pretty severely now because the rest of the planet has noticed they don't really have to filter their reality through it any longer, it's become redundant and expensive.
I know this is tangentially off the direct question, but just wanted to point out there are alternatives, and it doesn't hurt to offer them to your customers, and it's easy enough to do as well.
Firstly GGIAITCCI (golly Gee I AM in the credit card industry)
/hr is only 8.7mil a year. Your local MegaLoMart probably does more than that. They are probably paying around 100,000 for processing. Doing your own processing would require an investment over a million dollars and sponsorship from a bank.
To those posters who thing that "thousands of dollars per hour" is large enough to justify processing credit cards yourself, that is really not a large number. $1000
Having a second credit card processor would be a mild pain. it would probably require having two merchant accounts with two different banks (since a processor can only process merchants that are with banks they have arangments with). Not to mention that you would have support two different interfaces.
Your best bet would be to switch to a processor who takes downtime seriously.
Disclaimer: I work for Fifth Third Bank, in a credit card processing capacity (software testing and installation for authorization/settlement system).
First off, Verisign being totally down is completely unacceptable. Demand a refund for the service outage.
Second, why the hell are they totally down? The system that I work with (one of several owned by Fifth Third) is never completely down. We have three access methods; dial, SSL, and non-SSL TCP/IP. It's rare for one of them to have problems, virtually impossible for all of them to get hosed at once. We run on Tandems, which allow for "buddy" process running in seperate CPUs where the secondary takes over if the primary has a hardware problem; we have redundant access to our disk drives so that we can always get to the data. We also have a voice-menu system that you can use to authorize (not a good plan for e-commerce, but I figured if I was plugging the company I work for, why not?). Hell, we even have two identical systems in widely seperated locations! If you can't get through to us, you've probably got bigger things to worry about because there's been a major natural disaster.
Third, WTF did they change during the holiday season that blew up their system? We have a concept called "peak season freeze". Basically, we change *NO* software or hardware between mid-November and the end of September, except emergency fixes for things that are totally broken, and even that is rare.
Fourth, the guy who said you should running your own credit card processing solution is an idiot. He obviously does not know how the credit card processing world works and has never attempted a certification with one of the credit networks.
--Ender
PS I'll go write up an explanation of how the credit card processing world works in my journal now, so that you can go educate yourselves on the basics.
Loose things are easy to lose. You're getting your hair cut. They're going there to see their aunt.
We rely on monitoring the sites, and if there is a problem, switch from the processor to a simple CC capture. We would have to process the orders by hand, but we would only lose the sales that occur between the event of failure, and the switchover.
The key is knowing of a failure, and switching over.
As far as having two gateways/processors. This will be tough. You could have two of each, and just switch to the other one if the other goes down. Your store software should allow you to change this easily. Just disable one, activate the other. Problem with that is having a second gateway and processor which you don't use, then all of a sudden use, the will charge you out the ass.
Now you could get two gateways, and ONE processor. But if the processor goes down, you are completly screwed. But in my years of dealing with gateways and processors, it is 999/1000 the gateway's fault, not the processor.
Fear Is the Only God
I also like authorize.net they are very reliable and good tech support.