Plaid's pricing is a great example of this: a diverse array of discrete cost components—ranging from one-time fees to ‘per real-time requests’, ‘per completed payment fees’, and even monitoring fees, often monetized through recurring subscriptions.
This intricate fee structure poses a shared challenge for Fintech companies. They must grapple with the complex task of incorporating numerous small fee elements into their systems, both in terms of computation and successful collection. This issue underscores the need for streamlined solutions that simplify fee management and enhance the end-user experience, or at the very least, does not confuse them.
The complexity escalates further when factoring in Enterprise contracts featuring individually negotiated fees. Open Banking companies notoriously adapt their pricings based on the vertical of their customers, and it’s probably the case for other sub-areas of Fintechs, like embedded finance. This adds another layer of intricacy to an already intricate situation.
The whole thesis of Fintechs is to bundle software and core banking offerings, in a more elegant way than what Banks have been able to do, so far.
Square’s pricing page (below) captures this approach:
Billing an increasing number of products, each one bearing their own fee structure, also come with its own complexity. We covered an example here, with Heroku’s pricing.
By the nature of their activities, Fintechs are more prone to adopt a multi-product strategy, packaging low margin offerings (e.g., payment processing) with high margins ‘software’ features (e.g., workflow management, collaboration features).
Instant charge for real-time transactions
Fintechs face a distinctive hurdle absent in other sectors: the imperative to respond to real-time transactions, also called ‘instant charges’. It’s actually one of Fintechs’ superpowers: they sit so close to the money that they can pay themselves directly and instantly out of the money flows they help managing, when ‘traditional SaaS’ need to wait for the end of a billing cycle, and rely on payment rails (cards, etc.) to get paid.
Consider a B2B neobank, levying a $1 fee per ATM withdrawal. Unlike traditional businesses that consolidate invoicing monthly, Fintechs immediately debit and collect such fees. This per-transaction pricing makes it difficult to use a third party tool. That’s why Stripe doesn’t eat their own dogfood: i.e., they don’t use Stripe Billing to bill their own customers.
Furthermore, Fintechs introduce unconventional pricing models rarely seen in other domains. Examples include extracting a percentage from transactions, providing a stipulated number of complementary transactions, and allowing a predetermined transaction amount free of charge. These unique pricing approaches reflect fintechs' adaptive strategies to cater to dynamic financial landscapes.
Fintechs frequently adopt a distinctive pricing approach involving capping and flooring specific transactions.
In conjunction with the already intricate per-transaction pricing structure, the billing engine must further account for setting upper and lower limits in order to accurately calculate and apply charges. This added layer of complexity underscores the sophisticated nature of fintech pricing models.
Fintechs frequently encounter transactions spanning various currencies. As a result, they must factor in real-time conversion rates to meet their billing requirements. This additional layer of complexity arises due to the necessity of accurate and up-to-date conversion rates, posing an additional challenge in the billing process.
Example: transaction made in USD, but the customer is charged and invoiced in EUR.
Unearth subscription and repetition
Alongside the intricate construction of a complex core engine, as Fintechs mature, they increasingly introduce bundles for repeatability. Building a ‘recurring revenue’ motion indeed eases the pain of forecasting, hiring, and fundraising.
This implies iterating on bundles, and pricing structures before finding an efficient pricing motion, which creates corresponding billing challenges.
Charges can be quite intricate when it comes to businesses, and this complexity gets even more pronounced within the realm of fintech. This heightened intricacy arises due to the fact that taxes are influenced not only by the location of the customer – whether it's a state, country, or region – but also by the inherent characteristics of the products being offered.
Consider the scenario where a customer orders a physical card; in this case, taxes and VAT come into play. On the other hand, a banking transaction fee remains exempt from taxation. This nuanced interplay of factors underscores the unique challenges fintech businesses face when it comes to handling charges.
In a recent Linkedin post, we dived into the similarities between restaurants and fintechs taxes. Both have a need for a granular tax model.
For Constantia, our favorite pizzeria at Lago, food and beverages have different VAT rates based on the order type (On-Site or Takeaway), the place (Metropole or DROMs), the beverage type (with alcohol or without). On the other side, for Qonto, where the team met each other, some products are subject to VAT rates while banking products are not.
Both companies need to comply with taxes at the lowest level possible.
As we’ve seen before, diverse billing components like subscriptions and transactions often coexist. While some transactions are seamlessly settled, others encounter issues such as refusals or delayed refunds.
These discrepancies, sometimes spanning months after the initial transaction, significantly complicate the process of revenue recognition. Therefore, Fintechs require a meticulous transaction management system and billing engine to be able to accurately track revenue.
Margins calculations when ‘interchange is involved’
Calculating margins in the fintech realm can be challenging, primarily due to the reliance on interchange. Interchange, a pivotal component of transactions, introduces variability that can obscure clear-cut margin calculations.
For better transparency and understanding, some Fintechs opt for an ‘Interchange ++’ pricing, showing a breakdown of transaction fees.
Other companies may also opt for a revenue share structure with core banking intermediaries, which makes the margin calculations even more convoluted.
This dynamic nature demands sophisticated analysis techniques to accurately gauge profit margins within the context of fintech operations.
When they have the option, Fintechs avoid charging their end-users through external Payment Service Providers (PSPs, e.g., Stripe Payments, Adyen) when they have direct access to the flow of money. Indeed, why leave a 2-3% fee to a PSP when you can pay yourself by debiting the wallets you own and manage, for a living?
In that case, they choose to directly integrate their internal ledgers (built from scratch or with open-source frameworks like Formance) with billing engines. However, this approach introduces complexities during the setup. Establishing this internal ledger-to-billing engine connection can prove challenging, requiring careful navigation through fees, currencies, bundles, subscriptions, and negotiated terms.
This list is far from being complete… and maybe our title wasn’t right. ‘Recognition’ isn’t only about ‘salary’, and other engineers probably have their own challenges too. Our point was to highlight how underrated billing engineers are, and especially in the Fintech space.
The complexity they are handling is rarely known, and often underappreciated, except when they decide to leave the company.
Their work is mission critical and directly exposed to the ExCo level, however it’s often seen as a ‘commodity’ or ‘afterthought’, rather than what it really is: a high complexity and very sensitive engineering challenge.
Two hosting options, same benefits
Whether you choose the cloud version or decide to host the solution yourself, you will benefit from our powerful API and user-friendly interface.