We use cookies to better serve you
I AgreeMore InfoMore Info
1. Update to our Privacy Policy

Hi! We have updated our Privacy Policy to make sure you stay well informed about how we process personal data.

2. Cookie Policy

We place cookies in order to make sure our website works properly and to improve your browsing experience, to offer social media functionalities, to streamline and personalize our marketing content and to show you personalized advertisements (including on third party websites). We sometimes share cookie data with our partners for these purposes. Our cookies remember your settings and the data you fill out on forms on our website and analyze traffic to our website. Our cookies also register how you found us and collect information about your browsing habits. You can read more about our use of cookies and how we share data with our partners, and can change your settings on our Cookie Policy.

The Life of a Head of Payments: How do I sell online?

6
Dec


The year - 2010. I admit, I didn’t know much about the payments industry. I came from Product Development and knew very little about selling online, or even offline for that matter. But then things changed. In this blog series I would like to share with you the experience and the knowledge I have gained during my six wonderful years at Wix developing their online payments operation, get you in on why we decided to develop an in-house payments solution and what I wish I’d known back when I was just starting out.

A little bit about me before we get into things:

I have been in the software industry since 1993. Since 2004, I have held numerous executive Product and Project Management roles in various industries (from B2C web/consumer products to B2B technological products).

Today, my true passion and specialty is Global Online Payments & E-commerce.

I gained most of my expertise at Wix while overseeing the payments globalization, both for the company’s users and for the “users users”, meaning also the site owners payments solution. Following that, I began advising to leading internet companies (Fiverr and monday.com just to name a few) and other startups on the topic of online payments.

I believe that sharing my experience can help other companies sell online, and will hopefully give you a valuable overview on this area. I myself would have truly have benefited from such a summary back in the day. So enjoy…

When talking about “selling”, whether online or offline, it actually involves two equally important parts:
  • Billing (the logic behind who to charge and how much) and;
  • Payments (the actual “acquiring”)
When talking about “payments”, we also need to look at two aspects:
  • POS (point of sale/credit card present): offline purchases, when the buyer swipes his CC or other alternative payment method in a physical store or location
  • ePayments: online purchases when the physical card not required

In this blog series I will focus on ePayments for SAAS products for high-tech companies selling SAAS products. Hopefully, I will succeed in answering all the burning questions you’re probably asking yourself about making the smartest payments solutions decisions.

How Do I Sell Online? (And Quick)  

It all began when Wix.com (or any startup for that matter) decided it was time to show some revenues. What did they do? They looked for the quickest, easiest payments solution to charge their users online for their premium services.

After most startups start asking around, the majority end up using PayPal. And why not? Sound like the perfect solution. After all, all they want is to allow quick and simple credit card processing.

At Wix, the first integration of a billing solution was done “quick and dirty”. We’re talking 2009 (shortly before I joined them) and they needed to rake in revenues ASAP.

In less than 1 month, Wix integrated and decided to go with “AllCharge”, a global Internet payment service provider. Shortly after that, we came to realize that this solution was simply not good enough (low approval rate, didn’t support all credit cards...). We then integrated with another payment solution- Plesk (Parallels), which provided us with a billing system to manage both the subscriptions and payments, mostly for our U.S and European users.

A few insights later (after already being integrated with 2 billing solutions: first Plesk then followed by a second solution- Plimus), we decided to create and develop a proprietary in-house billing solution. I’ll elaborate more about this important decision and its vast impact on our operations in the “develop or buy” section a bit later on.

Let’s pause for a moment. If you’re scratching your head with confusion on what I just wrote about billing systems and payments, hopefully the following basic overview might help.


Basic Payments Buzzwords

This drawing explains several basic billing & payments terms you’ll probably encounter soon enough in your company or position:

First (top left) we have the Merchant who wants to sell. Every online or offline merchant needs to open a MID (Merchant ID) via an Acquirer Bank (or “Acquirer”) or Processor that is connected with the Acquirer.

Payment Methods divide into two main categories:

  • Credit card/Credit Schemes (Visa/ Mastercard etc.)
  • Alternative Payment Methods (e-wallets, cash etc.)

The Issuing Bank - the bank that issued the buyer’s credit card.

The Acquiring bank - the bank essentially performs the “card processing”. This means approaching the Issuing Bank, requesting to charge the buyer’s account, then placing the funds into the seller’s account (“settlement”).

Often, you will encounter the words “Gateway” or “Processor”, which are in fact the bodies who communicate with the Acquiring Bank. Sometimes the Gateway or Processor own a license to self-acquire in a certain region, without the need to connect with or through another acquirer.

On top of these you will sometimes find Aggregators. Using them will enable you to charge through one payment page that includes various payment methods (credit cards, local wallets etc.).

In a nutshell, the above is what I call “The Payment Ecosystem”.

Now that we’re all on the same page when it comes to the basic terms, we can move on to the “Billing System”, which I’ll simplify asa complex software system that determines the logic of who to charge and when”.

The Billing System:

The Billing System is mostly essential when your payment is not a one-time payment.

Let’s go over some of the basic Billing System functionalities:

  1. Payment Logic- who needs to be charged, when and how much.

It can be a subscription that renews periodically or any other logic that is not one-off.

  1. In addition, the Billing System holds the “Product Catalog”- for each item you sell, it converts the price into the relevant currency.
  2. The Billing System also manages Coupons, in case you want to offer them to your customers.


Which Provider Is Right for You:

When start-ups come to me for advice, the three basic questions I have them answer are:

  1. What kind of organization are you? Or- what kind of legal entity are you?
  2. Who are your customers?  What geographies and demographics?
  3. What is your business model? Returning customers? Subscribers?  

Based on these 3 questions, you will be able to choose the best billing and payments provider for you.

Here’s how…

When it comes to payments, there are a few golden rules:

1. Choose a provider that (1) works with acquiring banks in the same region as your customers, and (2) it’s best you open an entity in that region as well.

So, if your customers are mainly in the U.S, you would want to find a provider that offers acquiring in the U.S, in addition to opening your Merchant ID there. Why?  

  • You’ll receive better fees
  • You’ll score a much better success rate

2. Where to save your customer’s credit cards: If you use a subscription model, the customer’s credit card details need to be securely stored somewhere, and the solution must be PCI compliant. The same thing goes for when allowing a “1 click payment” for returning users (it really helps conversions, but I’ll leave this for another day).

The Payments Decision:

Based on Rule #1 - If your users are in the U.S, you would want to use a payments solution that has acquiring in the U.S (Stripe, Braintree etc.)

For example, in order to open a MID in Stripe, you will need to have a local U.S entity.

(you need to check this with each provider, but usually when they do not ask you to have an entity in the region you want to sell in , it means they can redirect the transaction through another acquirer (cross border), which usually will cost you more fees approval rate will be usually lower.)

Based on Rule #2- to save credit cards details, and assuming you are not PCI certified, your provider will need to save the CC for you. The good news is that most processors/payments providers do that, and give you a token back. The bad news is that from that moment on, you are pretty much ‘stuck’ with this provider. Moving the credit card to another PCI compliant provider can be done, but it's not easy. Here, you also lose the ability and the freedom to swap transactions between providers (in case you have a failover processor).

In short- for starting to sell online, it may be sufficient to use one payments provider.

On the other hand, for more advanced optimization and globalization, one payments provider is not ideal. I’ll explain further in the chapters ahead.



The Billing Decision:

Do you need a billing system? Ask yourself - where is the product catalog saved? Do I have specific logic (i.e. subscriptions) which I want to apply when charging my customers?

In recent years, it seems like more and more companies, even startups, are using their own logic and developing their own billing system.

But developing a billing system requires resources, and dealing with many aspects; from coupon management, currency management, and of course the subscription engine.

As mentioned earlier, at Wix, we used two separate billing systems & payments solutions as we did not want to rely on any one provider.

But soon we realized that we developed an undesirable dependence once the client’s CC was saved with any of the two providers, as we could not move an existing customer from one billing system to another along with his credit card details. This realization (together with other reasons) was part of the decision to develop our own payments solution.

Of course, to be able to have our own solution, independent of any one or more payments providers, first we needed a way to save the user’s credit card details. For that we needed to be PCI level certified. And in 2013, when we got our PCI compliance level 1 certificate (which took around 10 months to get), we were able to begin using our own billing system, connected to multiple payments providers, all while handling most of the logic in-house, as I’ll explain in the next chapters.

Stay tuned for the next chapter in the series.


A few more interesting reads

International Payment Preferences part 1

International Payment Preferences part 2

Six Ways to Increase Your Approval Rate

Stay on top of your payments

Sign up for our newsletter to get the latest payment news

By clicking Subscribe you agree to ZOOZ’s Privacy Policy.