Online payments for product managers

The content is recommended for you in case you are:

1. A product manager responsible for your company’s billing systems and experience
2. A product manager responsible for features that involve payments, such as marketplace or eCommerce
3. Want to learn more about online payment

In this post you will find:

1. Lessons learned from my experience with designing payment and billing experiences for various user segments and billing schemes, engaging tens of thousands of users.
2. Terminology guide for online payments and billing.

Designing payments and billing experiences

Many of the advice here is true for any kind of product management work but becomes crucial when dealing with payments and billing.

1. Keep it simple and standard

Simplicity is always important in product design. It’s even more important with payments and billing. Payments are sensitive, people are generally more concerned and stressed when paying or when dealing with billing. Therefore all the reasons for keeping things simple and standard apply with much greater importance.

Do not innovate! Unless your product innovation is tightly tied to its pricing, payment, or billing experience. Make people understand and feel comfortable by giving them what they are used to and familiar with. At some point I coined a phase in Duda: “if Stripe does not support it out-of-the- box, we should not do it.” The reason here is that Stripe is serving thousands of SaaS companies like Duda, and if their product managers did not think that some payment or billing feature or behavior is a good idea to be part of their product, so probably no other company really needs it, and most chances that we also don’t need it.

Duda’s original billing systems included a lot of custom features. When we developed Duda’s Client Billing, we decided not to support any idea or request that cannot be created by using Stripe features as-is. And actually, we did not hear much demand for such features. From my experience, coming up with non-standard payments and billing requirements is often a result of group thinking within the company and a false sense that “we are special and should do things in a different way.”

The second reason to keep things simple and standard is immutability. Recurring prices usually cannot be changed once used in production. So each change you would like to do will require developers to first develop a new solution and then either carry out a complex migration or maintain two solutions in parallel, which is very costly.

At Duda, we have a very complex billing experience, some of it for good reasons and some for less. Each complexity we introduced to the billing system is still with us. We once analyzed a purchase popup to find out it has 13 possible states, depending on your billing state. Migrating users from our old billing system to the new one is a project that took us 2.5 years. Looking back, our unique billing model allows us to support the unique requirements of our business. But in hindsight, we would have made some different decisions.

2. Break down delivery

Another piece of advice that is always true in product management, and twice as true for payments and billing. This is not always applicable, but I encourage you to try and implement it when you can. Map out the user flows and decide which of them are a must, and which can be implemented later. Once you deliver the must, you are free to decide whether to continue straight ahead to the next flows or to attend to more pressing needs, keeping it agile.

In many cases, you can leverage features of the payment processor or billing system you integrate with to fill for the flows you deprioritize. For example, Stripe’s customer portal is an out-of-the-box billing management feature where your subscribers can upgrade, downgrade, or cancel subscriptions, download invoices, and receipts, and update credit card details. Developing all of these could take weeks. A second example from client billing: we first launched for our beta group with many functionalities available only via Stripe dashboard and customer portal, and not in Duda’s product. These included: configuring products and prices, hosted checkout, and the customer portal. We created deep links to Stripe for each function, instead of developing a UI in our platform. 

3. Think about permissions

Money is a sensitive topic. Most software products with more than one user per account have some permissions mechanism. Think about: Who should see billing and payment information? Who can make actions? How do you verify identity in other channels, such as customer support? Once the free trial is over, can all users upgrade to a paid plan? Who can cancel? Can users see upgrade or downgrade options or locked features even if they don’t see prices? Can they see the plan they are on and not have access to payment info?

4. Be consistent and clear

Another always true advice. Use the same terminology across the entire flow. Remember that your marketing site is also part of the flow, even if managed by the marketing department. Users don’t know it’s two different teams, and they don’t care. IF you are using UI components of your payment processors check the language and design used there and use it within your product.

Give attention to failure scenarios. Payments may fail for multiple reasons and the failure might not be in a system you fully control. For example, a card reported stolen, the payment gateway requires strong authentication and the user fails to provide details, and of course, billing failed charges. Map failure flows, and make them as clear as possible: explain what happened, what are the implications, and what should the user do. Make it clear if the user was charged or not and whether they should try again.

Statement Descriptors

Statement descriptors are the descriptions buyers see in their credit card or bank statements. Make sure it is informative and that users can easily relate it to their purchase or subscription. Unclear statement descriptors are a top reason for users to dispute their charges and for merchants to get chargebacks.

In case your system creates varying charges, consider adding a short description or a reference to an order number to the dynamic part of the descriptor. For example, descriptors like Ben's clothing T-SHIRT or Ben's clothing KMP3W where KMP3W is the order confirmation number will help users to remember they ordered a t-shirt online a few weeks ago, and not contact their bank. This practice is commonly used by airlines and big marketplaces like Amazon.

5. Collaborate with business units from day one

Many times, business units have a lot of knowledge of users’ needs and preferences regarding payments and billing. Sales, support, customer success, and marketing know why people buy, what they ask, and what makes them angry or delighted. It’s better to have these insights and data as early as possible. In addition, these units will be a major factor in delivering any decision you make regarding payments or billing experience.”

Online payments terminology

This section explains some basic concepts. Since the online payments domain is very complicated, I’ve chosen to introduce the basics in a simplified way which is not always totally accurate but does work for our current context.

1. Merchant: sells goods and services, and gets the money.
2. Buyer: pays, and gets goods and services.
3. Payment processor: gets payment method, confirms the payment, transfers money, handles legal (fraud, disputes).
4. Payment gateway: the technology that encrypts and transmits the payment details from the point of entry to the payment processor.
5. Merchant account: an escrow account for the merchant under the processor. Holds the funds the buyer pays until they get to the merchant.
6. Issuer (credit card or payment method): the organization that created the payment method, usually a bank. The issuer pays the processor, confirms payments, and charges the buyer.
7. Card on file: a state in which the buyer allows the processor to keep credit card details and for the merchant to charge it again in the future, without the buyer having to provide the card details again. Card details are securely saved by the processor, and the merchant gets a token to initiate future payments.

This diagram describes the relations between the different payment entities:

Billing terminology

When dealing with recurring payments, there are a few more terms one should be familiar with:

1. Product, price, contract: products are the basic entities of billing systems. They represent the recurring products and services offered for purchase. Each product has at least one price and can have more than one, like in the case of a monthly price and an annual price, or one price in US dollars and one price in Euros. Contract is an alternate term for price. Once used with real users, prices are usually immutable, meaning cannot be edited except for naming and labeling changes.
2. Line item: a combination of price and quantity which results in a sub-total. For example: Basic product manager course $100 x 2, $200.
3. Frequency or recurrence: the time period for a recurring payment to renew. The most common frequencies are monthly and yearly (aka annual). Other frequencies are daily, weekly, quarterly, or 2-year, 3-year, etc.
4. Subscription: a set of line items that have the same frequency and are charged together. Each subscription is always related to a specific buyer.
5. Billing cycle, payment cycle, or billing period: a specific time period for which a subscription is renewed. For example, a monthly subscription with a payment cycle from January 10 to February 10, and then from February 10 to March 10, and so on.
6. Invoice: in each billing cycle the billing system produces an invoice for each active subscription. The invoice usually contains all the line items of the subscription.
7. Charge: once an invoice is created and finalized, most billing systems will also try to charge a payment method. The charge might succeed or fail. If it is successful a receipt will be issued. If not, most billing systems have some type of recovery or retry sequence.
8. Proration: if the line items of a subscription have changed during a billing cycle, most billing systems will automatically charge the relative amount based on the ratio between the date of change and the billing cycle. For example, upgrading from a $10/m subscription to a $15/m on the 15th of the month, with a billing cycle that starts on the 10th of the month, will result in a $14.16 invoice at the end of the cycle. The invoice will contain two line items: $10/m x 5 days = $1.66, $15/m x 25 days = $12.5.
9. Billing schemes: use in advanced billing situations, mostly when the amount of service supplied each billing cycle is changing. Including tiered pricing (aka volume discount), usage-based pricing, and more.

This diagram describes the relations between the different billing entities: