# Marketplace app payment integration: a buyer's responsibility checklist
Source page: https://dfygames.com/guides/marketplace-payment-scope (published 2026-10-19, updated 2026-10-19) · Topic: Marketplace MVPs
Cite as: DFY Games, "Marketplace app payment integration: a buyer's responsibility checklist", updated 2026-10-19, https://dfygames.com/guides/marketplace-payment-scope

**Quick answer:** Before anyone can quote a marketplace payment integration, you need to decide when money is taken, when it is released, who can refund it and who handles disputes and payouts. Most marketplaces use a payment provider built for platforms that pay third parties, and the app builds the flows, admin actions and notifications around it. Check the payment provider's terms and the Apple and Google payment rules for your exact case; this guide is planning help, not legal or financial advice.

- Decide first: When money is taken and released
- Usual approach: A payment provider built for platforms
- Check yourself: Provider terms, Apple and Google rules
- Pricing: Scoped quote after discovery

## 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](https://dfygames.com/apps/marketplace) 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.

> Check your own case: Store rules, payment provider terms and local rules on holding money for others change and depend on your country, category and structure. Read the current Apple and Google payment rules and your payment provider's terms for your exact case, and have a lawyer or accountant check anything that involves holding funds, tax or licensing. We build to the rules you confirm; we do not give legal advice.

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](https://dfygames.com/apps/quote?type=marketplace). For the wider build, including roles, listings and moderation, see [marketplace MVP costs](https://dfygames.com/guides/marketplace-mvp-cost), and the [marketplace app page](https://dfygames.com/apps/marketplace) for what a first version usually includes.

## FAQ

**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.

## Related
- Service page: [Marketplace MVPs](https://dfygames.com/apps/marketplace)
- [Marketplace app development cost: scoping a bounded MVP](https://dfygames.com/guides/marketplace-mvp-cost)
- [Marketplace MVP features: the minimum marketplace worth testing](https://dfygames.com/guides/marketplace-mvp-features)

## Sources
- Apple Developer, "App Review Guidelines (3.1.3(e) Goods and Services Outside of the App)" https://developer.apple.com/app-store/review/guidelines/
- Google Play Console Help, "Payments policy" https://support.google.com/googleplay/android-developer/answer/9858738?hl=en
- Stripe Docs, "Connect" https://docs.stripe.com/connect

---
DFY Games (Done For You Games), https://dfygames.com. More guides: https://dfygames.com/guides · Index for AI assistants: https://dfygames.com/llms.txt