This is an old revision of the document!
Table of Contents
Gateways, Merchant Accounts, Bank Accounts, Oh My!
The Myriad Pieces Needed for E-Commerce
Accepting credit card payments online is more difficult than it seems it should be, and matters are complicated by new and evolving systems that not only combine previously distinct aspects but also are redefining the payment process and creating entirely new options. We'll attempt to explain what is needed and why.
Please note that in this discussion we will not cover things like mobile payments, peer-to-peer payments, or “marketplace” systems. While they can be extremely beneficial in certain circumstances, they are worth exploring in depth if your e-commerce journey requires them.
All the Pieces: The "Traditional" Approach
In order to accept credit card payments online, a merchant typically needs all of the following:
- A website. Small websites can be static and hardcoded (like in Dreamweaver), or larger and/or dynamic and built on a CMS (Content Management System) like Wordpress, Squarespace, MODx, ExpressionEngine, Drupal, Joomla, Webflow, etc.
- An ecommerce platform. FoxyCart is an obvious example. Nearly all ecommerce systems have an integrated CMS. FoxyCart is different in that regard.
- The payment gateway. The ecommerce system's checkout page receives payment information (ie. the credit card number) from the customer, and sends that info to the payment gateway in order to authorize transactions. The gateway responds indicating success or failure (and the corresponding error code). Most gateways have a monthly fee as well as a small (~$0.05 USD) per transaction fee. Gateways typically send transactions to your merchant account to capture once a day as a “batch”. Common gateways are Authorize.net, Stripe, Braintree, and Chase Paymentech.
- The merchant account. The merchant account actually collects (“captures”) the money from the transactions that the gateway processes. This is where you get docked the 2-4% transaction fee for processing credit cards, as well as fees for the transaction and occasionally other fees. Once a day your merchant account deposits all its money into your bank account in a “batch”. Depending on your merchant account provider, your fees may be taken out when payment is batched (daily), or the fees may be taken out all at once, once a month. (Some gateways are provided by the merchant account provider, like SecureNet, Stripe, Braintree, PayPal Payments Pro, etc.)
- The bank account. This is where you finally see your money.
- Accounting, inventory, marketing, and etc. There are countless systems to help you manage your business. Most don't actually involve themselves in the actual transaction process, so they don't matter to this discussion.
For what it's worth, for merchants based in the US we have worked with a trusted partner to develop two merchant + gateway options. See our website for more details. For a full list of our supported gateways, see our gateways page, or contact us for if you have any questions.
Other Gateway + Merchant Account Systems
In some systems you can get two or three of the above functionalities combined. We'll focus on services that combine the payment elements first:
- PayPal Payments Pro rolls together the gateway and merchant account quite effectively, and could also be considered a “bank account” (though it is important to note that it is not necessarily regulated like a bank account). In addition, PayPal offers some basic cart and checkout functionality, which makes it somewhat of an “ecommerce platform”.
- Google Checkout and 2Checkout offer limited cart, gateway, and merchant account functionality as well. (Please note that neither GCo nor 2Co are currently supported by FoxyCart.)
Ecommerce Platform + Merchant Accounts or Gateways
Worth noting is that there are many ecommerce platforms that offer their own merchant account and gateway services. In the vast majority of cases these providers are simply white-labeling another company's services. There's nothing wrong with this, but you're unlikely to get any sort of competitive pricing with this situation.
Authorizing and Capturing Funds with Credit/Debit Cards
An important but often misunderstood piece of credit card processing is the relationship between “authorization” and “capture”. The easiest way to explain it is by using a gas station as an example. You drive up to the pump and insert your credit card, at which point the card is “authorized” for (let's say) $75. This authorization checks with your bank to make sure you have the funds, just like a normal transaction, but doesn't yet charge the card (“capture the funds”), since the final dollar amount is unknown. Once you have finished pumping and the final transaction amount is known (say, $45.03), the system issues a “capture” for $45.03. The first part is an “authorization only”, or “auth-only”, transaction. The second part is the capture.
(Another option would be for the gas station (or any merchant) to authorize a small amount like $1 just to make sure that it's a valid card, then upon completion clear that auth and issue an auth+capture for the full amount in one go. That approach can be sub-optimal, though, as a $1 charge might go through fine, but a $75 charge might fail for insufficient funds. This approach also requires storing payment information in one way or another, which can lead to its own challenges.)
The other, much more common way to process transactions is to do the authorization and capture at the same time, referred to as an “auth+capture” or “auth/capture”. Imagine buying groceries: You go to checkout, the total charge is determined, and your card is charged (both auth'd and captured at the same time).
Where things get confusing is on the proper usages of an auth-only transaction. It is often thought of as a way to accept pre-orders or to handle trial billing periods. While you could use an auth-only to handle these types of charges, it might not be a great idea for a few reasons.
- Authorizations effectively “hold” the amount authorized. So if you auth $300, that $300 is unavailable to the customer even if you haven't captured the funds. (If you don't capture and the auth expires, the funds will be released back to the customer, but in the meantime they may have overdrafted their account.)
- Authorizations don't last forever. 3 days is probably as far as you'd want to go under normal circumstances, and 30 days appears to be the upper limit, though the exact details will depend on a number of factors, including the card type (Visa, MasterCard, AmEx, etc.).
A better use of auth-only transactions would be to handle expected variations in product delivery or final charges. For example, if your shipping charges vary by factors that FoxyCart cannot account for, or products may not be available regularly, you may want to auth-only then adjust the final transaction amount before capturing the funds. Important to note, however, is that you can never capture more than you've initially authorized when using a traditional gateway. Some gateways allow you to capture only as much as has been authorized, while others 1) may allow you to capture up to a certain percentage of the authorized amount, but not more than a certain dollar amount higher.
In most situations we strongly recommend doing an auth+capture. If you do have specific requirements that necessitate auth-only processing we encourage you to test thoroughly and keep up to date on any changes your gateway may make that impact that functionality.
Supported Gateways
So what gateways are supported by FoxyCart? See the complete list.