Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Redundant Credit Card Processing Solution?

Cliff posted more than 9 years ago | from the backups-for-everything dept.

Businesses 86

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?"

Sorry! There are no comments related to the filter you selected.

SLA (3, Informative)

Taral (16888) | more than 9 years ago | (#11024667)

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.

Re:SLA (1)

DjReagan (143826) | more than 9 years ago | (#11024866)

I have worked for several companies that have redundant web hosts.

Re:SLA (1)

Taral (16888) | more than 9 years ago | (#11025501)

So they had contracts with two different companies for web hosting service?

Me? (1)

Saeed al-Sahaf (665390) | more than 9 years ago | (#11024992)

Many sites have redundant hosting via multiple server locations. I own 4 servers, two on the East Coast, two in Vancouver BC. In a way, it serves to load balance, but also, if on or two go down, there are always the others, and it's very unlikely that both Washington DC and Vancouver BC will go totally down at the same time. There are many people who do this.

Re:Me? (1)

Taral (16888) | more than 9 years ago | (#11025468)

That's not what I meant. I meant redundant web hosts as in having your site hosted at more than one compant.

Re:Me? (1)

Saeed al-Sahaf (665390) | more than 9 years ago | (#11025777)

Well, in a way, they are. Because they are at two physically different locations (facilities on opposite coasts), essentially, this is the case.

Re:Me? (1)

itwerx (165526) | more than 9 years ago | (#11027860)

I meant redundant web hosts as in having your site hosted at more than one compant.

Dunno about the parent but I have a couple clients that do that right now.
The commonality is they all have federal industry regulations mandating a maximum of 4 hours downtime (which is impossible for one company to truly deliver in the real world).
It's no big deal really. Just two bills every month instead of one and a few extra steps when doing site updates.

Re:Me? (1)

jsfetzik (40515) | more than 9 years ago | (#11042000)

I do it for my stuff, but then I am small time, about 6 small, low traffic sites. I rent server space from three different companies and have a duplicate copy of everthing on all three servers. It has happened twice in the past that I have had a server go offline for more then a day. In one case a week, I left that company. Nothing fancy though in that if there is a significant outage I manually change the DNS settings at the registrar. People that use my sites don't mind a day outage, but get upset with much more then that.

SLAs don't put fingers on the hand (1)

b00m3rang (682108) | more than 9 years ago | (#11025503)

when the service goes down.

Huh? (5, Funny)

Anonymous Coward | more than 9 years ago | (#11024719)

If you were losing thousands of dollars per hour, would you really be "asking Slashdot"?

What would Larry Flynt do? (1)

billn (5184) | more than 9 years ago | (#11024785)

He, like everyone else in that other huge credit card processor dependant industry, would have a backup processor.

Queue the Transactions (5, Insightful)

Logreybaby (451105) | more than 9 years ago | (#11024789)

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.

Re:Queue the Transactions (5, Funny)

Anonymous Coward | more than 9 years ago | (#11024834)

Ship? Don't you mean, "I would not let them look at any pictures until I successfully authorized and charged the CC."?

Re:Queue the Transactions (1)

itwerx (165526) | more than 9 years ago | (#11028008)

ROFL!! Mod parent Funny/Insightful!!!!

Re:Queue the Transactions (1)

bbuR_bbuB (804723) | more than 9 years ago | (#11035598)

And what happens when that data gets comprimised? I really would get pretty pissed off if I found out my vendor was storing my CC info on its boxes -- no need. Can't authorize, too bad. Try again later. I don't think VISA would be too happy about that practice...

Re:Queue the Transactions (1)

fwoggey (538973) | more than 9 years ago | (#11038550)

And what happens when that data gets comprimised? I really would get pretty pissed off if I found out my vendor was storing my CC info on its boxes -- no need. Can't authorize, too bad. Try again later. I don't think VISA would be too happy about that practice...

Encrypt the credit card info (use non-symmetrical encryption). Store the private key on a box not connected to the internet at large. Transfer the encrypted numbers to the secure machine. Decrypt. If you don't want to transfer them unencrypted back to the network to authorize them, then do it manually. If you're making thousands an hour, you can certainly pay someone $10 an hour to type some numbers in.

Re:Queue the Transactions (1)

bbuR_bbuB (804723) | more than 9 years ago | (#11054811)

You're assuming people who run most businesses have a clue about security. To them, Windows "is secure". No file permissions, ACL's, or anything. They just figure it's safe, cause it's on the computer. I've seen this in action. It's frighteningly common.

Re:Queue the Transactions (0)

Anonymous Coward | more than 9 years ago | (#11042476)

I really would get pretty pissed off if I found out my vendor was storing my CC info on its boxes -- no need.

This is exactly what happens with most retail systems. When the CC host doesn't reply, it tentatively approves the card based on some locally-set rules (like purchase under a certain amount, etc.) and logs the transaction. Later when the CC host is back online, a timeout-reversal is sent (this removes the charge on the off-chance that the request actually got to the host and got approved, but for some reason the reply didn't get back to you), then the original transaction is submitted again.

Re:Queue the Transactions (1)

Peter Cooper (660482) | more than 9 years ago | (#11055578)

As far as I recall, it's actually against the agreement you have with VISA to store the CVV number (used on most customer not present transactions now) of a credit card.

Re:Queue the Transactions (1)

sutterpants (775017) | more than 9 years ago | (#11037492)

Careful here... IANAL, but I believe it's illegal to charge a shopper's card until the item has actually shipped. Of course, this doesn't apply to *ahem* services which are delivered instantly, but if your customer ordered 100 widgets, until they're out the door, you can't charge them.

Having said that, you can certainly authorize the charge, which I would strongly recommend.

Re:Queue the Transactions (1)

dakryx (646923) | more than 9 years ago | (#11049751)

It's not illegal to charge before the item is shipped. Once charged it becomes a binding agreement. The reason companies do this is incase of some type of pricing error like with amazon when they were selling pda's for 30ish dollars, if they had charged soon as the order went through, amazon would've lost a nice chunk of change

Re:Queue the Transactions (0)

Anonymous Coward | more than 9 years ago | (#11042427)

Most retail systems will locally authorize credit/debit transactions when the host is down (transparent to the user of course), keep a backlog, and send them all for authorization when it discovers the host is back online.

Re:Queue the Transactions (0)

Anonymous Coward | more than 9 years ago | (#11048823)


Finally, someone who gets it.

I suggested this to our devs once, and they thought I was insane. "But, then you can't tell them if their card is bad, they'll have to call in"

Ayup, "SERVER NOT AVAILABLE" is a much better response.

Re:Queue the Transactions (1)

GenBradly (528592) | more than 9 years ago | (#11056426)

Bad idea. Not allowed by Visa/Mastercard anymore unless you are one of their certified gateways. My company looked into doing this, it was going to cost over 10k in fees alone.

Load balance or failover? (2, Insightful)

FooAtWFU (699187) | more than 9 years ago | (#11024806)

Well... I'd think it's simple. Which is cheaper for you to run, load balance of failover?

Eh? (4, Insightful)

Cthefuture (665326) | more than 9 years ago | (#11024918)

"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.

Re:Eh? (3, Interesting)

Ark42 (522144) | more than 9 years ago | (#11026367)

No kidding, I hardly make 'thousands of dollars per hour' but I can afford a merchant account and the interface linkpoint [] provides is great.

Its more about not wasting a huge % of each sale on the fees these middleman guys charge just to process a card. Places like charge near 20% of your sale last I checked. Get a merchant account and its a mere 2.9% + 35c per transaction or so.

Re:Eh? (1)

semafour (774396) | more than 9 years ago | (#11031128)

With VPS you actually do have your own merchant account. But even with that, you need an Internet payment gateway in order to process cards over the Internet; this is what VPS (and is. An Internet payment gateway allows you to use simple TCP/IP protocols (usually a web service) to submit card transactions; it then submits the transactions to the appropriate banks using some non-Internet protocols.

Think of an Internet payment gateway as a card swipe machine for your web site.

Re:Eh? (0)

Anonymous Coward | more than 9 years ago | (#11035605)

With VPS you actually do have your own merchant account.

no way. you're going through VPS for all the transactions. you're using their system the whole time. you have no merchant account with Visa, or MC, or anyone other than VPS. and when the VPS system goes down you're screwed.

Visa, MC, etc. offer merchant accounts. these accounts let you deal directly with the credit company. they also offer web services. plus if the web system goes down you can still process transactions by hand.

Re:Eh? (1)

fwc (168330) | more than 9 years ago | (#11050150)

no way. you're going through VPS for all the transactions. you're using their system the whole time. you have no merchant account with Visa, or MC, or anyone other than VPS. and when the VPS system goes down you're screwed.

I use Verisign payflow pro.

I definately *DO* have my own merchant accounts. One with Visa/MC, one with Discover, and one with Amex. All Verisign does is act as an online terminal for internet transactions. I.E. the internet equivalent of the hardware credit card machines normal brick-and-mortar stores use.

I can take my merchant account and process through any of the online payment processors. If I decide I want to pay extra for the priviledge of also having I can do so with my existing accounts.

Get your own system (3, Insightful)

hectorh (113198) | more than 9 years ago | (#11024996)

Any business that is running several e-commerce sites and processing thousands of dollars per hour should be using their own credit card clearing system.

This is when people realize that the lowest bidder is not always the best choice. (3, Informative)

hotgazpacho (573639) | more than 9 years ago | (#11025016)

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. [] (2, Informative)

Zaurus (674150) | more than 9 years ago | (#11025198) has downtime like any other (see my other post below). Specifically they were hit by a DDOS last summer that took them down for 3 days + some intermittent outages for about a week. We've just started having our traditional "holiday" outages with them today. They usually last less than a minute, but even so...they're not entirely reliable.

Having said that, 99.0% of the time they're up, and their support is ok.

Good Question (1)

Zaurus (674150) | more than 9 years ago | (#11025023)

Our Payment Gateway has also been flaky occasionally. Whether it's a targeted ddos in the summertime (actually happened), or a massive surge in traffic (ddos?) during the holidays, our Payment Gateway will occasionally refuse to process transactions for hours at a time. We sell online services, with a business model similar to the "buy a download key to unlock our shareware" model, so storing CC #'s for later is not an option. Once we give the service, it's given, so we need to process the cards in real-time. I approached "upper management" about getting a 2nd Payment Gateway account for redundancy last year, but in the end they were more willing to risk losing the sales during the downtime than spending the $$ and time to implement a redundant payment system.

Load Balacing (4, Insightful)

New Breeze (31019) | more than 9 years ago | (#11025051)

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.

Re:Load Balacing (1)

meshe (768681) | more than 9 years ago | (#11026439)

Ummmm, why would they send out a promotion to 500,000 subscribers when their merchant system is already down?

Re:Load Balacing (1)

New Breeze (31019) | more than 9 years ago | (#11027889)

They believed the provider when they said it would be back up by 10:30am this morning...

Do it yourself... (3, Informative)

T-Ranger (10520) | more than 9 years ago | (#11025109)

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.

Re:Do it yourself... (2, Informative)

Ark42 (522144) | more than 9 years ago | (#11026734)

Linkpoint [] integrates nicely with PHP and many other platforms. Its fairly easy to get set up with merchant account do the CC processing yourself. The fees are much lower that way as well.

Yes, but not with Red Hat! (0)

Anonymous Coward | more than 9 years ago | (#11035567)

> MCVE bindings are included in stock PHP,

Which is why we used it, and why I included a chapter about it in my book on PHP. The software works very well, and I've used it for over five years.

The problem is that Red Hat screwed over their customers pretty hard when they just stopped supporting CCVS and gave the name to Main Street. Just call them and try to get documentation or additional keys for CCVS. They won't do it. A friend that works there claims they deleted the source-code for CCVS, because the management wanted to make sure they never spent any more time or effort on it. Before that, some of the employees were supporting it on their own time because they felt bad about how Red Hat and Main Street screwed-over their customers.

I've spent about $30k on CCVS (now owned by Main Street), and they won't provide a changed key so I can change my merchant account for two of my customers that want to change. I will never buy another product from Red Hat, and I will never deal with their proxy Main Street. It sucks when I have money to spend, and they won't take it. It sucks worse when I don't know of another option for Linux that will do the same thing I need.

Paypal is my backup (3, Informative)

BortQ (468164) | more than 9 years ago | (#11025378)

I have my system set up with a main purchasing gateway, and also to use paypal as a backup/secondary option for users. I find this works quite well. On the off chance that the main gateway goes down I just have to switch a little HTML to make the paypal option the default and it continues to function.

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.

Have several options for payment... (4, Interesting)

zogger (617870) | more than 9 years ago | (#11025418)

...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.

Re:Have several options for payment... (0)

Anonymous Coward | more than 9 years ago | (#11040982) soon as you said "e-gold", I knew you were a crackpot...

Re:Have several options for payment... (1)

zogger (617870) | more than 9 years ago | (#11044002)

ooo, my feelings are hurt by an anonymous coward...oooo, he called me a bad name I am so chagrined, I promise to change my ways instantly based on your detailed analysis and recommendations

Re:Have several options for payment... (1)

duffbeer703 (177751) | more than 9 years ago | (#11045580)

Get real...

Currency valuation swings are part of doing business. I'm sure that you're bemoaning the collapse of the gold standard, yet have no clue whatsoever about the many, many bad effects commodity-backed currency.

The commissions that you will pay in the process of doing business with "real" money fill far exceed whatever you are losing in the dollar.

Re:Have several options for payment... (1)

zogger (617870) | more than 9 years ago | (#11049492)

I'd fart in your general direction, but don't want to waste the methane on a lout. You have to be at least moron class to get the benefits, and you fail it.

Pick Me! (check your email) (1)

viiviiviivii (459313) | more than 9 years ago | (#11025736)

The company I work for has a multiple country/currency/provider solution.

That allows for realtime swapping of payment providers (in the case of failure) in a way that is transparent to the merchant.

We have the ability to geolocate and cluster such that we are always reachable in the event of one server being down etc...

a few comments (2, Insightful)

gradbert (80505) | more than 9 years ago | (#11025765)

Firstly GGIAITCCI (golly Gee I AM in the credit card industry)

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 /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.

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.

Re:a few comments (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11026169)

So, instead of just writing "golly Gee I AM in the credit card industry", you wrote a pointless acronym which no-one is ever going to use or remember and cost yourself 15 or so keystrokes?

Re:a few comments (0)

Anonymous Coward | more than 9 years ago | (#11040617)

This man speaketh the truth.

Re:a few comments (1)

budgenator (254554) | more than 9 years ago | (#11041499)

I think the word Bank is critical here, and I mean a real bank, where you can develope a relationship with a human person, face to face on both a personal and business level. A real Banker is going to be more interested in keeping an on-going mutuly beneficial relationship; not meeting a commision quota this month while he looks for an other job.

Change processors (4, Insightful)

Ender_Stonebender (60900) | more than 9 years ago | (#11026175)

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.

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.

Re:Change processors (1)

Fubar420 (701126) | more than 9 years ago | (#11026722)

Back up... Non-SSL TCP/IP?

For Credit card processing?

You're joking right?

Re:Change processors (1)

Ender_Stonebender (60900) | more than 9 years ago | (#11031107)

No. But it's not public internet, either, it's private connections. We also support VPN connectivity, in case you want another variation on SSL.


Re:Change processors (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11043286)

If you're really interested in the mechanics of CC processing, I used to work for one of the largest CC transaction providers in the UK (retail logic).

During 2000, the acquirers dropped PCConnect (I think it was) in favour of FTP as PCC wasn't y2k compliant. So, now, all your batched card payments are transferred to the CC via FTP.

Sure its all private LAN type stuff, or VPN of course, to write-only directories. (and Amex doesn't even tell you whether your transfer has succeeded - you have to wait til the next day to find that no payments have been made before you retry).

And to really top it off, the premium product (Solve) was originally written by the CTO on his Atari ST. Credit Card payment processing really is cutting edge!

Re:Change processors (1)

tzanger (1575) | more than 9 years ago | (#11027823)

Basically, we change *NO* software or hardware between mid-November and the end of September

So your systems are locked-down-no-changes for ten months of the year? That's a hell of a long "peak season".

Re:Change processors (1)

dubl-u (51156) | more than 9 years ago | (#11029925)

Basically, we change *NO* software or hardware between mid-November and the end of September
So your systems are locked-down-no-changes for ten months of the year? That's a hell of a long "peak season".

No, he just wrote the post last month, and so wasn't allowed to apply the patch to change "September" to "December".

Re:Change processors (2, Interesting)

adolf (21054) | more than 9 years ago | (#11029281)

Peak season freeze?

Sometime in about the past week, the entirety of the Fifth Third Bank [] website changed. Looks like they decided to roll out all a whole new look-and-feel, while mucking up the login procedures again.

So as long as you're boosting your employer, I'll knock 'em down a bit:

Why the fuck would you change something broad like the entire user interface during the busiest time of the year? And what's the gig with the tiny fonts?

But that's not all, no sir: Dispite all of its newness, the new website still fails to let me transfer funds between my accounts. And I can only presume that still nobody has any clue why. Everyone I talk to at that god-forsaken bank suggests that it should work fine, that the accounts are "connected," and so on.

But in the dropdown list, there's only ever one account present. Tried Opera, Mozilla, and Firefox under several different Linux distributions, several versions of IE under several versions of Windows, each at several different venues with several different ISPs.

In each case, the HTML with which to render multiple accounts in a dropdown is absolutely absent. Your shit is broken, and has been for years.

And also: Your people stink. They botched my first checking account before I even had a chance to use it, and they lost the flood insurance renewal that I hand-delivered to them instead of paying it like they were supposed to. And then they sent me a nastygram a few weeks later, proclaiming that they were going to sell me some different insurance of their choosing if I failed to jump through several itemized hoops.

The people are so bad, in fact, that the only reason I continue to do my banking business with them is that they were the only place stupid enough to give someone like me (negative credit, negative income, no trade lines, so on, so forth) enough money that I could buy a house.

A reliable datacenter does not a good company make.


Re:Change processors (1)

Ender_Stonebender (60900) | more than 9 years ago | (#11031201)

The Fifth Third Bank website is *NOT* part of the credit card processing system; and I was not involved in the redesign. And yes, I knew that it had changed, but since I don't have any accounts with the bank, I didn't bother looking into how well it worked. (I work in an office that was a CC processing company which 5/3 acquired; I have no access to Fifth Third accounts. It would be an hour drive for me to get to the nearest branch.) Take your complaints to someone else - like maybe to one of the customer service people at a branch? Ask them to demonstrate how to transfer funds. Laugh at them when it doesn't work. They will then bust their butts to get it fixed for you. (This worked for me with the bank I do have accounts at, AmSouth Bank.)

One other thing: I never said that Fifth Third Bank was good to use for personal banking, nor meant to imply it. I have no experience with that, and can only hope that your experiences are not typically (although, sadly, I think they may be). I only meant to say that (1) Verisign's behavior as described in the article is unacceptable, (2) Fifth Third would be a better choice for a merchant to use a credit card processor, and (3) impart some information about how Fifth Third's credit card processing works so that people would not be dealing with them blind.


What he said... (0)

Anonymous Coward | more than 9 years ago | (#11042286)

yeah, and their name sucks, too!! "Fifth Third"? Yep, I want a bank that not only isn't "First", they can't figure out if they're third or fifth!!

Simple CC Vaidation (2, Insightful)

Unholy_Kingfish (614606) | more than 9 years ago | (#11026824)

This time of year isn't our busy time, but we have it other times of year.

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.

Re:Simple CC Vaidation (1)

danielrose (460523) | more than 9 years ago | (#11028783)

Why not load share between two processors, send one order to the first, the next order to the second.. If you get enough orders you should still get decent rates on fees at both..

Load balance two gateways (0)

Anonymous Coward | more than 9 years ago | (#11029032)

I work for a company that does E-commerce, and I handle the CC processing. We've tried different software packages that use SSL direct to the processor -- even one written by the processor -- and they're all junk. Or if there is a good program, I haven't found it.

The best solution I've found is to load balance between Verisign and Both send to the same processor, as we want to use only one merchant account. At times, I have seen any one of the three go down, sometimes for hours.

An improvement to this is to get a second merchant account on a different processor, but management doesn't want to do that. It will take a day-long outage at our processor to get that ball rolling, and it WILL happen, but I'm only allowed to fight fires, not smoke.

I feel your pain. Good luck.

VPS is sorely outdated (0)

Anonymous Coward | more than 9 years ago | (#11029378)

Having actually worked on the VPS system at VeriSign, I have a bit of insight into many of the problems that are there. Not that this will help you solve your current problem, but maybe this will serve as a warning to others.

VPS came about when VeriSign bought a company called Signio a while back. Originally it was Windows NT servers with Cold Fusion code and MS SQL backend. Still have the same ancient Cold Fusion, but now on Windows 2000 and Oracle on Sun. So a lot of bits have been rigged and kludged together to scale the system and to keep it running. But worse than the antiquated processing system is the political infighting at VeriSign which keeps it from ever getting updated. There has been a plan to rewrite the entire VPS platform into something more modern (say Weblogic app servers) for more than three years. But nothing has yet come of that.

So if you are using VPS, you are using a five year+ old, duct taped together, barely held together system. It's a miracle it stays up during the holidays, ever, except for the work of some very dilligent and dedicated operations folks.

Seriously in violation of another NDA-

Work it into the e-commerce platform... (1)

Phil John (576633) | more than 9 years ago | (#11030014)

...our proprietary system is used on around 400 sites, ranging from small mom and pop stores to larger online etailers (not in the league of amazon by a long-shot, but turnover of several mil a year easily). We realized early on that:
  • Lots of different vendors wanted lots of different payment service providers (some were refused at certain providers but agreed to at others, some had to go with a certain one for their merchant account etc.)
  • Lots of these different payment service providers offer similar types of interface options
  • Sometimes payment providers go down, sometimes they go bust (myPaySystems), sometimes they get ddos'd
The upshot of this is that we designed our system to be able to:
  • use pretty much any payment provider out there (we haven't been presented with one that we couldn't integrate with)
  • use multiple payment providers if needed (i.e. nochex vs paypal for the smaller sites)
  • change primary payment provider in less than 10 seconds (a single entry in the site config is changed and bam, new payment processor live).
This isn't the kind of thing that's particularly fun to backport into an existing project, or stress free (the quality of most providers documentation is, with rare exceptions like worldpay and protx, shit) but it can really pay dividends in situations like yours.

Ogone (1)

wimbor (302967) | more than 9 years ago | (#11030073)

If you do not mind shopping abroad, try Ogone ( It has different gateways: a Web terminal, batch upload, direct link to your website, ...

Re:Ogone -- what's in a name (1)

rjamestaylor (117847) | more than 9 years ago | (#11034740)

Boss:"Sam, where's our money??"
Sam:"It's o'gone!"
"Leave your money with us."

No thanks.

Re:Ogone (0)

Anonymous Coward | more than 9 years ago | (#11042986)

If he doesn't mind shopping a broad? I thought he was selling a broad...

Why don't you send me the card numbers by e-mail ? (1)

dario_moreno (263767) | more than 9 years ago | (#11030268)

If you send me the complete credit card details by simple e-mails, I will quickly tell you if they work or not !


viiviiviivii (459313) | more than 9 years ago | (#11030433)

I don't understand why everyone beats on about reliability etc... The truth is, that they ALWAYS go down for some reason.

As mentioned earlier, the company I work for sells the use of a payment gateway.

Where I work we have redundancy via the fact that we can process via any provider depending on the merchants requirements (we can rollover to a different provider in the case of failure). Basically the merchant can integrate for one API and the rest is magic.

If a merchant wanted fallover in case our servers fell, then, we can simply duplicate our setup and have it hosted in multiple locations.

I am not really a sales manager, and, don't really have to worry about getting new customers. So, I only offer this info as I am sure that there has to be a US company that offers similar services. is another company that offers a similar solution, although, I think they are restricted by merchant Id whereas we are not.

If you're losing thousands of dollars per hour... (1)

nganju (821034) | more than 9 years ago | (#11032238)

... get a direct merchant account with a credit card processor. I used and it worked just fine. Of course you need a merchant bank account, a Duns & Bradstreet number etc. Spend the few grand it will take to get a programmer to write your own code to interface with the processor's API. I wrote the layer to talk to's API in less than a week.

Have the user enter his CC info on YOUR site, don't redirect him to the merchant site. This has the added bonus that you can save the CC numbers, so you can give the user one-click shopping next time (but better check Amazon's "patent" first). Then use your own interface to talk to the processor's API and authorize the credit card. If the processor happens to be down, store the transaction in a temporary DB table and tell the user the order has been accepted. Then later when the processor comes back up, authorize the CC. If it doesn't authorize correctly send the user an email saying there was a problem with the CC.

A site that makes 'thousands of dollars per hour' definitely justifies the nominal cost to build a robust, in-house solution. The solution above oughta get you through the holiday season.

Re:If you're losing thousands of dollars per hour. (1)

mp3phish (747341) | more than 9 years ago | (#11048875)

How to prevent leaked credit cards?

Seriously, I am trying to do self processing at a small shop. Just trying to get the store online with CC payments, and in store charge accounts... But everyone I have talked to says that unless your using a payment gateway to process the credit cards, it is a lawsuit waiting to happen. They say PGP emails are not good enough, and storing them on the server might be illegal or considered negligance.

What shopping cart software do you propose to use for this type of CC storage which would allow me to retrieve it and bill it using a hand processor? (being that it is a low volume web store which compliments a brick and mortar store...)

thanks if you can help!

One Solution (1)

TPoise (799382) | more than 9 years ago | (#11035960)

One Easy Solution:


TrustCommerce experience? (1)

brlewis (214632) | more than 9 years ago | (#11044865)

I notice that TrustCommerce has debian packages for their APIs. My impression from reading their web site is that they're clueful. So far I've only used paypal, but would be interested in peoples' experience with TrustCommerce. I'm thinking of adding them as a secondary payment option some time next year.

Re:TrustCommerce experience? (1)

PizzaFace (593587) | more than 9 years ago | (#11050130)

TrustCommerce [] is very developer-friendly. They don't provide a ready-made payment form for your website, but if you or your shopping cart can collect the data, they have a solid, simple gateway API for processing it. And with regard to the topic of the article, TrustCommerce claims that its redundant systems offer 100% availability through failover [] .

I've been using TrustCommerce for a small site for several months, and I'm now implementing a large site with them. I've had no problem with their payment gateway or with their "vault" interface for manually entering transactions and viewing reports.

Their documentation is thorough and they support multiple code interfaces to their API: PHP, Python, Java, EJB, Perl, Ruby, ColdFusion, C, and COM/.NET/OCX/ActiveX.

TrustCommerce has given me good customer service and very good developer support. In my first project, I was using a hosted server and one of TC's developers helped me talk to my hosting company about installing the TCLink module that communicates directly with the gateway. My host had a policy against installing custom modules on the webserver, so TrustCommerce had an alternative solution, sending transactions securely through HTTPS/POST and using Curl to read the results back, and that method has worked fine.

For my new project, I've built my own webserver so I can use the TCLink module without begging a hosting company for customization. My server uses Suse Linux Enterprise Server 9, and I found out the hard way that TrustCommerce built its Linux RPM module for TCLink-PHP on Red Hat. (On SLES, I should have installed and compiled the "UNIX" package instead of the "Linux/RPM" package. You probably won't have the same problem if you use Debian because debian-unstable includes TCLink modules for PHP, Perl, Python and Lisp.) I'm a Linux newbie, but TrustCommerce's developer support patiently talked me through creating the symlinks I needed to make the rpm module work on SLES.

Slightly OT - Small business CC Processing (1)

Pugio (816116) | more than 9 years ago | (#11036375)

In some posts people have referred to CC processing "by hand". How does one go about doing this? I have a friend who has a small business in which he processes credit cards over a dial-up connection. The problem is, the software needed only runs on an outdated OS. I've tried looking for alternate solutions for him but I haven't found any site that allows by-hand processing at his current price level (very low).

Re:Slightly OT - Small business CC Processing (1)

IMarvinTPA (104941) | more than 9 years ago | (#11036690)

The old imprint machines still exist and are valid. Finding one may be a pain, and you won't instantly know if they are overdrawn.
I'm no expert though. I just know I've seen the machines in recent memory.

Re:Slightly OT - Small business CC Processing (1)

wimbor (302967) | more than 9 years ago | (#11037828)

Don't know about price level, but Ogone ( has a web-interface for handling sales. It can even work with card reader...

Re:Slightly OT - Small business CC Processing (1)

login: (155941) | more than 9 years ago | (#11038707)

You could check out PCCharge. It is designed for people like your friend. The service isn`t perfect, but as long as your friend stays away from food stamp sales (he doesn`t run a grocery store does he?) it should be ok.

Seems your solution is obvious, isn't it? (1)

wmshub (25291) | more than 9 years ago | (#11038680)

I run a web site much smaller than yours. On a good month, I do thousands of dollars in traffic per month, rather than per hour. But, speaking as somebody who has written credit card processing code (I go through's AIM system), I can say that it's not very hard. I wrote my own shopping card/connection software because the protocols to were simpler than the APIs of any of the shopping cart systems I could find. It took about two weeks to write and test it. That's it.

So, one person (me) can write code to connect to a gateway in two weeks. I pay about $15 per month to the gateway. If I did enough business to need redundancy, I would do another two weeks work to write code for the 2nd gateway, another $15 or so per month, then have a switch so that system admins could choose gateway 1, 2, or both...done. 1 engineer month and a few dollars monthly to pay for the 2nd gateway, and there is your redundant credit card processing system.

I think your choice is clear: Pay a programmer to spend a month writing the code you need to handle both gateways from your web site. Pay for both gateways. Problem solved.

CC Processing (1)

MadHungarian1917 (661496) | more than 9 years ago | (#11041289)

In a former life I was director of engineering for a company which sold/supported retail Point of Sales systems CC processing was a important part of these systems.

First we always used a payment gateway system these used dialup or 56k leased lines to the processor. I know that using the internet for transport is attractive because of low costs however since you have accepted the use of an "unreliable transport" for your CC authorization traffic to your merchant account you have essentially no recourse when the system goes down.

If on the other hand you use a processor provided link THEY are on the hook when the system goes belly up.

We used First Data

They had another name back then but that is unimportant. We used their payment gateway and interfacing to it was simple.

And if the system went down the transactions were still captured logged and if necessary the customer could voice authorize the transactions.

Paypal works well (2, Informative)

neckdeepinspecialsau (756133) | more than 9 years ago | (#11043756)

I agree with all of the folk who are backing paypal as a backup. When I set up someone with a payment solution I more often than not push for a pay with pay pal option. With this option you have the backup you are looking for and you also open the door to the customers that like to pay with paypal and since they don't charge a recurring fee you have a no real cost backup.

I also like they are very reliable and good tech support.

I used to use verisign (1)

Omega1045 (584264) | more than 9 years ago | (#11048146)

Back in my eCommerce days I used VeriSign (we called them VeriScum) and ran into this problem every Christmas. What my team ended up doing was this. A cc web page would try to approve the credit card in real time. If it could not, it would just store the card number in a table for later processing and put the purchased item on a temp hold status. We had some late night processes that would run at a few times during the night (12am, 2am, 4am) and try to process these numbers. Each process would try and fail on the 3rd try, then would get hit again the next time the process ran (12, then 2, etc).

I started off only running the process at 2am, but not all the cards would go through. When I added the 12pm and 4am spots, then everything always went through. The key is to avoid the times when people are at the malls competing for VeriSign's bandwidth via checkout card readers.

Re:I used to use verisign (1)

mp3phish (747341) | more than 9 years ago | (#11048931)

What kind of security is required to hold credit card numbers on the database like this?

Re:I used to use verisign (1)

Omega1045 (584264) | more than 9 years ago | (#11052178)

It has been a while so I am trying to remember what package we used to encrypt back then. In any case, we had an encyption package, so that we stored cc numbers, and some other vitals about the customer in an encrypted fashion. It seems to me like we stored their lastname and email address encrypted as well. Like I said, I cannot remember the package but we compiled our keys into a dll, which is about as secure as I think one will get (ie the encryption keys were not sitting around in plain text in a file, table or script).

Load Balancing CC Processors (1)

Marshal3KSP3 (754353) | more than 9 years ago | (#11048907)

Interestingly enough, I wrote a software package from scratch that load balances our company's credit card processing across various networks, including Verisign and AuthorizeNet, as well as among some smaller parties.

It's a great method for not only avoiding blackouts when a gateway goes down, but also for load-balancing chargeback rates if you sign up with multiple banks as well.

Interestingly enough, sometimes a climbing chargeback rate means we send *more* traffic their way... thus increasing the denominator, so to speak.

AuthorizeNet got hit by a DDoS shortly after we deployed this system, so it was a lifesaver. AuthorizeNet hasn't been the same ever since, unfortunately...

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?