How Swimm selected a payment provider

It’s an exciting moment in a startup’s journey when you realize your product is worth paying for, and you begin shifting the focus from product-market-fit and growth to revenue.

The question then becomes this: what’s the best way to collect payments from customers?

In my experience, this step is thought to be just adding in a simple feature to the single user’s story – like “Users clicks buy now” -> “User is charged.”

But selecting a payment provider can be one of the most important decisions made while developing a product.

Usually, the day to day engineering process tends to play out linearly like a video game: you get a well defined task, finish it, only to get to the next task waiting to be finished. But these kinds of decisions – getting a payment provider to work now without considering the future – can be detrimental to your future engineering roadmap.

In a previous job, I worked on WeWork’s contracts and billing systems. I had a front-row seat for the implication of these types of decisions and how complicated the process can be over time: new prices, products, countries, payment methods. I learned a lot about the pros and cons of using different providers.

So today, I’m sharing how we approached selecting a payment provider for Swimm. We started by creating an outline of questions that we knew we wanted to answer – to unpack countless numbers of decisions we would need to make.

The checkout experience

We began our payment selection process by laying out our basic assumptions about the user buying journey.

We mapped it out and added a checklist you can see below.

“User clicks buy now” – Who is the user?

Are we a B2C company? Are we selling a product directly to a single consumer?

• Where are the services being provided? Are they provided online? In a specific country or state?
• Where is the consumer registered from a tax standpoint?

Are we a B2B company? Are we selling a product directly to a company?

• Who can buy this product for the company? An Admin? A Financial Decision Maker? Any employee?
• Where is the company registered? In which country or state?
• Should tax be collected in that country/state?
• Should the company’s tax status be captured?

Where are we expecting our users to be located?

• Some countries have a minimum revenue requirement before requiring stricter reporting rules.

“User clicks buy now” – What is the user buying?

Is it a subscription?

• Should it be charged monthly? Quarterly? Yearly?
• Should there be any proration? If yes, up to what percentage?

Is it a single transaction?

• Is the product taxable?

Is it usage-based?

• What are the different rates we charge?
• What actions need to be taken when a price change occurs due to an update in usage? (Charge immediately? Postponing the charge to the next invoice?)

Is there a trial for the product?

• If yes, for how long?
• Does the user have to cancel the subscription?

Is there a free tier?

• Will we need a Paywall?
• Do we have any customers with different offerings than the default?

Will there be any additional charges? Add-ons? Setup fees? Shipping? Deposits?

“User clicks buy now” – Is the user presented a price?

• Should it include tax?
• Should it include shipping?
• Should it be adjusted based on quantity/usage?
• Should it include the prorated price? Full price? Both?
• How do we deal with fractions in a currency? Do we round up? Down? How many digits do we display after the decimal point?
• Is there a single price? Is it priced per currency? Per country? (EUR can be a tricky test case, for example) Would we have customer-specific prices? Will we be A/B-testing different prices?

“User clicks buy now” – Are there discounts?

• What type of discounts, if any, are offered?
• Should promotion codes be supported?

The billing process

Next, we began unpacking our billing process – including invoicing and collection. Here’s how we broke it down.

“User charged” – What currency should we use?

• Is this product always priced in USD? Are we expecting any adjustments for other countries?
• What about foreign transaction fees/conversion fees for users from different countries?

“User charged” – What payment method should we use?

• Credit cards are usually supported but typically have a higher fee
• Should we accept less frequent cards such as Discover / Amex?
• Should we support 3DSecure? Other types of verification, such as zip code?
• Should we support bank transfers such as ACH or SEPA?
• Should we support sending payment requests – meaning sending an invoice to the customer – allowing them to pay it later?

“User charged” – Should the user receive an invoice?

Some countries require uploading an invoice to a government service

Some countries require certain details mentioned in an invoice

• Marking it as a tax invoice
• Displaying tax IDs on invoices
• Showing the company’s address on invoices

“User charged” – What compliance standard is required?

• Should we adhere to a level of PCI compliance because we are collecting payment details?
• Should our servers/clients have access to the client payment information?
• Should we adhere to SOX compliance because prices can be controlled and changed now?
• Should we adhere to GDPR compliance because of the data we are collecting?
• Should we add some fraud detection tools?

“User charged” – What happens after the purchase?

• Should we support refunds?
• Should we support cancellations?
• How should we handle chargebacks?
• What happens if the customer’s credit card expires?
• What happens if a payment is declined?

Company stakeholders in the billing process

As was the case for Swimm, many stakeholders will likely want to be part of the billing process discussion. I recommend that efforts be made to both identify and understand each stakeholder’s priorities earlier rather than later. Swimm had a kick-off meeting with the following teams: sales, legal, finance, product, engineering, billing, and support.

We found that once you’ve got the answers to the slew of questions about the billing process, selecting a payment provider becomes significantly easier.

For example, if you decide to go with a proration option, this will likely narrow down the list of potential payment providers; or if invoicing with custom fields is required, it will reduce your options even further.

If certain criteria limit your choice of payment providers too much you can expand the list by deciding that either (a) the requirements need to be reconsidered or (b) that a few different providers should be considered for different processes (payments, invoicing, taxes, etc.)

Payment providers finalists – making the final decision

Once we narrowed it down to a short list of providers (“Swimm’s finalists”), we began addressing many longer-term considerations since Swimm’s product would be evolving.

Here’s a brief list of some of those questions that will help you look ahead to the future vision for your product.

1. What are the technical capabilities of the payment provider? Is it documented? Is It easy to integrate? Does it support your programming language? Is it easy to get support?
2. How easy is it to understand the customer payment journey?
3. Does the payment provider support one-off adjustments?
4. How easy will it be to change the product price? To introduce a new product? Add a promotion code or a different business model? Sell in a new country?
5. What is the payout process of the payment provider? How long does it take? Are there any currency conversion options?
6. How do we anticipate the future size of the business?

How we made our choice

As a SaaS product allowing developers to create and maintain code documentation, we knew there were some items we needed right from the get-go.

1. Subscription for Swimm’s product, priced at the per-user level
2. PCI compliant, reducing our access to customer payment information to a minimum
3. Proration of charges to the 1st of the month
4. Support changes in quantity and charge them on the next invoice
5. Support charging in multiple currencies with local taxes in certain countries
6. Issue tax-compliant invoices in specific countries

Why we chose Stripe as our payment provider

After experimenting with a couple of payment providers, and consulting with all of Swimm’s stakeholders where we worked on a few proof of concepts to make sure every priority was supported by our selected provider – we were ready to make our final decision.

We found that Stripe met most of our requirements, and even had more advanced features such as integration with our programming language of choice, add-ons such as fraud detection, reporting, tax calculation, and revenue allocation – which we knew would become more relevant as Swimm grows.

Documentation of our decision

It was significant for the larger Swimm team to document the different internal debates and discussions in finally deciding on a payment provider. So we did just that.

After all, Swimm is all about documentation – and so we wanted to be sure that we could look back at a later point to understand the context and the why. These are things you often forget.

Bottom line

Overall, the process of choosing a payment provider for Swimm went smoothly. There was a lot to decide and countless numbers of discussions that stretched out over days and weeks to clarify, as a company, what we wanted and why.

Having these discussions before jumping into implementation saved us a lot of headaches.