In short, a payment gateway is a bridge from the online world to the banking world. The two are not inherently connected.
For your website to communicate with your bank and, more commonly, with the bank of someone attempting to make a purchase on your website, it must pass through a few channels (secure channels). It must connect with merchant accounts and also with banks where people have their accounts (debit or credit). An authorization is made on the amount of the purchase. The payment gateway reports back if there are enough funds, if there are not enough funds (decline) or if there is an error - such as an incorrect expiration date. Once your website knows the status of the charge, it can issue an appropriate result, such as:
There are many out there - hundreds, if not thousands probably. Sometimes individual banks have their own, sort of "home spun" payment gateways that they use. With each transaction, there's an amount (fee) taken out by the payment gateway, so there's definitely some interest in creating and running a payment gateway. The one that's the standard, as far as website developers goes, is Authorize.net.
Authorize.net has the best interface. We call it an API, which stands for Application Programmer's Interface. It's basically how we talk to the gateway. Just about any programming language can use the API - such as PHP, Perl, Cold Fusion, ASP / DotNet and so on. So it's not tied to a programming language.
When a shopping cart software developer creates shopping cart software, they know that they will have to use a payment gateway. Since Authorize.net is so common and so widely used, it's the usual choice to integrate into shopping carts. The advantage is that it's a tried and true system - versus reinventing the wheel with someone else's system. It's so common, in fact, that other payment gateways use the Authorize.net API so that there are no hurdles to using it with shopping cart software.
The other common payment gateway is PayPal's PayFlow Pro. As you know, there's the "normal" way of connecting to PayPal where you get a PayPal login screen, have to login to your account, select your funding option and then are sent back to the website where you were conducting your purchase. PayFlow Pro is different. It acts more like Authorize.net where all of that is in the background and people enter their credit card information on the store website. Since PayFlow Pro is also popular, it's another good choice - just not as popular as Authorize.net.
There are several advantages.
First, like we mentioned, it's popular and easy to integrate. There's very little testing that needs to be done with Authorize.net compared to a website developer that is presented with a payment gateway and API that they have never seen before. Development time is minimal, which saves you money. They also provide some great options like saving card information for later, recurring billing and other great features.
Second, they provide top-notch fraud protection systems. If you are concerned about fraud prevention, then Authorize.net has the tools to help you. Some merchants might choose to just get warnings when fraud is suspected, while other merchants might want transactions be held in that case. Those settings are completely up to you.
Third, Authorize.net has high customer satisfaction and proven support. Ask other online store owners that you know and see which payment gateway they're using. You may even see merchants sporting Authorize.net seals on their websites, which help to provide trust to web shoppers.
Fourth, card information is secure. This data can easily be kept on their servers instead of on your server, which makes getting PCI compliance even easier.
Here's a note we got from Authorize.net on October 8, 2014 about some good changes in service:
Effective November 7, 2014, the following services and features will be included with all new Authorize.Net accounts:
Additionally, all Authorize.Net accounts will also include these recently released features:
Good question. This can be kind of an unknown. There are a lot of sort of "home made" payment gateways out there. Small companies see how much they can make offering these services and they brew their own system. Banks do this a lot. When that happens, you don't know what you're going to get as the developer that has to use this kind of system. For one, it might not be programmed in a normal way, so some custom scripting may be required. Also, you don't know what things they haven't thought of yet that you have to do.
For example, there was one we used (we'll not name names) and there were some pretty major problems that were discovered once the site was live. First, they didn't accept debit cards. Later, it just started working all of a sudden - we think they didn't carefully set things up on their end for this specific account or something. This points to a lack of experience.
Second, we found out that if there were any special characters in any fields - like an ampersand in a name field or something - then the transactions would not go through. The customer saw a very cryptic error message. This didn't help them, our client or even us. After a bit of investigation, we were able to find the issue. We had to write a script on our end to fix this. This is really something you would expect the payment gateway to deal with. Instead, they don't tell each of their clients that it's their responsibility to do that work. This client of ours lost some donations because of this issue and used our time to troubleshoot and then finally fix it. Using this payment gateway ended up costing them more.
The point here is not to bad mouth other payment gateways (that's not our bag, baby) but to point out that going with a trusted gateway provider is essential. Why trust online payments and your organization's reputation to anyone but the best? You get what you pay for - but actually you can get Authorize.net at a competitive price... which should make the decision even easier. It's a no-brainer, people.