If you’re using Bubble to build an app for a business, chances are good that you’re incorporating payments. As fintech specialists with over a decade of experience, my team and I speak with many entrepreneurs and Bubble builders about the payment scenarios their apps require. More often than not, the specific use case, vision, business model, or some other factor necessitates a more complex payment solution than Bubble’s Stripe plugin will easily enable.
This post highlights the most common payment business models I come across and shares some suggestions about the best path for adding these payment features to your Bubble application. Keep in mind that your use case may use elements from multiple of the categories highlighted below.
The payments ecosystem is complex - especially for a no-code builder. The Lost Sheep Advisory team is here to help. You can schedule a free 20-minute project and payments consultation to discuss your use case, email us at [email protected], or drop me a note on the Bubble forum.
Basic SaaS
Your app is in the Basic Software as a Service (SaaS) category if you charge your user’s credit cards to sell them subscriptions to your app, sell your app itself, or sell products that you directly offer (i.e., not from a 3rd party seller as in a Marketplace).
For example, let’s say I’m a guitarist who has created an app to sell tickets to my performances or let patrons sign up for a monthly subscription that includes access to all of my performances. The money flows directly from the Buyer to the Seller in a single hop.
This use case is well-supported by Bubble’s Stripe plugin. You can easily add and charge users’ credit cards and set up Subscription plans. Bubble’s documentation and plenty of YouTube videos do a great job explaining how to add this to your application. If Bubble’s Stripe plugin isn’t doing the trick, you’re probably moving into a more complex payment scenario.
SaaS with Lower Cost Bank Payments
The most common and user-friendly way to accept online payments is via credit card, but doing so can be expensive. Stripe’s standard US pricing is 2.9% + $0.30 per charge (which is a bit pricey compared to the credit card industry average, but their technology advantage makes the comparative cost worthwhile). Credit card fees can quickly eat into your margins and start adding up to a high cost, especially if your average transaction size is very small or very large (for example, a $2000 transaction results in ~$58 in fees and a $10 transaction results in $0.59 in fees). As the selling merchant, these fees buy you the trust customers have in using credit cards and some protection from risks related to accepting fraudulent payments. However, you’re also paying for your customers’ perks from their credit card companies and fees to multiple intermediaries.
Fortunately, there are other lower-cost methods available. The lowest cost tends to be Bank Payments (in the US, these are known as ACH Transfers). The pricing for Bank Payments tends to be lower - usually less than 1% of the payment price, often with a fee cap for large transactions of ~$5.00. So for a $2000 transaction, you could save more than $50 in fees. However, these lower-cost methods come with other tradeoffs, including speed (they can take 2+ days to clear, depending on your world region), increased risk of fraudulent use, and a more burdensome customer experience that can decrease conversion; any of these tradeoffs could mean that Bank Payments aren’t a good fit for your business model. That said, there is a rapidly developing ecosystem of technology companies and features to address these tradeoffs through features such as Same Day transfers or access to Real-Time Payments networks. Worldwide, Bank Payments (also known as Account to Account transfers) are deploying more widely and provide a viable and compelling competitor to credit card companies.
From an application development perspective, implementing Bank Payments requires more effort to add to your application. One feature of these types of payments is usually asynchronicity - unlike credit card payments, you may not know for a few days if a payment succeeds or fails. Therefore, as a developer, you need a deeper understanding of these payments to add them to your app successfully.
Here are some examples of approaches to adding Bank Payment functionality to your Bubble app:
- Use Stripe’s Pre-Build Checkout Page (available via Bubble’s Stripe Plugin) and enable Bank Payments on your Stripe account
- For US apps, use an ACH-specific payment provider like Dwolla combined with an Account Verification provider like Plaid Auth. Lost Sheep Advisory has a plugin available specifically for this use case.
- Directly integrate Stripe’s Bank Payment features using the Stripe API and their Financial Connections feature.
- If you’re in Europe, you may be able to use Payment Initiation products from a variety of providers like Plaid or Tink.
To continue our guitarist app example from earlier, this lower-cost bank payment scenario could involve pushing patrons to use Bank Payments as the primary payment method to save me, the guitarist, some money. Credit cards could still be available as a fallback option.
Worldwide, Bank Payments (also known as Account to Account transfers) are deploying more widely and provide a viable and compelling competitor to credit card companies.
Complex Saas
The previous use cases were focused on relatively straightforward payment scenarios: selling fixed-price items or simple per-month subscriptions using a single payment platform. That works for many apps, but some may need more complex handling. This section will highlight a few of those complexities.
I’d like to make one meta recommendation about integrating Stripe into your Bubble app for more complex scenarios: I generally advise NOT using plugins for Stripe integrations beyond what Bubble’s Stripe plugin provides. Instead, I highly recommend you build your Stripe integration directly from your API connector. Doing so will allow you to address the nuances of your specific use case in a way plugins usually have to over-simplify. There are some excellent tutorials on YouTube and the Bubble forum on how to get started building Stripe integrations in your API Connector.
Business-to-Business (B2B) Invoicing
Instead of having your user add a payment method that you charge (i.e., pull funds from), you can set up your app to use Stripe to send an invoice to a customer. The customer can then asynchronously pay that invoice via credit card or bank transfer. This may be the right approach if your customers are primarily larger businesses with Accounts Payable and Invoicing processes. You can use Stripe’s invoicing product as a standalone or combined with Subscriptions to enable this. Such an approach could also let you shift invoicing timelines by setting Invoice periods for different cadences than Stripe’s standard “start now” dates or selecting longer invoice due dates (e.g., NET30).
In the guitarist example, this scenario might apply if I was selling group tickets to a promoter or venue. I’d allocate them the tickets and send a future-due invoice for payment.
Irregular or Usage-Based Subscriptions
Suppose your application offers multiple tiers of service or sub-products. You may need to add multiple line items to a subscription (e.g., a monthly platform fee plus bundles of additional user seats). This can get even more complex if you have some services billed monthly and some billed annually (e.g., an Annual base price plus monthly usage fees). You can also set up usage-based subscriptions, for instance, if you bill $10 per month for each gigabyte of consumed app storage. Stripe’s subscription product can handle this complexity, but you’ll need to build your integration using the API connector to address the specific use case.
In our guitarist example, this could be a patron “listens” feature where they pay $0.10 per listen to my newest recording.
iOS Native App Payments
Apple’s App Store is notorious for requiring in-app payments for many standard business models (basically, anything not involving physical goods). If your Bubble app is wrapped for sale in the App Store (I like using BDK for this), you may be in this position. Your Bubble app will need to handle payments and subscriptions via Stripe for your web app and Android app, plus Apple’s in-app charges for the iOS app. This “omnichannel” payment scenario integrates many payment platforms, which introduces complexity and implementation time. Your app will likely need to track payments and their status internally in your App Data rather than rely just on a payment provider like Stripe to do so - design accordingly.
Simple Marketplace
An Important Note About Paying Money To Your App’s Users
It is straightforward to accept payments from users. Due to anti-money laundering (AML) rules, taxation requirements, know-your-customer (KYC) practices, and other regulations, paying money out to your users is much more complicated. A handful of providers - including Stripe Connect, Dwolla, and others - enable paying money out to users. The specific features of each vary; the further you are from a “typical” marketplace like Airbnb, Etsy, or Shopify, the more challenging it will be to find a provider to support you.
A simple marketplace is characterized by a customer purchasing something from a seller (usually a digital good or service) enabled by your application. Usually, your application will take a portion of the transaction as a platform fee. Your platform is the intermediary only: the transaction is between the Customer and The Seller. The Seller retains the risk, payment fees, and ultimate responsibility for delivery of the product or service. Examples of this kind of platform include Shopify or an Invoicing service like Invoice2go. This type of arrangement is easily supported by Bubble’s Stripe plugin using the Seller features.
To extend the guitarist example, let’s say I restructure the app to allow a few musician friends to manage their ticket sales and patrons. Each of them signs up with Stripe as a seller and sells tickets through the app. I take a small platform fee to pay for my Bubble license. This is an example of a Simple marketplace.
What makes a Marketplace no longer simple? Any of the following are signs that your Marketplace falls into a more complicated category:
- You want to allow your customer to buy from more than one seller in a single purchase
- Your sellers aren’t familiar with running an online business themselves
- You want your customer experience to be one of purchasing goods or services from your platform rather than from individual sellers on your platform
- You want to build a platform payment experience that’s invisible to your sellers (i.e., sellers don’t know or need to deal directly with Stripe, don’t know about payment fees, etc.)
- There is a time delay between when a Customer makes a purchase and when a Seller should be paid
- The Platform Fee cannot be calculated at the time of the customer’s purchase
Complex Marketplace
If your app is not a simple marketplace, then it is complex for one or more reasons. There are a few chief characteristics to consider when designing your payment solution.
Payment Timing
This scenario arises when your business model requires a delay between a customer paying and a seller receiving funds for that purchase. For instance, Airbnb often collects payments from customers as reservations in advance but does not pay those out to the host until check-in. Or, in the case of selling physical goods, you may not pay the Seller until a shipping confirmation is sent.
In our guitarist ticket sales app, this could arise if I decide that the other musicians can sell tickets on the app but that they won’t receive the ticket sales proceeds until the concert date.
In this case, you’ll need to handle the collection of funds as a separate step from the payout to the seller. In Stripe terminology, this is called “Separate Charges and Transfers” (or, alternately, a delayed Destination charge); other Marketplace-enabled platforms like Dwolla function this way by default. In this use case, you’ll need to carefully manage how funds payout from your platform’s payment account to your business’s bank account since funds may be required to cover future transfers to Sellers.
Implementing Stripe Separate Charges and Transfers is best accomplished with Stripe by using the API connector directly. However, other platforms, like Dwolla, function this way by default, so using the Dwolla plugin may work well.
Multi-Party Marketplace
Let’s say your Marketplace sells handcrafted pianos and includes the delivery service for the piano. In this case, you would have two sellers for a single transaction - the maker and the delivery service. Another example is an Etsy-like marketplace where customers can add things from multiple sellers to their cart and then check out altogether. These are examples of multi-party payments that split a single customer purchase into multiple transfers to different sellers.
To torture our guitarist app example, in this case, we’ve partnered with the venues that host the concerts. Ticket sales are split between the venue and the musician.
Again, Stripe’s terminology for this is to use Separate Charges and Transfers. Your app will be responsible for telling Stripe (or another platform like Dwolla) how much to keep for your platform and how much to pay out to each seller. Your app will need to keep careful track of the funds collected from the customer to ensure it makes it to the correct seller.
Merchant of Record & Payment Fee Payer
The final key consideration with complex marketplaces is whether the Platform or the Seller is acting as the “Merchant of Record”. The “Merchant of Record” appears on the customer’s bank account statement, is responsible for paying the payment fees, and is generally responsible for refunds, disputes, and chargebacks.
If you are in a Complex Marketplace scenario, then your app is likely the Merchant of Record. Your app will need to make sure you have ways of issuing refunds (and manually collecting funds to cover a refund from your sellers if applicable), providing customer support, and handling payment issues including disputes and chargebacks. These are all your app’s responsibility - not the sellers using your platform.
As the guitarist app has gotten more complex, it’s transformed from being musicians interacting with their patrons to the app itself connecting patrons and musicians and concert venues. When a customer buys a ticket, it shows up on their credit card statement as a purchase not from the artist but from the app. When a customer has to cancel their tickets, the app is responsible for orchestrating the refund process.
When implementing this in your Bubble application with Stripe, you’ll start by creating the Stripe Account for your sellers in either Express (simpler) or Custom (harder) mode. Stripe’s documentation will show you how to structure the API calls in your API Connector. If you’re using another marketplace-enabled platform, then check that platform’s documentation for details of how the Merchant of Record functionality works. For instance, with Dwolla, the Merchant of Record is always your platform.
Peer-to-Peer Payments
Peer-to-Peer payments are characteristic of funds moving from Person A to Person B, generally without a good or service being sold (i.e. neither Person A nor Person B are really merchants that are selling something). Classic examples include Venmo and Zelle, which are commonly used for things like splitting bills at restaurants.
Stripe does not support this business model. Instead, you’ll need to look at another payment provider - in the US, Dwolla has proven to be a leader in this area. If you’re in Europe, you have access to a network of Payment Initiation providers for instant bank transfer payments that support Peer to Peer payments including Plaid or Tink. There are some plugins available for this functionality already, and more are in the pipeline.
This would show up in the guitarist app if, for instance, I could organize a group of friends to purchase tickets together, and then enable my friends to pay me back directly within the app.
Restricted Business Types
Payments platforms and the banks that back them have limitations on the kinds of businesses they will support. These limitations can be for regulatory, technical, or risk tolerance reasons.
Stripe in particular has a list of businesses they cannot support. They also have a list of business types, including many financial, travel, and medical use cases, that require special dispensation to use Stripe’s platform. You can find their current guidance here. In my experience, if Stripe flags your account as potentially being risky or in a restricted business category, it can be exceptionally difficult to have it re-enabled.
If Stripe cannot support your use case, you’ll need to look elsewhere. I have been impressed by Dwolla’s ability to work with businesses and figure out how to support their use case - however, they only support ACH payments in the US. There are multiple other payment providers that you can easily integrate into Bubble, but the existing plugin ecosystem for those providers is limited and you’ll need to invest in the integration yourself.
Holding Customer Funds - Digital Wallets
All of the use cases described above assume that a Customer is purchasing a good or service from a Seller. In fintech, there are increasingly use cases where you collect funds from a customer and hold them on their behalf before transferring them to a third party or back to the customer. In such a case, there is no “Seller” - your app acts as an intermediary for your customer and hangs onto their funds. For instance, if your app lets users save money a little at a time throughout the month to pay a bill at the end of the month.
In the guitarist app scenario, this could look like a service to help the musician purchase a new instrument by holding onto 5% of their proceeds until they’ve saved enough to buy the new drum set.
This isn’t a standard payment scenario. The funds your platform is collecting aren’t “yours” - they still belong to your customer until you pay the bill on their behalf or return the funds. This ability for a Customer to keep a balance of funds on your platform is an emerging use case that very few payment providers facilitate (Stripe does not). The leader in this area is Dwolla, which can hold balances for your users in a Digital Wallet.
Banking
Most financial services go beyond what Payments tools can work around with features like digital wallets. For instance, if your use case involves lending, investing, or providing other banking services, then the tools Payments providers offer are only a tiny piece of the puzzle. You’ll need to partner with a Banking as a Service (BaaS) provider or obtain a banking charter. A deeper dive into Banking as a Service (BaaS) is beyond the scope of this guide.
Other Considerations
We’ve covered many vital considerations and use cases related to adding Payments to your Bubble app. It hasn’t been exhaustive. Here are a few other questions and features to consider as you design your Payments experience.
- Do you need to support alternate payment methods like Paypal, GooglePay, ApplePay, Web3 currencies, or Buy Now Pay Later solutions? Payments platforms like Stripe can help with this - though the implementation can get technical.
- Do you need an automated solution to collect sales tax on your platform? Stripe has a Tax product that can help with this.
- Consider internationalization - what is your platform’s native currency, and how do international transactions work? Again, Stripe has a complete feature set related to this.
- For marketplaces, how does your Payments platform support your tax requirements related to income reporting for your sellers? Stripe offers tax form features.
Disclosure: Lost Sheep Advisory is a referral partner of Dwolla.
