Powstania Warszawskiego 15
31-539 Kraków
Payments blueprint
How to add payments to your app is rarely a coding question. It is a set of business decisions about what users pay for, who takes a share and what happens when something goes wrong. This blueprint walks through those decisions in the order we settle them with founders, before a single payment screen is built.
Short answer
To add payments to your app, first decide what users pay for. Digital purchases used inside the app, such as subscriptions or premium features, usually go through Apple and Google in app purchases, which take a commission. Real world services and goods, such as training sessions, deliveries or tickets, go through your own payment provider, for example Stripe. Then pick the model, set up the accounts in your company's name, plan refunds and cancellations, and test every payment scenario before launch. A subscription purchase typically takes three to four weeks to build and test, and a marketplace with payouts to providers takes longer.
Key takeaways for founders
From the user's side, paying in an app looks simple. One tap and it is done. That is why many founders assume adding payments is a quick add on at the end of the project. In practice, the first decision has nothing to do with code: what exactly is the user paying for?
Digital purchases used inside the app usually have to go through Apple and Google in app purchases. Real world services and goods go through your own payment provider, such as Stripe, or another provider that fits your market and the payment methods your customers expect.
We see two opposite mistakes. Some founders plan to send a real world service through Apple and Google, which they should not. Others plan to take every payment with their own provider, including digital content that the stores expect to go through their system. Both mean reworking part of the app later.
The most common surprise: Apple and Google take a commission on in app purchases, and many business plans simply do not include it.
For most apps the store commission is between 15 and 30 percent of each digital purchase, depending on the program and the type of purchase. Some markets now also allow your own checkout for digital purchases, with different rules and fees. We broke the numbers down in our article on in app purchase fees. The point here is simpler: the fee has to be in the plan before you set your prices.
Most apps our clients build earn through a subscription or by selling something inside the app. Marketplaces, where one user pays another, are less common but far more demanding. The three models look like this:
Whatever the model, in about 60 percent of our projects it changed at least a little during the build. Not because founders plan badly, but because these mechanisms are rarely explained until the team starts asking detailed questions. The earlier those questions come, the cheaper the changes.
Use RevenueCat instead of building store payments from scratch. For apps built with Flutter or React Native, RevenueCat sits between the app and the stores. It speeds up development noticeably, which lowers the cost of the first version, and it handles a lot that would otherwise be custom work:
It is free up to a certain level of revenue and then takes a small share, and it adds one more service the app depends on. For most first versions that trade is clearly worth it.
Make the paywall dynamic. In the fitness app we built for Body Vibes, the paywall reads its prices and plans from the backend, where the owners change them themselves. If prices are written into the app, every change needs a developer and a new release in the stores, which slows the business down at exactly the moment it is testing what sells. This is a decision to make before the build, not after launch.
Some of the work cannot be done by the development team, because the accounts have to belong to your company. These are the things we ask founders to prepare:
On the founder's side
Start these early. Account verification can take a while on its own, and setting up Stripe properly is more time consuming than founders expect. When they wait until the last weeks, the payment flow is ready but cannot be tested with real accounts.
In a marketplace, one payment has to work for three parties. The customer pays, the provider gets paid and the platform keeps its share. On Domedo, a platform we built for physiotherapy home visits, the payments run on Stripe Connect, a Stripe product made for exactly this.
Without it, there is no safe way to send money from customers to providers. And around every payment there is a long list of things that are easy to forget: refunds, cancellations, partial refunds, failed payouts. Stripe handles them as standard, which gives the founder something worth more than any feature: peace of mind.
Three things about marketplace payments regularly surprise founders:
Our position is simple: payments are the one part of an app you cannot rush. Every scenario has to be thought through before the app reaches your customers, because a mistake here does not look like a bug. It looks like lost money and lost trust.
In one app we worked on, invoices for customers were generated incorrectly and prices for products were calculated wrong. Both hit the client's business directly, long before anyone noticed it in the code. These are the scenarios we make sure every payment flow has an answer for:
Refunds deserve the most attention. Write the cancellation policy before the build, and keep a way to issue refunds by hand when a situation falls outside it. Stripe makes this part much easier, with full and partial refunds available as standard.
AI can write the code for payments. Someone still has to make sure it works in production the way the AI promised.
That is the real difference today. Writing payment code is faster than ever. A carefully thought out business model, and the confidence that every case behaves as planned, still depends on the people behind the app.
Payments are tested long before a real card is charged. We work in three layers:
After launch, the dashboards of Stripe and RevenueCat become one of the founder's most useful tools. They show where the money is, and they help plan the next moves with three numbers:
A feature like buying a subscription takes about three to four weeks, including end to end tests. A marketplace with payouts to providers, verification and invoices takes longer, often more than a month for the payment part alone. That is one of the main reasons advanced payments extend the timeline of a first version, as we described in how to plan a mobile app.
We keep prices out of articles, but our pricing page explains how first versions are priced.
Work out the monetization model with every commission included: Apple and Google for digital purchases, and your payment provider for everything else. Then check that the numbers still leave you a profit. That is the point of adding payments in the first place, and it is far easier to adjust on paper than in a finished app.
Here is how much the commission changes the math, before taxes:
Same app, two very different margins. If your model only works at the full price, it is better to find out now than after launch.
Before you brief a development team, check that you can tick every line. Gaps are fine, they show what to settle first.
Payments blueprint
No. Digital purchases used inside the app, such as subscriptions, premium features or in game items, usually go through Apple and Google in app purchases. Real world services and goods, such as training sessions, deliveries or tickets, go through your own payment provider, for example Stripe.
For most apps between 15 and 30 percent of each digital purchase, depending on the program and the type of purchase. The details are in our article on in app purchase fees.
RevenueCat is a service that connects your app to Apple and Google subscriptions through one integration. It speeds up development, handles renewals and cancellations, and gives you revenue analytics. For most subscription apps built with Flutter or React Native it is the faster choice.
The customer pays through a payment provider built for marketplaces, such as Stripe Connect. The payment is split between the provider and the platform, and the provider receives a payout. Providers are verified before their first payout, which keeps every transaction safe.
A registered company with a business bank account, a Stripe account in the company's name, the Paid Apps Agreement in App Store Connect, a payments profile in Google Play, and terms of use that cover renewals, cancellations and refunds.
About three to four weeks for a feature like buying a subscription, including end to end tests. Marketplace payments with payouts, verification and invoices take longer, often more than a month.
Written by
Thomas Siudut
Co-Founder and CEO, Apps Value
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Planning payments for your app?
If you are working out how your app should take payments, we are happy to look at it with you. We will go through the model, the fees and the cases worth planning before the build.
19+ projects delivered · 6 years building apps · 13+ positive client reviews
