Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Businesses The Almighty Buck

Redundant Credit Card Processing Solution? 86

Posted by Cliff from the backups-for-everything dept.
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?"
This discussion has been archived. No new comments can be posted.

Redundant Credit Card Processing Solution? More

Redundant Credit Card Processing Solution?

Comments Filter:

  • SLA (Score:4, Informative)

    by Taral ( 16888 ) * on Tuesday December 07, 2004 @06:16PM (#11024667) Homepage
    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.
    • I have worked for several companies that have redundant web hosts.
    • 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? (Score:2)

        by Taral ( 16888 ) *
        That's not what I meant. I meant redundant web hosts as in having your site hosted at more than one compant.
        • Well, in a way, they are. Because they are at two physically different locations (facilities on opposite coasts), essentially, this is the case.
        • 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.
        • 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 mu
    • when the service goes down.

  • Huh? (Score:5, Funny)

    by Anonymous Coward on Tuesday December 07, 2004 @06:19PM (#11024719)
    If you were losing thousands of dollars per hour, would you really be "asking Slashdot"?
  • He, like everyone else in that other huge credit card processor dependant industry, would have a backup processor.

  • Queue the Transactions (Score:5, Insightful)

    by Logreybaby ( 451105 ) on Tuesday December 07, 2004 @06:23PM (#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 (Score:5, Funny)

      by Anonymous Coward on Tuesday December 07, 2004 @06:27PM (#11024834)
      Ship? Don't you mean, "I would not let them look at any pictures until I successfully authorized and charged the CC."?
    • 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...

      • 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 unencrypte

        • 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.
      • 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.
    • 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.
      • 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
    • 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? (Score:3, Insightful)

    by FooAtWFU ( 699187 ) on Tuesday December 07, 2004 @06:25PM (#11024806) Homepage
    Well... I'd think it's simple. Which is cheaper for you to run, load balance of failover?

  • Eh? (Score:5, Insightful)

    by Cthefuture ( 665326 ) on Tuesday December 07, 2004 @06:31PM (#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? (Score:4, Interesting)

      by Ark42 ( 522144 ) <slashdotNO@SPAMmorpheussoftware.net> on Tuesday December 07, 2004 @08:16PM (#11026367) Homepage

      No kidding, I hardly make 'thousands of dollars per hour' but I can afford a merchant account and the interface linkpoint [linkpoint.com] 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 regnow.com charge near 20% of your sale last I checked. Get a merchant account and its a mere 2.9% + 35c per transaction or so.
    • 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 authorize.net) 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.

  • Get your own system (Score:4, Insightful)

    by hectorh ( 113198 ) on Tuesday December 07, 2004 @06:36PM (#11024996) Homepage
    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.

  • Authorize.net (Score:3, Informative)

    by hotgazpacho ( 573639 ) on Tuesday December 07, 2004 @06:38PM (#11025016) Homepage Journal
    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 [authorize.net]

    • Re:Authorize.net (Score:2, Informative)

      by Zaurus ( 674150 )
      Authorize.net 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.
  • 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-

  • Load Balacing (Score:4, Insightful)

    by New Breeze ( 31019 ) on Tuesday December 07, 2004 @06:39PM (#11025051) Homepage
    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.

  • Do it yourself... (Score:4, Informative)

    by T-Ranger ( 10520 ) <jeffw@cheMENCKENbucto.ns.ca minus author> on Tuesday December 07, 2004 @06:43PM (#11025109) Homepage

    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 [mainstreetsoftworks.com]. 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... (Score:3, Informative)

      by Ark42 ( 522144 )

      Linkpoint [linkpoint.com] 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.

  • Paypal is my backup (Score:4, Informative)

    by BortQ ( 468164 ) on Tuesday December 07, 2004 @06:59PM (#11025378) Homepage Journal
    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... (Score:4, Interesting)

    by zogger ( 617870 ) on Tuesday December 07, 2004 @07:01PM (#11025418) Homepage Journal
    ...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.
    • 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.
  • 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 (Score:2, Insightful)

    by gradbert ( 80505 )
    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
    • 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 (Score:5, Insightful)

    by Ender_Stonebender ( 60900 ) on Tuesday December 07, 2004 @08:01PM (#11026175) Homepage Journal
    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.
    • Back up... Non-SSL TCP/IP?

      For Credit card processing?

      You're joking right?
      • 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.

        --Ender

      • Re:Change processors (Score:1, Interesting)

        by Anonymous Coward
        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

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

      • 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 (Score:3, Interesting)

      by adolf ( 21054 )
      Peak season freeze?

      Sometime in about the past week, the entirety of the Fifth Third Bank [53.com] 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
      • 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 custom
  • 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 ot

    • 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..
  • ...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 ty
  • If you do not mind shopping abroad, try Ogone (www.ogone.com). It has different gateways: a Web terminal, batch upload, direct link to your website, ...
  • If you send me the complete credit card details by simple e-mails, I will quickly tell you if they work or not !
  • 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 serve
  • ... get a direct merchant account with a credit card processor. I used Authorize.net 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 Authorize.net'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
    • 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 sto
  • One Easy Solution:

    http://www.TrustCommerce.Com

    • 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.
      • TrustCommerce [trustcommerce.com] 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 [trustcommerce.com].

        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 gatew
  • 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).
  • 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 authorize.net's AIM system), I can say that it's not very hard. I wrote my own shopping card/connection software because the protocols to authorize.net 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 perso
  • 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 wh
  • 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 authorize.net they are very reliable and good tech support.

  • 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
    • What kind of security is required to hold credit card numbers on the database like this?
      • 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 fil
  • 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 d

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close