Payments

What you can charge for in a phone app today, what the stores forbid, and the workarounds that actually work.

What you can charge for in a phone app is decided by Apple and Google, not by Mistflow. The rule is simpler than it looks.

The rule

What you sell	How you take payment
Physical goods, and services delivered in the real world	Your own checkout. Both stores allow this
Digital content and subscriptions used inside the app	The store's own billing. Both stores require this

Ecommerce, marketplaces, food delivery, bookings, classes, and tickets fall on the first line. Premium tiers, ad-free upgrades, coins, and unlockable content fall on the second.

Physical goods and services: supported. Your app opens a hosted checkout, the person pays, and the app confirms the purchase with your server before unlocking anything. This works on both platforms today, through one path.

People pay for the class when they book it

Digital subscriptions are not supported in phone apps yet

Apple and Google require their own billing for digital goods, and the standard library for that has open crash bugs on the platform version we ship. Wiring it in would mean shipping an app that crashes. If you ask for paid digital content in a phone app, you are told rather than handed something that cannot ship.

If you want to charge for digital content

Three options that work today:

Charge on the web. Sell the subscription on your app's website and have the app recognise the account. This is what many apps do, and it is allowed as long as the app does not link out to it
Launch free, charge later. Get the app in people's hands, add paid tiers when store billing is available
Reframe what you sell. If the thing being paid for is a real-world service, it belongs on the first line and can use ordinary checkout

Confirming a purchase correctly

One detail decides whether people get charged without receiving what they paid for.

The app knows when the checkout window closed. It does not know whether money moved. Those are different events, and only your server, hearing from the payment provider, knows the second one.

So access is granted when your server confirms the payment, never when the browser comes back. Someone who closes the window early does not get access; someone whose payment succeeds gets access even if their phone died on the way back. This is built the correct way by default, and it is worth knowing so you do not ask for it to be "simplified".

Testing payments

Test on a real installed build, not the in-browser preview
Test the cancel path: open checkout, close it without paying, confirm nothing was unlocked
Test the slow path: pay, then kill the app before it returns. Access should still arrive
Test a refund if your provider supports it, and decide what your app does about access

What you need

A payment account of your own. Mistflow does not process money for your app or take a cut of it. Fees, payouts, taxes, and disputes are between you and your provider.

Not supported

In-app purchases and subscriptions through the stores
Native payment sheets (Apple Pay and Google Pay inside the app)
Marketplace payouts splitting money between multiple sellers automatically