Why payments need decisions before a quote
Taking a card payment is a solved problem. Taking a payment on behalf of someone else, keeping a fee, holding the rest until a job is done and paying it out is a set of business rules. A developer can build any of those rules, but cannot choose them for you, and each one changes the screens, the payment states and the admin tools.
This guide is a checklist of the decisions and ongoing jobs that stay with you as the buyer and operator. It does not explain payment provider APIs; once your answers are written down, connecting to the provider is the developer's job and part of the marketplace app development scope.
Marketplaces usually rely on a payment provider product made for platforms. Stripe, for example, describes its Connect product as being for platforms and marketplaces that need to move money between multiple parties. Products like this handle seller onboarding, identity checks and payouts on the provider's side, so the app does not store card or bank details itself. What remains is your logic: when to charge, when to release, how to refund.
A responsibility map for refunds, disputes and payouts
Fill this in for your own marketplace before you ask for a quote. The "typical lean choice" column is a common starting point for a first version, not a recommendation for every business.
| Event | Questions to answer | Typical lean choice | What the app builds |
|---|---|---|---|
| Charge | Charge at request, at acceptance or after completion? Deposit or full amount? | Full amount authorized or charged at request | Checkout screen, payment status on the order |
| Platform fee | Percentage, flat fee or both? Paid by buyer, seller or split? | One percentage taken from the seller's share | Fee calculation, fee shown on receipts and earnings |
| Payout | Released on completion, after a waiting period or on a schedule? | Released when the order is marked complete | Completion action, payout status for the seller |
| Cancellation by buyer | Free until when? Fee after that? | Free before acceptance, no cancellation after | Cancel button with rule check, automatic refund |
| Cancellation by seller | Always a full refund? Any penalty for the seller? | Full refund, admin notified | Decline action, refund trigger, admin alert |
| Refund request | Who decides: seller, your team or automatic rules? | Your team decides from the admin panel | Report form, admin refund action, notifications |
| Partial refund | Needed in version one? | No, full refunds only | Amount entry and recalculated fees (if yes) |
| Card dispute (chargeback) | Who responds to the card network with evidence, and who absorbs the loss? | Your team responds through the payment provider's dashboard | Order record that shows what happened and when |
| Seller onboarding and checks | Which identity checks? Who approves a seller? | Provider's hosted onboarding plus manual approval | Onboarding link, approval queue |
| Tax documents and invoices | Who issues receipts or invoices, and in whose name? | Provider receipts; accountant advises on the rest | Receipt emails, export of orders |
Each row you change from the lean choice adds work. Partial refunds and deposits are the two that grow the build fastest, because every order screen and admin action has to understand more states.
Store and payment provider rules to verify yourself
Apple and Google have rules about which payments must use their in-app purchase systems. Apple's App Review Guidelines (section 3.1.3(e)) say that apps selling physical goods or services consumed outside the app must use payment methods other than in-app purchase, such as Apple Pay or card entry. Google Play's payments policy likewise says its billing system must not be used when the payment is primarily for physical goods. Most service and goods marketplaces fall on that side. Digital goods sold inside the app usually do not.
Payment providers also restrict some business categories and require you, as the platform, to accept their platform terms. Read those before you design the flow around one provider.
The admin and operations work behind every payment
Every row in the responsibility map ends with someone on your team doing something. The admin panel is where that happens, and its scope follows directly from your answers.
| Task | Who does it | Admin tool needed |
|---|---|---|
| Approve a new seller | Operations | Queue with profile, documents status, approve or reject |
| Find an order from a support email | Support | Search by email, order number or name |
| Refund an order | Support or owner | Refund button with reason, notification to both sides |
| Pause a problem seller | Owner | Suspend action that hides listings and blocks new orders |
| Answer a chargeback | Owner | Order timeline to copy into the payment provider's dashboard |
| Check the month's fees | Owner or accountant | Order export or a simple totals view |
If one person runs everything at the start, a single admin role is enough. Separate support and owner roles become worth building when you hire your first support person.
Questions to answer before you ask for a quote
Buyer responsibility checklist
- Which payment provider will you use, and is the account in your business's name?
- Are you selling physical goods, in-person services or digital goods?
- When is the buyer charged, and when is the seller paid?
- How is your fee calculated, and who pays it?
- Which cancellations are free, and who can issue a refund?
- Do you need partial refunds, deposits or tips in version one?
- Who on your team handles disputes and chargebacks?
- Which countries and currencies do you need at launch?
Jobs that stay with you after launch
- Keeping the payment provider account verified and in good standing
- Approving or pausing sellers
- Deciding refund requests that the rules do not settle automatically
- Responding to chargebacks with the order record
- Checking fees and payouts each month with your accountant
- Re-reading provider terms and store payment rules when they change
Answers to these, plus the transaction you want to support, are enough for a meaningful scope. Send them through the scoped quote form. For the wider build, including roles, listings and moderation, see marketplace MVP costs, and the marketplace app page for what a first version usually includes.
Frequently asked questions
Do marketplace apps have to use Apple or Google in-app purchase?
Not for physical goods or services used outside the app, according to both stores' current payment rules. Digital goods consumed in the app are different, so check the current rules for your case.
Does the app store card or bank details?
With a platform payment provider, no. The provider collects and holds card and bank details, and the app stores references and order states.
Who handles chargebacks?
You, as the platform, usually respond through your payment provider's dashboard. The app helps by keeping a clear order timeline you can use as evidence.
Can I add partial refunds later?
Yes. Starting with full refunds only keeps the first version simpler, and partial refunds can be added once you see how often they are needed.
Whose name is the payment account in?
Yours. Developer, hosting and payment accounts stay in your business's name, which also keeps payouts and disputes under your control.
Is this legal advice?
No. It is planning help for a scope. Have a lawyer or accountant review anything involving holding funds, tax or licensing in your country.
Sources
- Apple Developer, App Review Guidelines (3.1.3(e) Goods and Services Outside of the App)
- Google Play Console Help, Payments policy
- Stripe Docs, Connect
Written and reviewed by the DFY Games team. Published ; facts checked . Prices and store rules change: check the linked sources before you rely on a figure.