In-app payments: what the store takes, and when you can charge outside it

Charging inside a mobile app is not the same as charging on the web. Not because of the technology, but because of the rules: app stores impose their own purchase system for certain kinds of product, and that system costs far more than any gateway.

The dividing line: digital content or the real world

Simplifying heavily, the rule separates two cases:

• Digital goods and services consumed inside the app (feature subscriptions, virtual currency, unlockable content): the stores require their in-app purchase system.
• Physical goods, or services delivered outside the app (a food delivery order, a booking, an in-person class, a ticket): you can charge for them with your own gateway, just like on the web.

That distinction is why a food delivery app can take a card payment without going through the store, while a productivity app has to sell its paid plan through in-app purchase.

What the store takes

The exact terms change often, so always check the current ones in each store's documentation before setting prices. The usual brackets have been:

• A standard commission around 30% of the purchase.
• A reduced commission around 15% for developers below a certain annual volume and, for subscriptions, from the second year of the same subscriber's retention.

Beyond the percentage, two effects are easy to forget: the store charges on the tax-inclusive price, and it pays out on its own schedule, which is not your gateway's.

What changed in Europe

European digital markets regulation has forced the system open in the European Union: link-outs to your own payment, alternative stores, and other distribution routes. The commercial terms attached to those alternatives have kept changing and differ between platforms, so leaving the store's system is as much a commercial decision as a technical one: run the numbers with today's fees and your real volume, not with a headline.

Sell on the web, unlock in the app

When the product does fall under in-app purchase but you want to cut the cost, the usual route is to sell the subscription outside the app — on your website — and have the app simply check whether the user has access. At that point the fee becomes an ordinary gateway fee, which you can compare on the pricing page. In exchange, the customer pays in a browser, with the conversion cost that implies, and how you communicate that option inside the app is subject to each store's rules.

The access grant lives on your server

Wherever the money is taken, keep two things apart: the purchase (a payment, with its receipt) and the access grant, what the jargon calls an *entitlement*. The app should not decide on its own whether a user is paying: it should ask your server and get back a list of active grants and their expiry.

Doing it this way solves several classic problems at once:

• The user switches phone or reinstalls and keeps their access.
• They buy on mobile and use the service on the web with the same account.
• You grant access manually for support, a promotion, or a trial, without touching the store.
• An expired or refunded receipt removes access without shipping a new app version.

It is the same model as the payment flow described in what actually happens inside a card payment: the payment is an event, the state is what you query.

Common mistakes

• Tying the grant to the device or store identifier instead of the user account. It breaks the moment there are two platforms.
• Not keeping a history of grants: when a customer disputes something, there is no way to know what they had and until when.
• Forgetting refunds: the store can return the money without your system noticing if you don't process its notifications.

In short

Before integrating anything, place your product on the map: what you sell, where it is consumed, and what fee each route implies. Then separate purchase from grant, and store the grant somewhere you can query and correct it. You can see how all of this looks in a dashboard with sample data in the demo, or keep reading the articles on in-app payments.