Powstania Warszawskiego 15
31-539 Kraków
In a marketplace or booking app, the payment is where the product, the App Store rules and your business setup meet. Decide them in the right order and payments are a few weeks of work. Decide them late and the app waits in review while you explain your business model to Apple.
Most marketplace and booking apps can take payments through a provider such as Stripe instead of Apple's in app purchase, because they sell services or goods used outside the app. In app purchase is required for digital content and features used inside the app, such as premium subscriptions. The payment design has four parts: who the seller is, when money is taken, how providers are paid out, and what happens on cancellation. Review may still ask about the model, so prepare a short explanation and a test account before submitting.
Apple's guidelines separate payments by what is being bought, not by what kind of app it is. A single marketplace can fall under two rules at once.
A cleaning booked through the app, a repair, a session with a trainer at the gym, a delivered product. Guideline 3.1.3(e) requires a payment method other than in app purchase.
Live one to one sessions delivered through the app, such as tutoring or a video consultation. Guideline 3.1.3(d) allows payment methods other than in app purchase. One to many sessions, and answers delivered later rather than live, must use in app purchase.
Premium features, subscriptions to the app itself, credits spent in the app. These go through Apple, with the commission explained in our guide to in app purchase fees.
The mixed case is common. A booking marketplace takes session payments through Stripe, then adds a premium plan that unlocks features inside the app. That plan usually goes through in app purchase, while the bookings do not, so the two flows are built and reviewed separately. In the United States, apps may also link out to web checkout for digital purchases since 2025.
The real time rule is the one that decides the business model of expert platforms. A live video consultation with an advisor or a coach can be paid by card, while a paid question answered in writing the next day has been treated by Apple as digital content that must use in app purchase. How we map every paid action against these rules for platforms where clients book advisors, consultants or coaches is on our professional services marketplace app development page.
Apple reviews the app, not your pitch deck. When a reviewer sees money moving outside in app purchase, they check whether it should have gone through Apple. We have met this question on marketplace and booking projects, and each time it was resolved by explaining the model. It is a predictable step, not a crisis.
Two things shorten it: review notes that say in plain words what is sold and where it is used, and a test account with a completed booking the reviewer can open. The other delay we see is simpler. The client's Apple developer account is opened and configured too late, and setting it up is not a quick task, so it belongs in the first week of the project.
Every marketplace or booking payment passes through the same four moments. The product decisions sit between them.
At booking, as a deposit, or after the service. This choice shapes your cancellation logic.
The card is authorised or the money is held until the service happens.
The platform keeps its fee and the rest is assigned to the provider.
The provider is paid to their bank account after verification.
Marketplace products such as Stripe Connect handle provider verification, split payments and payouts, so the app never stores card data or moves money itself. What the app still has to define is the business rules around those moments, and that is where most of the scope sits.
A quote for payments without these answers is a guess. Each one changes screens, backend logic and the payment provider setup.
Does the platform sell the service and pay providers, or connect customers with providers who sell directly? This changes invoices, taxes and how the payment provider is configured. The tax side is a question for your accountant, and it is worth asking early.
At booking, as a deposit, or after the service. Each option handles changes, failed cards and expired authorisations differently.
Cancellation windows, no shows, partial refunds and who carries the platform fee on a refund. Write the policy before the screens are designed.
Instantly, weekly or after a holding period, and what each provider must supply to be verified before the first payout.
It sounds wrong for a marketplace, but it is often the right call. Loopy Jobs, the specialist marketplace we built in Flutter on a Supabase backend, launched its first version with the core of the product: two user types, search and a booking system built on the backend. Automated payments, company profiles and subscriptions were planned for version two.
Deferring payments lets the first version prove that both sides actually use the platform before you build payouts, refunds and disputes for transactions that may not happen yet.
When payments are part of the product from day one, they belong in version one and the scope grows with them. In EveSport, the trainer booking platform we built, Stripe payments were part of the first release, because paid sessions were the product.
If your model matches a standard booking or marketplace tool, one type of provider, simple cancellation rules and no split payments, a subscription product will cost less than a custom app.
Custom makes sense when the payment rules are part of how you compete: deposits that depend on the provider, commissions that vary, payouts tied to completed work. The signals are covered in when to build custom booking software, and how we build these products is on our marketplace app development and booking app development pages.
Not for services or physical goods used outside the app, such as a booked appointment or a delivered product; those use your own payment provider. In app purchase applies to digital content and features used inside the app.
Yes, when the booking is for a service delivered outside the app. Apple's guideline 3.1.3(e) requires a payment method other than in app purchase in that case.
Not when they are live and one to one, such as a video session with an advisor or a coach, which guideline 3.1.3(d) allows to be paid by card. One to many sessions and paid answers delivered later must use in app purchase. More on professional services marketplace app development.
Usually through a marketplace payment product such as Stripe Connect, which verifies each provider, splits every payment between the provider and the platform fee, and pays providers out to their bank accounts.
Reviewers check whether money moving outside in app purchase should go through Apple. A clear explanation of what is sold and where it is used, plus a test account with a completed booking, usually resolves it.
Only if the product depends on them from day one, such as deposits that protect a provider's time. Otherwise a first version can prove demand first and add automated payments in version two.
Typically two to three weeks of work for a standard marketplace or booking flow, plus time for store review. Complex refund, deposit or payout rules add to that.
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.
Walk us through who pays whom, and when. We will tell you what Apple is likely to ask, what the payment provider handles, and whether payments belong in your first version.
30 minutes, no preparation needed.