Create a pricing model as flexible as Swan’s, the Banking as a Service (BaaS) platform backed by Accel, with multiple features and a billing system that scales with your operations.
What's in it for you?
In this article, you will learn how to build a billing system based on several different components, which all need to be monitored and have their own pricing.
This template is suitable for companies whose granular pricing mainly depends on usage, such as fintechs and companies that offer a modular platform, which allows customers to select the modules they need and only pay for what they use.
What's the secret sauce?
Swan’s standard plan includes a monthly subscription that gives access to many services, for which customers are charged based on consumption. While the initial setup is free, each additional service has its own pricing model, as described below.
Percentage charge (based on transaction amount)
€1/month per account
€5/month per account
€1/month per card
Single-use virtual cards
€0.10 per issued card
€5 per printed card
SEPA credit transfers & direct debits
€0.15 per transaction
0.03% of SEPA transac. out
With such a granular pricing, it is essential for Swan to be able to define different metrics to monitor the consumption of their customers.
We are going to teach you how to replicate this pricing with our billing solution.
What do you need?
The first thing to do is to create your company account on Lago Cloud or deploy Lago Open Source on your existing infrastructure. In both cases, you should ask a back-end developer to help you with the setup.
Our documentation includes a step-by-step guide on how to get started with our solution.
Step 1 – How to count events
We are going to take as an example the ‘single-use virtual cards’ line from Swan’s pricing.
The BaaS platform charges €0.10 per issued card. Therefore, Swan needs to record the number of virtual cards created by each customer.
Through the user interface, we have created a billable metric called ‘Virtual cards’. For this metric, the aggregation type is ‘count’.
Every time a single-use virtual card is created by a customer, an event will be pushed to Lago. At the end of the billing period, Lago will count the events (i.e. the number of cards created) associated with each customer and use this number to invoice them according to their consumption.
We can apply the same method to create billable metrics for physical cards (€5 per printed card), and SEPA credit transfers and direct debits (€0.15 per transaction).
Step 2 – How to count unique events over a billing period
Our next example is the ‘business accounts’ line from Swan’s pricing.
The BaaS platform charges €5/month per business account. Therefore, we are going to create a new billable metric that will allow us to calculate the number of business accounts associated with each customer.
We also define the aggregation type to be recurring in order to keep the aggregated amount for the next billing period.
Our new billable metric is called ‘Business accounts’ and includes the ‘business_account_id’ property.
For this metric, the aggregation type is ‘count unique’, which means that regardless of the number of incoming events related to the same account, each business account will be counted only once.
We can apply the same method to create billable metrics for personal accounts (€1/month per personal account) and cards (€1/month per card).
Step 3 – How to calculate a sum based on a property
We have already created billable metrics for each line of Swan’s pricing, except the ‘movement fee’.
The BaaS platform charges 0.03% on outgoing SEPA transactions. Therefore, the corresponding metric should allow us to calculate the total amount of transactions.
In this case, the aggregation type is metered. It means the aggregated amount is reset to 0 at the beginning of the next billing cycle.
Our new billable metric is called ‘SEPA out’ and includes the ‘transaction_amount’ property. Incoming events will be aggregated using the ‘sum’ function to add up the amount of each transaction.
Step 4 – How to create a pricing plan
Now that we have all our billable metrics, we can replicate Swan’s standard plan.
First, we need to add a monthly subscription fee, which will be paid in advance (i.e. at the beginning of the month), as illustrated below.
For the usage-based part of the pricing, we are going to define multiple charges, using our billable metrics.
‘Virtual cards’: €0.10 per event;
‘Business accounts’: €5 per unique ‘business_account_id’; and
‘SEPA out’: 0.03% of the sum calculated with the ‘transaction_amount’ property.
At the beginning of the billing period, an invoice related to the monthly subscription will be generated automatically.
At the end of the billing period, Lago will automatically invoice each customer according to their consumption, then all counts and calculations related to billable metrics will be reset to zero for the next period and remain the same for recurring metrics.
Fintech companies like Swan rely heavily on usage-based components for their pricing.
With Lago, you can adapt this template to your products and services, using some of our most popular features:
Plan models, including monthly/yearly plans that can be paid in advance or in arrears;
Billable metrics, including multiple aggregation types; and
Charges, including our percentage pricing model (and more).