If you are the CEO of a startup that plans to accept online payments the landscape can seem daunting. There are a lot of individual articles on PCI Compliance, Payment Gateway/Merchant Accounts and new emerging payment types of different size and length. This post attempts to tie the key concepts together into a brief overall primer to get you going. Given we're providing services in this space I'll also pitch Spreedly at the end. 

Potential Pitfall 1: PCI Compliance 

Your goal is to reduce your PCI compliance scope to the bare minimum. Too often I see comments saying "We use XYZ payment provider so we have no PCI responsibilities" That's not quite true. Even if you do everything right you still need to complete a SAQ-A --essentially a one page self assessment questionnaire. Therefore your true goal is to aim for a SAQ-A vs falling into deeper scope and having to complete a much more complex SAQ-D. If someone is telling you that their solution means you have no PCI compliance requirements it's a red flag that at best they are naive.

What does that mean in practical terms as it relates to your company? That you'll either use a hosted payments page or a transparent redirect. The goal for both is the same. When it comes time for your prospect or customer to enter sensitive credit card data it won't touch your servers at all. That will keep you outside of the more rigorous PCI compliance scope. 

Payment pages come in two forms. The most "extreme" is the PayPal, Amazon, 2CheckOut type of approach. Here your customer leaves your site completely and lands on an alien page to complete their transaction. This definitely solves PCI compliance scope issues. It can also infuriate developers/business analysts because that's a complete blackhole in your process flow. On top of that, some of these services try and motivate your customer to do something other than just complete the transaction - which can drive payment abandonment higher. There may be some benefits - especially if you're a very small startup selling to consumers. The thought that a "trusted" brand like PayPal is where the financial transaction is "occurring" may help you close sales from wary customers. In general though try and avoid these "offsite" branded payments pages unless you have no other choice. (after seeing this post 2CheckOut tweeted to let us know that they're actively making changes to their checkout process to reduce the issues highlighted here)

Then there are "gentler" payments pages.  At Spreedly our subscription service uses a much gentler payments page. It's designed to be simple, clean and elegant. We suspect in many cases people don't realize they've left our customers' site for another service. Many other services also offer their own payments page as part of their value proposition around PCI compliance scope reduction. The major drawback? Again, you don't control the design of that page. There are other benefits beyond PCI Compliance scope. Higher conversions via an experienced service optimizing flow based on gobs of data.

Transparent redirects are in part a response to the constraints of hosted payments pages. They allow complete freedom in the design of your payments page while still keeping you outside significant PCI Compliance scope. Transparent redirects are a newer process so if this is critical to you then that'll limit the number of payment gateways you can work with - which may be a good or bad thing.

Selecting a Payment Gateway


A Internet merchant account is the special bank account that allows you to capture and store money from other banks (via your purchasing customers' accounts) In a retail store that data usually travels over a closed POS network in an all in one event. Transacting online required the creation of payment gateways to replicate the point of sale (POS) network. If you want to start accepting payments online you'll need both: a merchant account and a payment gateway to connect to that merchant account. 

You can purchase the two separately, and many businesses do, but the industry trend is toward buying the two together in a "bundle". PayPal largely led the way followed by Braintree (who admittedly focused much more on the payment gateway end) and then Stripe. Europeans are embracing PayMill while Australians have Pin.net.au.Therefore "You need a payment gateway" typically means you need a payment gateway and a merchant account. For that reason many people find it easier to purchase them together.

If you go to your existing banking partner they'll charge you to set up an internet merchant account. They'll then usually bundle in a payment gateway with the package (most commonly Authorize.net in the US while Ogone seems very popular in Europe) You can call Authorize.net directly and they'll bundle in a merchant account. Pro tip: If you're going to take this approach I suggest working with the payment gateway as the primary. If a payment gateway sells you a merchant account they'll let you switch the merchant account. If the merchant account sells you the payment gateway the payment gateway won't let you switch merchant accounts - it's a channel thing. Given you integrate to the payment gateway APIs those changes are more challenging in the long run. 

The payment gateway/merchant account landscape seems to be splitting into two worlds. For 2.9% and 30 cents you can get set up immediately to begin accepting payments (see the list of combined payment gateways I mentioned above). You can work with an elegant, modern API. You'll most likely get credit card portability included (more below). Support - both direct and online - will usually be good and prompt. Your developer/s won't follow you out to your car late at night with a menacing look.

The other choice is to fill out paperwork, wait as little as one day or as long as a week for an approval. If you're small or just starting out you might get rejected or asked for more details. Then you'll find an API/documentation that your developers will be less than thrilled about. Depending on the provider, getting your credit card data back if you wish to leave might be impossible too. The reward for all this? Processing fees closer to 2% and 20 cents a transaction at scale. That's approximately $100,000 + per year on a $10 million top-line store. (Check out Feefighters.com if you want to get into specific scenarios based on average ticket size etc)

One final note. Understand your business. Banks and merchant accounts are trying to assess the risk you bring. Risk is based on refunds, chargebacks and the chance you'll go out of business. 

Are you going to have a high ticket (price) item? Are you going to do very little volume then suddenly burst into activity via a flash sale or event? Do you think your business lends itself to requests for refunds? If you're going to look "erratic" then I strongly recommend talking to the merchant account first vs just using an immediate sign up service. It can reduce the likelihood of the dreaded "freeze" or hold. 

Storing Credit Cards


Logically, you really have to store cards for subscription services. You don't have to store cards in a one time commerce scenario but most studies show substantially higher cart conversion rates if you can pre-populate prior card information. Short answer - storing cards is usually either required or a good-practice when it comes to sales and follow on sales.

Storing credit cards is a subset of PCI compliance. Let's start by saying it would be great if you could store your own cards. That means you could change or add a new payment gateway at any time. 

No longer is a credit card tied to a particular gateway - it sits away from the gateway. This can help you with your initial payment gateway selection (make it less critical to pick the right gateway for today and for tomorrow). You can add gateways as you grow internationally or keep a gateway as a permanent "hot backup" should you experience issues with your primary gateway.

If your business model includes allowing your customers to process credit cards within your application then having your own credit card vault is almost a requirement. Let's say you're building the world's greatest CrossFit gym membership solution. You'll want to work with as many payment gateways as possible so that you can sell to cross fit gyms in Seoul, San Francisco, Sydney and Seville. 

Your customers - the people running those gyms - will want you to support local selections. If you don't help them vault away from their gateway you'll reduce their ability to change if they need to. You'll also tie your hands on strategic payment partnerships in the future.

Yet storing cards puts you fully into PCI compliance scope. Even for a startup (small volumes) you would want to budget $75,000 to $100,000 per year to cover hard and soft costs around maintaining PCI compliance. It's for these reasons that most people store their cards at the gateway. Spreedly aims to solve that problem - more on that near the end.

A form of lock-in that payment gateways have is not returning your cards to you (or in practical reality along to your new preferred payment gateway) Unless you doubt you'll ever want to change payment gateways insist on getting an answer as to whether they support credit card portability. It's rare but becoming more common thankfully. 

Credit card portability will help cushion the blow of changing gateways but it'll still be a fairly meaningful project (API integration, matching tokens to existing users etc)

Alternative Payment Types

Lastly, there are alternative payment types to credit cards. PayPal as a payment type is probably the best known one. Newer payment types include Amazon payments, Dwolla and GoCardless. It seems there'll be more to follow. You'll want to accept these based on customer demand or a desire to drive down your transaction costs. For example, GoCardLess, which is UK based and expanding in Europe, is a bank to bank transfer and only charges 1%. So the appeal is obvious. Newer payment types aren't typically supported by payment gateways (PayPal is the most frequent exception) so today they're a separate effort to support.

Then there are regional payment types - especially in Europe. European's tend to have more direct or debit payment types and they depend on the country involved. Dankort, ELV for Germany and more. If those markets are critical you're going to have to add or start with a European gateway. 

Summary (Yes and the Spreedly Pitch) 

The good news is getting a payment gateway/merchant account continues to get easier while the services themselves get better. That's a nice combination. If you don't see yourself selling outside of your national market and staying under $1 million in revenue then picking any of the "all in one" options I listed should work. Stripe might be the most elegant. PayPal has the scariest reputation but moves you down from 2.9% to 2.5% as soon as you hit $10,000 per month. Braintree has an ever increasing international reach.

Or you could integrate to Spreedly - in particular our Spreedly Core service. 

We vault your cards away from the gateway. We offer a transparent redirect. We work with 40+ payment gateways and are adding support for non credit card types. We give you the independence to store a card and charge it against multiple gateways. We give you the ability to support the gateways that your customers need or want to use to process within your service.

If you're interested check out Spreedlycore.com - which is soon to be combined with Spreedly.com into one single site.