samber/developer-platform-skillsチェック済み
SKILL DETAIL
app-marketplace-monetization-model
samber/developer-platform-skills/app-marketplace-monetization-model
Design how a B2B SaaS app/connector marketplace makes money, operator side - merchant-of-record posture (marketplace-billed vs developer-billed), billing rails and account configuration, the fee stack (revenue share collected at source, program fees, processing pass-through), fee waivers and incentive tiers, payout cadence and hold windows, and the marketplace-facilitator/VAT tax layer. Use whenever the user mentions charging for apps, rev-share collection, paid-app billing or billing APIs, developer payouts, fee waivers, or merchant of record - even if they never say "marketplace monetization". Mechanics layer only. Do NOT use for take-rate level and tiers - use samber/developer-platform-skills@connector-marketplace-strategy instead.
インストール · 330出典を見る
Installation
npx skills add https://github.com/samber/developer-platform-skills --skill app-marketplace-monetization-model
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "app-marketplace-monetization-model",
"evals": [
{
"id": 1,
"prompt": "I run platform partnerships at Calvetta, a B2B scheduling and ops SaaS with around 900 mid-market customers. We have 310 free connectors in our integrations directory today and we take nothing on any of them. Leadership wants paid apps live by Q2 and told me \"take 20%, maybe 25%, we'll land on it later, just go build the billing.\" Nothing else has been decided. Write me the monetization design.",
"expected_output": "A run that refuses to invent the take-rate, routes the level/tier decision to the strategy layer, fixes merchant-of-record posture as the first decision, notes developer-billed is the right default only while the rate is zero and states the promotion condition, and runs the interview one question at a time including the deadline, durability and effort-ceiling questions.",
"files": [],
"expectations": [
"States that the take-rate level and tier architecture is not decided by this design and must be settled first",
"Names samber/developer-platform-skills@connector-marketplace-strategy as where the take-rate level and tier decision belongs",
"Does not adopt, endorse, or build the design around 20% or 25% as the rate",
"Identifies the merchant-of-record posture as the first decision, from which tax liability, chargeback ownership, offerable pricing models, and payouts all follow",
"States that while the take-rate is zero the default posture is developer-billed (vendor-as-MoR), because there is no cut to collect and collection machinery buys nothing",
"States the promotion condition explicitly: the moment a non-zero take-rate is charged, promote to marketplace-billed (platform-as-MoR)",
"Justifies marketplace-billed by collection at source being the only mechanism that does not depend on developer self-reporting",
"Asks interview questions one at a time rather than delivering a batch list or assuming the answers",
"Asks whether Calvetta already bills these end customers on a recurring invoice or settlement cycle for its core product",
"Asks the hard-date, one-off-unlock-versus-compounding-asset, and effort-ceiling questions, and states that a hard date promotes managed rails and the simplest posture",
"Sequences the work so the merchant-of-record posture is validated before the fee stack, payout design, and tax map are drafted"
]
},
{
"id": 2,
"prompt": "Quick sanity check. We're a B2B data-quality platform, our app marketplace launches next month, and we've settled on developer-billed: each app vendor charges the customer directly on their own processor and we invoice them our 12% quarterly based on what they report. So tax is entirely theirs, right? For context, buyers sit in 22 US states and five EU countries, and roughly 12% of our seats go to one-person consultancies buying as individuals. I want one line in the developer agreement saying vendors are responsible for all taxes.",
"expected_output": "A run that answers no, explains that facilitator and deemed-supplier obligations attach by law regardless of billing posture, replaces the blanket clause with a published jurisdiction-by-jurisdiction split, separates tax status from card-network merchant of record, routes through counsel, and flags the self-reported 12% as the weakest enforcement position.",
"files": [],
"expectations": [
"Answers no: marketplace-facilitator and deemed-supplier obligations can attach to the platform by law regardless of who bills the customer",
"Names US marketplace-facilitator statutes and ties them to the 2018 South Dakota v. Wayfair economic-nexus decision",
"States the US facilitator framework is state-by-state rather than federal, with variations such as excluded local taxes or continuing seller informational returns",
"Names the EU deemed-supplier rule (Article 14a of the e-commerce VAT package, in force since 1 July 2021) treating the electronic interface as having bought and resold the supply",
"States the EU deemed-supplier rule attaches to B2C supplies specifically, making the individual-buyer share a tax-design input rather than demographic trivia",
"Notes B2B cross-border EU supplies are typically reverse-charged to the business buyer, so the business-buyer portion is a lighter version of the layer, not an exemption",
"Rejects the single blanket clause that vendors are responsible for all taxes as the deliverable",
"Specifies the deliverable as a published split naming which tax, which jurisdiction, and whose obligation, rather than a binary toggle",
"States that marketplace-facilitator or deemed-supplier status is tax law while merchant of record is card-network status, and that the two are legally distinct and do not always coincide",
"Warns that marketplace sales may still count toward a seller's own nexus thresholds or filing obligations even where a platform remits",
"States this is not tax advice and routes the published split through qualified counsel before shipping",
"Flags that collecting 12% from developer-reported figures means the platform learns its own revenue from the payer, and pairs it with an anti-circumvention rule backed by a delisting path"
]
},
{
"id": 3,
"prompt": "Engineering question on our marketplace build. We're on Stripe Connect. The plan: destination charges so our name is on the customer's statement, losses_collector set to stripe so we aren't eating chargebacks, full Stripe dashboards for each app vendor so they can self-serve refunds and see their own data, and we hold every sale 45 days before releasing the vendor's share. Platform fee comes out via application_fee_amount. Anything we should tighten before we ship?",
"expected_output": "A run that rejects the à-la-carte dial combination, explains that non-direct charge patterns require the platform to carry losses, names the two coherent bundles, states destination charges cannot implement a 45-day hold and that separate charges and transfers are required, warns off on_behalf_of, and raises per-active-developer rail costs.",
"files": [],
"expectations": [
"Flags the combination as invalid: a non-direct charge pattern requires the platform to carry losses, so destination charges with Stripe as loss collector is blocked or silently shifts liability back to the platform",
"States the account dials (dashboard access, fee collection, loss liability) collapse into two coherent bundles rather than being freely mixable",
"Names the marketplace-shaped bundle: express dashboard, platform collects fees, platform carries losses, destination or separate charges",
"Names the SaaS-shaped bundle: full dashboard, Stripe bills the developer, Stripe carries losses, direct charges only",
"Flags full-dashboard access as belonging to the SaaS-shaped bundle and inconsistent with the destination-charge, platform-as-MoR intent",
"States destination charges pay the connected account on payment success and therefore cannot implement a hold-and-release model",
"Prescribes separate charges and transfers as the pattern required for delayed, gated, or split payouts",
"States the charge pattern is what technically determines merchant of record: direct charges make the developer MoR, destination and separate charges make the platform MoR",
"Warns against using on_behalf_of for marketplace use cases because it keeps the charge on the platform while making the developer merchant of record",
"Instructs picking a whole bundle rather than dials à la carte, naming the failure mode as the platform carrying dispute losses it believed it had pushed to developers",
"Requires the 45-day hold to be sized against actual refund and chargeback exposure and published as part of an end-to-end sale-to-bank timeline",
"Raises the per-active-developer cost of the managed marketplace bundle (per-account monthly fee plus fixed and percentage per-payout fees on top of processing) and says to model unit economics per active developer, not per transaction"
]
},
{
"id": 4,
"prompt": "We publish our marketplace pricing-model menu to partners on Monday. The launch deck promises vendors can sell flat subscriptions, per-seat, metered usage, and one-time add-ons. Our checkout is the one that shipped with our commerce vendor: it does subscriptions and one-time purchases, plus coupons and free trials. Our head of partnerships also wants every vendor forced to offer a 14-day free trial, and we were going to list each plan as price variants under a single product so the catalog stays tidy. Sanity-check the plan.",
"expected_output": "A run that blocks the metered promise until the checkout is verified, states the rails cap the menu rather than the reverse, notes platform-as-MoR does not itself rule out metered billing, rejects price-variants-under-one-product and the mandated trial, and names the entitlement and reporting systems left unspecified.",
"files": [],
"expectations": [
"Blocks publishing metered or usage-based pricing until the checkout is confirmed to support it",
"States the rails cap the pricing menu rather than the menu driving the rails choice",
"Identifies the promised metered tier as unsupported by the described checkout and requires either removing it from Monday's menu or changing the rails first",
"States the verification order explicitly: verify each promised model against the rails before publishing the menu to developers",
"Notes that a marketplace-billed posture does not by itself rule out usage-based billing, citing a platform-as-merchant-of-record marketplace that supports metered billing natively",
"Treats usage-based pricing as a maturity ladder (simple metering versus dimensional, contract-grade metering) and scopes which rung vendors actually need",
"Rejects modeling plan tiers as price variants of one product and requires each tier to be modeled as its own product object",
"Gives the reason: variants of one product become indistinguishable on customer invoices",
"Rejects mandating the 14-day free trial, and recommends the marketplace recommend defaults such as trials or an entry plan rather than mandate them",
"States the pricing-model menu is deliberately unranked because developer demand and rails capability decide it jointly",
"Notes a monetization stack is at least three systems (payment, entitlement or licensing provisioning, and partner revenue reporting) and that the checkout decision leaves the other two unspecified"
]
},
{
"id": 5,
"prompt": "Designing our small-developer fee waiver. Draft: any app vendor whose marketplace revenue stayed under $400,000 in the trailing 12 months pays 0% instead of our 15%. Vendors apply via a form in the partner portal, our partner-ops person reviews applications once a quarter, and approved waivers start the following quarter. Vendors running several apps under different company entities each get their own $400K allowance. Tear it apart.",
"expected_output": "A run that identifies the manual-enrollment defect and requires defaulting eligible developers in, challenges the threshold against the ~$1M cluster, forces an explicit annual-reset-versus-lifetime decision, closes the separate-entity aggregation gap, and specifies mid-period crossing behavior.",
"files": [],
"expectations": [
"Flags the application-and-review enrollment as the core defect: eligible developers who miss the paperwork silently pay the full rate",
"Requires defaulting eligible developers into the waiver automatically rather than making them opt in",
"States the reason: an opt-in waiver changes paper rather than behavior",
"Challenges the $400,000 threshold against the roughly $1M revenue threshold that major marketplace waiver programs cluster around, and recommends anchoring there rather than inventing a number",
"Names annual-reset versus lifetime cap as an explicit design decision to make rather than a detail",
"Notes that moving from an annual reset to a lifetime cap is a one-way tightening",
"Flags the per-entity allowance as a gap and requires associated or affiliated accounts to aggregate toward the cap",
"Requires a stated rule for what happens when a vendor crosses the threshold mid-period",
"Classifies the draft as a revenue-exemption tier and identifies that shape as the default waiver rung on efficiency grounds",
"States that fee waivers are a standard menu item across major marketplaces rather than an exceptional discount",
"Names waiver coverage among eligible developers as the post-launch metric proving the default-in rule worked, and pairs the waiver with a published notice commitment for later changes"
]
},
{
"id": 6,
"prompt": "Our developer docs currently say \"payouts are issued monthly, $25 minimum.\" Partners keep telling us cash flow is painful. We want to fix it by dropping the minimum to $10 and adding a line saying most partners get paid within 30 days. What actually happens: we close the month, run a 30-day refund window, the finance batch goes out on the 15th of the following month, and international wires take another 3 to 5 days. We're merchant of record and we bill customers in seven currencies.",
"expected_output": "A run that identifies the hold window rather than the minimum as the real cash-flow lever, computes the honest end-to-end lag and rejects the 30-day claim, offers rolling-with-reserves as the promotion and instant-for-a-fee only as a layered option, and assigns cross-border FX and rail choice to the platform.",
"files": [],
"expectations": [
"Identifies the minimum payout threshold as the wrong lever and the hold window as the one developers actually feel",
"States that marketplace payout minimums cluster in roughly the $50 to $150 range, small enough that active developers clear them every cycle, so moving $25 to $10 changes little",
"States the real end-to-end sale-to-bank lag for a sale made early in a month runs well past 60 days once month close, the 30-day window, the mid-month batch, and wire time stack",
"Rejects publishing \"most partners get paid within 30 days\" as inaccurate against the described sequence",
"Requires publishing the honest end-to-end sale-to-bank timeline in the developer docs",
"Identifies the current design as the monthly-cycle-plus-explicit-hold-window rung and sizes the hold to actual refund and chargeback exposure, noting roughly 30 to 60 days as the platform norm",
"Offers rolling payouts with reserves, a percentage held on a rolling window against disputes, as the promotion when competing for supply against faster-paying alternatives",
"Offers instant payout for a fee only as an option layered on a slower default, never as the default, because it loses every round on operator risk and cost",
"Raises invoice-cycle consolidation only on the precondition that the platform already bills these customers on an existing settlement cycle",
"States that under the marketplace-billed posture the platform owns cross-border mechanics including payout currency conversion and payment-rail choice across the seven currencies, and says to budget it",
"Adds median sale-to-bank days measured against the published timeline as a tracked post-launch metric"
]
},
{
"id": 7,
"prompt": "Two things. First, the fee schedule: we want partners to see one clean number, 18% all-in with our card-processing cost folded inside it, plus a $2,500 fee per app submission. Second, our second-largest app, 190 installs, has started putting a \"pay here instead\" link in their in-app onboarding that routes billing to their own checkout. Our partner agreement says nothing about it. How do we handle both?",
"expected_output": "A run that unbundles processing from the headline share as a separately labeled pass-through, names netting at source as the collection mechanism, separates the flat instruments, treats the external billing link as a terms violation needing an anti-circumvention rule plus delisting path, and commits a written notice period for fee changes.",
"files": [],
"expectations": [
"Rejects folding payment-processing cost into the headline share and requires it as a separately labeled pass-through line",
"Gives the reason: a share that silently includes processing reads as a higher take than it is and cannot be compared honestly against competitors' headline rates",
"Names revenue share netted at source as the collection mechanism, deducted before payout rather than invoiced, audited, or chased",
"Evaluates the $2,500 submission fee against the real cost it funds, such as the security or app review, rather than accepting it as a round number",
"Notes that a registration-style flat fee should be sized to deter low-intent or spam submissions without deterring legitimate developers",
"Distinguishes one-time registration fees, per-app review fees, and annual listing fees as separate flat instruments rather than one undifferentiated charge",
"Treats the \"pay here instead\" link as circumvention of the revenue share and a partner-terms violation, not a pricing complaint or a product decision",
"Requires writing an explicit anti-circumvention rule into the partner terms",
"Requires backing that rule with a delisting path, stating that a rule without a removal path is only a preference",
"Notes that circumvention pressure rises with the take-rate",
"Requires a written, committed notice period for fee changes, roughly six months as the established pattern, published alongside the fee schedule, with unfavorable changes deferred and favorable ones accelerated"
]
},
{
"id": 8,
"prompt": "Final review before we flip the switch in three weeks. Recap: we're merchant of record, 15% rev share netted out before payout, automatic tax calculation is switched on in our billing provider for all 50 US states and the EU, we have 40 active app vendors averaging about $600 a month gross each, monthly payouts, and a $1M annual exemption tier. Our ops dashboard will watch payout volume and take revenue. What would you check?",
"expected_output": "A run that flags the silent zero-tax failure and demands registration verification plus independent tax monitoring, challenges per-active-developer unit economics at $600/month gross, and checks the design against the three gates plus the full post-launch metric set rather than payout volume and take revenue alone.",
"files": [],
"expectations": [
"Flags that automatic tax calculation with no active registration in a jurisdiction returns no error and silently collects zero tax",
"States that under-collected past transactions cannot be retroactively corrected",
"Requires verifying active tax registrations jurisdiction by jurisdiction rather than trusting that calculation is switched on",
"Requires monitoring tax collection as its own system, because payout health does not reveal tax health",
"Challenges the per-active-developer unit economics: roughly $90 a month collected at 15% of $600 gross must be netted against flat per-account and per-payout rail fees plus processing",
"States unit economics must be modeled per active developer rather than per transaction",
"Checks that the merchant-of-record posture is stated per app population with tax, chargeback, and payout ownership each explicitly assigned and no transaction type left ambiguous",
"Checks that every fee instrument names its collection mechanism, its enforcement pair, and its notice commitment in writing",
"Checks that the published developer docs state the end-to-end sale-to-bank timeline and the jurisdiction-by-jurisdiction tax split",
"Extends the dashboard beyond payout volume and take revenue to include net take revenue against billing-ops cost, median sale-to-bank days against the published timeline, dispute and chargeback rate attributed to whoever the posture assigned it, waiver coverage among eligible developers, tax-registration coverage of transaction volume, and circumvention incidents",
"Says to baseline against the platform's own first quarter rather than treating other platforms' published figures as targets"
]
},
{
"id": 9,
"prompt": "We have 180 apps already billing our customers directly on their own processors, some of them on three-year contracts signed last year. On January 1 we become merchant of record for everything: single cutover, no exceptions, all 180 migrate. We also want to pull roughly $4M of annual off-marketplace revenue from private deals our partners closed outside the directory onto the marketplace. We have two people on billing engineering and no dedicated compliance headcount. Poke holes.",
"expected_output": "A run that rejects the single cutover for a population under multi-year contracts, names the configurable-per-app posture and its doubled cost against the stated headcount, frames the developer-billed branch as a closing legacy path, and uses the $4M back-book to promote differential-rate migration incentives under the notice commitment.",
"files": [],
"expectations": [
"Challenges the single-cutover assumption for a legacy population that cannot migrate in one cycle, given the multi-year customer contracts already signed",
"Names the configurable-per-app posture, running both merchant-of-record postures at once, as what a phased migration actually requires",
"States its real cost: two billing branches, two tax postures, two payout systems, and doubled developer documentation",
"Notes the compliance review runs twice under the configurable posture, and flags the two-person billing team with no compliance headcount as the binding effort ceiling",
"Requires the developer-billed branch to be framed as a closing legacy path with a stated end direction, never as an option offered to new developers",
"Identifies the roughly $4M off-marketplace back-book as what promotes migration incentives from the starved rung",
"States that with no measurable back-book the migration-incentive shape should be deleted from the menu rather than parked at the bottom of it",
"Proposes differential rates as the migration lever, pairing an accelerated benefit on the preferred path with a deferred increase on the legacy one, rather than only waiving fees",
"Notes the differential-rate lever is worth more than the waived fees themselves",
"Requires the rate changes involved to run under the published notice commitment, with the unfavorable leg deferred"
]
}
],
"trigger_queries": [
{ "query": "who should be merchant of record on our app marketplace, us or the app vendors?", "should_trigger": true },
{ "query": "we're switching our integrations directory from free to paid, how do we actually collect our cut?", "should_trigger": true },
{ "query": "design the fee stack and payout schedule for our connector marketplace", "should_trigger": true },
{ "query": "should the platform bill the customer or should each app developer bill directly?", "should_trigger": true },
{ "query": "how long should we hold marketplace funds before paying app partners?", "should_trigger": true },
{ "query": "our partners say payouts take forever, what should we actually publish in the docs?", "should_trigger": true },
{ "query": "do we owe sales tax on apps sold through our marketplace if the developer bills the customer?", "should_trigger": true },
{ "query": "we want to waive fees for small app developers, how should that work?", "should_trigger": true },
{ "query": "what revenue threshold should our zero-fee tier for app partners use?", "should_trigger": true },
{ "query": "design a small-partner fee exemption for our app store", "should_trigger": true },
{ "query": "one of our apps is routing billing around us to skip the rev share", "should_trigger": true },
{ "query": "how much notice do we owe partners before raising our marketplace fee?", "should_trigger": true },
{ "query": "set up rev share collection on our app marketplace so we don't have to chase invoices", "should_trigger": true },
{ "query": "our marketplace checkout doesn't do metered billing but we promised partners usage pricing", "should_trigger": true },
{ "query": "which pricing models should we let marketplace app vendors offer?", "should_trigger": true },
{ "query": "we're becoming merchant of record for third-party apps, what does that change for us?", "should_trigger": true },
{ "query": "who eats chargebacks when a customer disputes a third-party app charge on our platform?", "should_trigger": true },
{ "query": "should app charges go on the customer's existing invoice with us or through a separate checkout?", "should_trigger": true },
{ "query": "help me design the money flow for our partner app store", "should_trigger": true },
{ "query": "destination charges or separate charges and transfers for our marketplace payouts?", "should_trigger": true },
{ "query": "we want a 45-day hold on marketplace payouts, how do we build that", "should_trigger": true },
{ "query": "our EU customers buy third-party apps through us, who remits the VAT?", "should_trigger": true },
{ "query": "write the tax split we publish to our app developers", "should_trigger": true },
{ "query": "how do other B2B marketplaces structure the processing fee versus the revenue share?", "should_trigger": true },
{ "query": "is it fine to bundle payment processing into our marketplace take rate?", "should_trigger": true },
{ "query": "our app partners have to enroll for the reduced fee and most of them never do", "should_trigger": true },
{ "query": "what should our marketplace charge per app submission?", "should_trigger": true },
{ "query": "we're paying more in connected-account fees than we collect from our small app partners", "should_trigger": true },
{ "query": "how do we get 200 partners who currently bill customers directly onto our billing?", "should_trigger": true },
{ "query": "cutover plan for moving legacy vendor-billed apps to platform-billed", "should_trigger": true },
{ "query": "we want partners who move off-platform contracts into the marketplace to get a discount", "should_trigger": true },
{ "query": "how should we price the move from our old app framework to the new one for partners?", "should_trigger": true },
{ "query": "what metrics tell us our marketplace money model is actually working?", "should_trigger": true },
{ "query": "our tax engine is switched on but I think we've been collecting zero in half these states", "should_trigger": true },
{ "query": "should app vendors get a full billing dashboard or a stripped-down one?", "should_trigger": true },
{ "query": "does being the merchant of record mean we can't offer usage-based apps?", "should_trigger": true },
{ "query": "we take nothing from our integrations today and finance wants that to change", "should_trigger": true },
{ "query": "payout cadence for third-party app developers, weekly, monthly, or instant?", "should_trigger": true },
{ "query": "we need to write the money section of our partner agreement", "should_trigger": true },
{ "query": "who's liable if sales tax on a marketplace app is calculated wrong?", "should_trigger": true },
{ "query": "design how our directory makes money without wrecking developer trust", "should_trigger": true },
{ "query": "our app store revenue share, how do we actually enforce it?", "should_trigger": true },
{ "query": "what sale-to-bank timeline should we promise our app partners?", "should_trigger": true },
{ "query": "should we absorb refunds on third-party apps or push them to the developer?", "should_trigger": true },
{ "query": "we're standing up paid connectors and I have no idea how the billing should be structured", "should_trigger": true },
{ "query": "what take rate should our app marketplace charge, 10, 15, or 20 percent?", "should_trigger": false },
{ "query": "should we build our own integration marketplace or just list on other people's?", "should_trigger": false },
{ "query": "how curated should our app marketplace be, open submissions or invite-only?", "should_trigger": false },
{ "query": "design the security review process for third-party apps before they get published", "should_trigger": false },
{ "query": "what should we require in an app listing's screenshots and description?", "should_trigger": false },
{ "query": "write the category taxonomy for our app directory", "should_trigger": false },
{ "query": "plan the launch marketing for our new app marketplace", "should_trigger": false },
{ "query": "how many launch partners should be in our marketplace's founding cohort?", "should_trigger": false },
{ "query": "design the partner developer signup and sandbox provisioning flow", "should_trigger": false },
{ "query": "we're listed on AppExchange and want more installs, optimize our listing", "should_trigger": false },
{ "query": "should we build a Fivetran connector or an Airbyte one first?", "should_trigger": false },
{ "query": "how should we price our own SaaS product's tiers?", "should_trigger": false },
{ "query": "what should we charge for our API's enterprise plan?", "should_trigger": false },
{ "query": "set up Stripe Checkout in our Next.js app", "should_trigger": false },
{ "query": "implement Stripe subscriptions with webhook handlers in our backend", "should_trigger": false },
{ "query": "our dunning emails aren't recovering failed payments", "should_trigger": false },
{ "query": "reduce involuntary churn from expired credit cards", "should_trigger": false },
{ "query": "generate an invoice template for my consulting business", "should_trigger": false },
{ "query": "how do I add purchasing power parity pricing to my iOS app?", "should_trigger": false },
{ "query": "monetize my mobile game, ads or in-app purchases?", "should_trigger": false },
{ "query": "our AWS bill doubled last month, help me find where the cost went", "should_trigger": false },
{ "query": "design rate limits and quota tiers for our public API", "should_trigger": false },
{ "query": "write our API deprecation and sunset policy", "should_trigger": false },
{ "query": "design the webhook retry and dead-letter policy for our platform", "should_trigger": false },
{ "query": "which languages should we ship official SDKs in?", "should_trigger": false },
{ "query": "design our OAuth scopes and consent screen for third-party apps", "should_trigger": false },
{ "query": "should we expose an MCP server for our product?", "should_trigger": false },
{ "query": "design a JDBC endpoint so customers can query their own data", "should_trigger": false },
{ "query": "how should we deliver bulk Parquet exports to enterprise customers?", "should_trigger": false },
{ "query": "what goes on the landing page of our developer portal?", "should_trigger": false },
{ "query": "which technology partners should we integrate with next?", "should_trigger": false },
{ "query": "design our partner tiers, silver, gold, platinum, and their benefits", "should_trigger": false },
{ "query": "how do we structure commission for our reseller channel?", "should_trigger": false },
{ "query": "write an affiliate program for our SaaS", "should_trigger": false },
{ "query": "how should we compensate our sales reps on partner-sourced deals?", "should_trigger": false },
{ "query": "pick a billing system for our own subscription business, Chargebee or Recurly?", "should_trigger": false },
{ "query": "we need to close the books faster, our billing ops is still manual", "should_trigger": false },
{ "query": "how do we handle revenue recognition under ASC 606 for annual contracts?", "should_trigger": false },
{ "query": "what's a good free trial length for our product?", "should_trigger": false },
{ "query": "design a usage-based pricing metric for our API product", "should_trigger": false },
{ "query": "should our open source project charge for a hosted version?", "should_trigger": false },
{ "query": "how do we sponsor a developer conference and what do we get for it?", "should_trigger": false },
{ "query": "write the job description for a partner integration engineer", "should_trigger": false },
{ "query": "what's our developer community moderation policy?", "should_trigger": false },
{ "query": "we're a Shopify app developer, how do we grow installs on the app store?", "should_trigger": false }
]
}
references/fee-stack-and-incentives.md›
# Fee stacks and incentive programs - named benchmarks
Figures and effective dates go stale - re-verify any number before publishing it in a live fee schedule. Take-rate _level and tier architecture_ (which percentage, which tiers, zero-take-or-not) belongs to `samber/developer-platform-skills@connector-marketplace-strategy`; this file covers the instruments and incentive programs that implement it.
## Named fee stacks
- **Salesforce AppExchange** - the full-stack archetype: 15% of net revenue for standard ISV partners (25% OEM), plus a one-time $999 security-review fee per paid app and a $150 annual listing fee. Free apps (~40% of the marketplace) pay no revenue share; a flat-annual-fee contract exists for apps that don't fit the percentage model. Every instrument type appears in one stack: revenue share, review fee, listing fee, and flat-fee fallback.
- **Shopify App Store** - the low-friction stack:
- One-time $19 partner-registration fee.
- 0% revenue share on the first $1M of **lifetime** gross App Store revenue, 15% above.
- A flat 2.9% payment-processing fee, charged as a separate labeled line, not folded into the share.
Very large developers ($20M+/year through the store, or $100M+ company revenue) pay 15% on everything, reassessed annually.
- **Atlassian Marketplace** - the differential-rate stack: within Paid via Atlassian, the rate depends on hosting framework - Forge stepping 15% → 16% → 17%, Connect stepping 15% → 20% → 25% (steps extended to April 1 and October 1, 2026). Only apps exclusively on Forge modules, Forge auth, and Forge UI get Forge rates; any Connect module present gets Connect rates.
- **HubSpot App Marketplace** - the zero-take contrast: no revenue share at all; the marketplace is funded as a retention asset. Zero-take is an architecture, not a transitional embarrassment - and it needs no collection instrument, which is why the monetization build should wait for a non-zero rate.
- **Apple App Store / Google Play** - the consumer-store baseline the B2B stacks position against: 30% headline, 15% small-developer tiers (below). Shopify explicitly markets its 15% ceiling against this 30% - take-rate generosity used as a developer-acquisition lever.
## Waiver and incentive programs, by shape
Fee waivers are a standard menu item across major marketplaces, not an exceptional discount. The programs cluster around a **$1M revenue threshold** as the near-universal cutoff - an operator picking its own threshold has strong precedent to anchor there rather than invent a number.
**Revenue-exemption tiers:**
- Apple Small Business Program (since Jan 1, 2021):
- 30% → 15% for developers with ≤$1M prior-calendar-year proceeds.
- Crossing $1M mid-year reverts to 30% for the rest of the year.
- Associated accounts aggregate toward the cap.
- **Enrollment is manual.**
- Google Play (since July 1, 2021): 15% on the first $1M of earnings, resetting annually; subscriptions at 15% from Jan 1, 2022. A March 2026 restructuring moves toward a 10% base service fee on the first $1M plus a separate 5% billing fee (rollout from June 30, 2026 in US/EEA/UK), keeping the effective rate near 15% for most developers. **Enrollment is manual.**
- Shopify: the 0%-under-$1M tier became a **lifetime** cap as of Jan 1, 2025 (previously an annual reset; earnings before that date don't count toward the threshold) - a one-way tightening, and the one exception to the annual-reset pattern. Deciding annual-vs-lifetime is a real design choice, not a detail.
The enrollment lesson: on both manual-enrollment programs, a qualifying developer who misses the paperwork silently pays the full rate. An operator's own program should default eligible developers in if the waiver is meant to change behavior rather than exist on paper.
**Migration incentives:**
- Atlassian's Forge 0% incentive: 0% revenue share on eligible Forge apps up to $1M lifetime Forge revenue (aggregated per partner company), replacing an earlier 5%-in-year-one incentive; an accelerated "Runs on Atlassian" variant lets qualifying apps keep 100% up to the same cap. Paired with the Connect rate _increases_ above - favorable changes accelerated, unfavorable deferred, both under a stated six-months-notice commitment.
- Microsoft's renewal discount: 50% off the marketplace transaction/agency fee on private-offer and multiparty renewals via self-attestation, explicitly covering migrations of existing paid agreements onto the marketplace - a retention lever aimed at deals the platform didn't originally win.
**Behavior-based discounts:**
Each pays for a named pricing, packaging, or architecture choice rather than a revenue level.
- Google's subscription-vs-one-time split (subscriptions get the lower rate)
- Atlassian's framework split (Forge cheaper than Connect)
- Atlassian's solution-partner reseller discounts off list price
## Enforcement precedents
- **Anti-circumvention with a delisting path**: several high-revenue Shopify apps routed billing through an external processor to dodge the revenue share, violating the partner terms, and reversed course under delisting threat. "Pay through us" is a governance rule enforced by removal, not a pricing preference - and circumvention pressure rises with the rate.
- **Notice-period commitment**: Atlassian's standard-rate changes carry a stated six-months-notice commitment; its 2026 Connect increases were deferred three months while the Forge benefit was accelerated. Adopt the notice period before the first rate change, and publish it with the fee schedule.
- **Compliance delisting**: Salesforce's May 2026 mandatory security controls for connected apps, with non-compliant apps delisted - a mature marketplace uses delisting as its enforcement lever for security and for revenue rules alike.
references/mor-and-billing-rails.md›
# Merchant-of-record postures and billing rails
Marketplace monetization mechanics vary across platform implementations. Platform rates and dates shift - re-verify before quoting them in a live design.
## The one upstream fork
"Who bills the end customer" is not one choice among several - it is the single fact that determines four downstream systems at once:
| | Marketplace-billed (platform-as-MoR) | Developer-billed (vendor-as-MoR) |
| ---------------------------- | ------------------------------------------------ | --------------------------------------------------- |
| Merchant of record | The marketplace operator | The app developer |
| Tax liability default | Platform | Developer |
| Chargeback/dispute ownership | Platform absorbs and manages | Developer's own responsibility |
| Pricing models offerable | Capped by what the marketplace checkout supports | Whatever the developer's own billing stack supports |
| Take-rate collection | Netted at source before payout | Self-reported/audited, owed separately |
| Payout | Platform pays out net revenue on its schedule | Developer collects gross directly |
The marketplace-billed branch earns its complexity by being the only one that lets the operator bundle tax compliance, chargeback handling, licensing/entitlement automation, and revenue reporting into one developer-facing promise - "we handle the business-operations toil, you handle the product." Developer-billed is cheaper for the operator (it builds less) but pushes every one of those systems onto each developer individually, a real adoption-friction cost to weigh against the take-rate charged.
## Charge patterns under managed rails (Stripe Connect)
The charge pattern is what technically decides merchant of record:
| Pattern | MoR | Platform fee | Use |
| ---------------------------- | --------------------------------- | ------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Direct charges | The developer (connected account) | `application_fee_amount` | Developer-billed; developer's name on the customer statement, developer handles own disputes |
| Destination charges | The platform | `application_fee_amount` or transfer amount | Marketplace-billed default; auto-pays the developer on payment success - not for hold-and-release |
| Separate charges & transfers | The platform | Manual (transfer less than charge) | Marketplace-billed with delayed/gated/split payouts - required whenever payout isn't "instant on payment" |
Stripe's own guidance: do **not** use `on_behalf_of` for marketplace use cases - it keeps the charge on the platform while making the developer MoR, a mismatch most operators don't actually want.
## Account-configuration dials and the two bundles
Stripe's Connect Accounts v2 replaced fixed account types with three independent dials:
- Dashboard access (`express`/`full`/`none`)
- Fee collection (`stripe`/`application`)
- Loss liability (`stripe`/`application`)
The compatibility matrix collapses them into two coherent bundles:
- **Marketplace-shaped**: express dashboard, platform collects fees, platform carries losses, destination or separate charges. Hard rule, not preference: any non-direct charge pattern **requires** the platform to carry losses - combining them with `losses_collector: 'stripe'` is blocked, and near-miss combinations silently shift liability onto the platform.
- **SaaS-shaped**: full dashboard, Stripe bills the developer, Stripe carries losses, direct charges only.
Cost of the marketplace bundle to model per active developer: roughly £1.60/month per active express-dashboard account, plus 0.25% and £0.20 per payout (Stripe UK pricing, varies by region), on top of standard processing. At low per-developer volume, the flat fees can exceed the percentage collected.
## Per-platform postures (2026 landscape)
- **Apple App Store, Google Play**: pure platform-as-MoR (agent/commissionaire); platform owns tax, chargebacks, pricing ceiling. Neither natively supports usage-based billing.
- **Microsoft Commercial Marketplace**: platform-as-MoR agency model, and the one platform-billed archetype here that natively supports usage-based/metered billing - proof "marketplace-billed" and "no usage pricing" are separate constraints.
- **Shopify App Store**: marketplace-billed one step beyond destination charges. App charges consolidate onto the merchant's existing ~30-day Shopify invoice ("charges are directly added to the merchant's Shopify invoice"), and Shopify "handles all chargeback-related processes" plus billing, trials, proration, upgrades/downgrades. Supports recurring, usage-based, and one-time charge types. This invoice-consolidation shape requires already being the customer's primary biller - the precondition most operators lack but can approximate with destination charges.
- **Salesforce AppExchange Checkout**: marketplace checkout branding over Stripe rails underneath; supports one-time and subscription plans plus coupons and trials - **no usage-based pricing**, the sourced case of rails capping the developer pricing menu. Pairs the payment rails with two separable systems: the License Management App (entitlement provisioning) and Checkout Management App (partner revenue reporting) - a monetization stack is at least three systems (payment, entitlement, reporting), and a design covering only payment leaves two unspecified.
- **Atlassian Marketplace**: runs the full fork as internal policy - "Paid via Atlassian" (platform-as-MoR: Atlassian bills, licenses, handles tax and refunds, pays out net) versus "Paid via Vendor" (vendor-as-MoR, vendor keeps 100% but carries payment, tax, and disputes). Cloud apps can no longer list as Paid via Vendor except narrow requested exceptions - the configurable posture exists as a closing legacy branch, not an open choice. Independently of that fork, the Forge-vs-Connect hosting choice sets the _rate_, not the MoR: "who bills" and "what rate" are two separable dials.
## Tax status is not MoR
Stripe's documentation distinguishes marketplace-facilitator/deemed-supplier status (tax law) from merchant of record (card-network status): the two "are legally distinct and don't always coincide." The charge pattern determines the card-network MoR; tax liability can attach to a different entity by statute regardless - the legal frameworks are covered in this skill's payout-and-tax reference, linked from SKILL.md.
references/payout-and-tax-mechanics.md›
# Payout mechanics and the tax layer
Payout schedules and tax rules change - re-verify before publishing a timeline or a tax split. **Nothing here is tax advice**: state-by-state and country-by-country rules vary, and sellers frequently retain filing or nexus obligations even when a platform remits the tax; route the published split through qualified counsel.
## Seven-platform payout comparison
Payout speed tracks the merchant-of-record choice: platform-as-MoR stores hold funds longest; direct managed-rails configurations pay fastest.
| Platform | Frequency | Minimum | Holds/reserves | Time to bank |
| -------------------------------- | ----------------------------------------------------------------------------------- | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Apple App Store | Monthly (per fiscal month) | ~$150 (region-dependent) | Fiscal-month-close tax/refund netting | Within 45 days of fiscal-month close (documented); ~33 days typical, up to ~68 days from sale (community-reconstructed) |
| Google Play | Monthly, starts the 15th | $1 most regions | None published | EFT 2-3 business days after the 15th → ~30-45 days from sale |
| Microsoft Commercial Marketplace | Monthly | $50 combined | 30-day credit-card escrow on top of the cycle; future payouts withholdable to recover write-offs | Cycle + 30-day escrow (credit card); 30 days post customer invoice (EA) |
| Atlassian (Paid via Atlassian) | Monthly | No published dollar minimum | 30-day refund/chargeback window (31-60 at Atlassian's discretion) | ~30 days after month-end, max 60; only for sales where Atlassian received final payment |
| Shopify App Store | Rides the merchant's ~30-day invoice cycle | None separate | Shopify absorbs chargeback handling | Same cycle as the merchant's Shopify invoice; payout at partner-account level, not per app |
| Salesforce AppExchange Checkout | Not published - governed by the partner's own connected Stripe account | Not published | Stripe's standard new-account hold (inferred, not Salesforce-confirmed) | Stripe standard rolling (~T+2). A documentation gap, not a withheld commitment - never quote a fixed Salesforce schedule |
| Stripe Connect (build-your-own) | Daily rolling default; configurable daily/weekly/monthly; Instant ~30 min for a fee | Platform-configurable | Fixed reserves (to a release date) or rolling reserves (% on a rolling window, e.g. 30 days); 7-14 day new-seller hold is a common platform-added policy | Fastest of the seven - entirely platform-configured |
**How to read it for a design**: minimum thresholds cluster in a $50-$150 range - small enough that active developers clear them every cycle. The cash-flow lever developers actually feel is the multi-week hold/escrow period. Working-capital modeling should use the real lag (~33-68 days at the slowest archetype; cycle-plus-30-day escrow at another), not the headline "monthly" or "within 45 days" language. The operator's published timeline should state the honest end-to-end number.
**Cross-border**: every platform-as-MoR store converts payouts to the developer's bank-account currency and absorbs FX conversion and payment-rail choice; the developer never picks a rail. An operator adopting the marketplace-billed posture inherits that same role - budget it as part of the posture.
## US: marketplace-facilitator statutes
_South Dakota v. Wayfair_ (2018) let states tax remote sellers on economic nexus; states responded with marketplace-facilitator laws shifting the calculate/collect/remit obligation - and liability for errors - from individual sellers to the marketplace itself. The Tax Foundation counts 38 dedicated facilitator regimes among the 45 sales-tax states; all sales-tax states have some form of economic nexus for facilitators. It is a state-by-state framework, not federal:
- Some states exclude local taxes.
- Some still require sellers to file informational returns.
- Marketplace sales may still count toward a seller's own nexus thresholds even when the marketplace remits.
## EU: the deemed-supplier rule
Since July 1, 2021, the EU's e-commerce VAT package (Article 14a) treats an electronic interface facilitating certain **B2C** supplies as if it bought and resold them itself, making the platform liable to collect and remit VAT: one commercial sale splits into a B2B leg (seller → platform) and a B2C leg (platform → consumer). Three mechanics apply:
- OSS lets a business file one VAT return covering all 27 member states.
- IOSS covers imports ≤€150.
- A €10,000 distance-selling threshold applies, below which home-country VAT can still be charged.
The 2025 ViDA package extends deemed-supplier treatment to more platform categories: scope is widening, not narrowing. B2B cross-border VAT is typically reverse-charged to the business buyer instead, which is why a purely B2B-buyer marketplace faces a lighter version of this layer.
## The split is never a binary toggle
- **Microsoft** splits by country: in Microsoft-Managed countries it is agent/commissionaire and calculates/collects/remits; in Publisher/Developer-Managed countries the publisher carries sole responsibility for registration, collection, remittance, and tax invoices.
- **Salesforce** splits by tax regime: Checkout calculates, collects, and remits **US sales tax** on the partner's behalf, but is deliberately not the general MoR for VAT. "You're responsible for VAT registration, maintaining required data, and distributing the taxes that you collect" holds internationally, even though Checkout can collect the VAT amount at the point of sale.
- **Apple, Google, Atlassian** (platform-as-MoR): the legal requirement and the commercial choice point the same direction - the platform collects and remits in most jurisdictions.
A well-designed marketplace publishes its split explicitly - which tax, which country, whose obligation - rather than leaving developers to discover it jurisdiction by jurisdiction.
## Mechanics under managed rails, and the silent-failure trap
Stripe Tax assigns liability explicitly (`automatic_tax.liability`: `self` for the platform, `account` for the developer), and the practical determination follows the charge type - direct charges make the developer MoR, destination charges usually the platform. A platform passing tax liability to developers must also give each developer its own registration surface, not just flip a flag on its own account.
The trap worth engineering around: enabling automatic tax calculation with **no active registration** in a jurisdiction returns no error and silently collects $0 tax - and under-collected past transactions cannot be retroactively corrected. Payout mechanics and tax mechanics are two independently failure-prone systems; neither's health is visible from watching the other, so verify tax collection with its own monitoring.
SKILL.md›
---
name: app-marketplace-monetization-model
description: Design how a B2B SaaS app/connector marketplace makes money, operator side - merchant-of-record posture (marketplace-billed vs developer-billed), billing rails and account configuration, the fee stack (revenue share collected at source, program fees, processing pass-through), fee waivers and incentive tiers, payout cadence and hold windows, and the marketplace-facilitator/VAT tax layer. Use whenever the user mentions charging for apps, rev-share collection, paid-app billing or billing APIs, developer payouts, fee waivers, or merchant of record - even if they never say "marketplace monetization". Mechanics layer only. Do NOT use for take-rate level and tiers - use samber/developer-platform-skills@connector-marketplace-strategy instead.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# App Marketplace Monetization Model
You are a marketplace-monetization designer advising the team that operates a B2B SaaS platform's app or connector marketplace. The strategy layer has (or should have) already set the take-rate level and tier architecture. This skill designs the machinery underneath it:
- Who bills the end customer
- How the platform's cut is collected
- What developers can charge
- When they get paid
- Who owes which tax, where
The output is a monetization design the platform team can implement and publish to its developers.
One question structures everything else: **who is merchant of record** - the marketplace, or each app developer. Fix it first; every later section is a sub-decision of it. Across every platform, that single choice determines:
- Tax liability
- Chargeback ownership
- Available developer pricing models
- How payouts work
**Memory (advised):** When memory lives in a file, consider using `developer-platform-context.md`; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.
## Interview
Ask these before proposing anything. One question per message, multiple-choice where offered - each answer moves a rung in the menus below, and batching them buries the one answer that changes the design.
1. Is the take-rate architecture already decided (level, tiers, zero-take-or-not)? If not, stop and run `samber/developer-platform-skills@connector-marketplace-strategy` first - this skill executes that decision, it doesn't make it.
2. Do you already bill these end customers on a recurring invoice or settlement cycle for your core product?
3. Which pricing models must developers be able to offer? (a) flat subscription (b) per-seat (c) usage-based/metered (d) one-time (e) free with paid tiers.
4. What billing engineering exists in-house - a full billing stack, a managed payment-rails provider, or neither?
5. Where do buyers sit - US only, EU, beyond? And are any end buyers consumers rather than businesses? (This changes the tax layer, not the rest.)
6. What loss appetite do you have - will the platform absorb chargebacks, refunds, and fraud losses, or must developers carry their own?
7. Is there an existing population of apps already billing customers directly that you cannot migrate in one cycle?
8. By when must the model be live - a hard date, or open-ended?
9. Is this a one-off unlock (start collecting the agreed rate) or a compounding asset (billing infrastructure you'll extend)?
10. What is the effort ceiling - billing/payments engineering hours, compliance and legal review capacity, appetite for carrying financial risk?
Questions 8-10 exist because the menus below diverge sharply on time-to-effect, durability, and effort - the default rankings cannot pick for the user.
- A hard date promotes managed rails and the simplest posture.
- A compounding mandate promotes owning more of the stack.
- A low effort ceiling deletes the configurable-per-app posture outright rather than demoting it.
## Where B2B vs B2C actually matters here
The operator this skill serves is a B2B SaaS platform, and most of the design does not split on whether its end buyers are businesses or consumers - merchant-of-record posture, fee stack, and payout mechanics work the same. The one layer that genuinely splits is tax: the EU's deemed-supplier VAT rule attaches to B2C supplies specifically (B2B cross-border VAT is typically reverse-charged to the business buyer instead), and US marketplace-facilitator statutes exist because states wanted consumer sales tax collected at the platform.
- A marketplace with any consumer-facing apps treats question 5's answer as a tax-design input, not demographic trivia.
- A purely B2B-buyer marketplace gets a lighter version of step 7, not a different skill.
## Workflow
1. Confirm the take-rate architecture from the strategy layer (interview question 1).
2. Fix the merchant-of-record posture.
3. Configure the billing rails and account dimensions behind that posture.
4. Compose the fee stack that implements the take-rate.
5. Set the pricing-model menu developers get - after checking the rails support it.
6. Design fee waivers and incentives.
7. Design payout cadence, holds, and thresholds; publish the sale-to-bank timeline.
8. Map the tax layer jurisdiction by jurisdiction and publish the split.
9. Write the enforcement rules and notice commitments.
10. Check the design against the measurement gates.
Draft the design section by section in that order, validating each with the user before the next - a merchant-of-record assumption caught at step 2 is cheap; the same assumption discovered at step 8 rewrites the tax map and the payout system together. Re-rank every menu below against what you know about this user before presenting it: an in-house billing platform, an existing invoice cycle, a legacy developer-billed population, or a hard date each move rungs. The defaults are defaults, not laws.
## 2. Merchant-of-record posture
Three postures, ranked. Mechanics, platform-by-platform postures, and the underlying charge patterns: [references/mor-and-billing-rails.md](references/mor-and-billing-rails.md).
- effort (descending): `configurable per app > marketplace-billed > developer-billed`
- developer-adoption value (descending): `marketplace-billed > configurable per app > developer-billed`
- compliance cost (descending): `configurable per app > marketplace-billed > developer-billed` - the configurable posture papers two tax postures and two liability models at once, so every review runs twice and each app's posture is a commitment to that developer; marketplace-billed triggers tax registration and remittance wherever you sell plus card-network merchant obligations, and unwinding it means re-billing live customers and re-papering developer agreements; developer-billed pushes registration and disputes onto each developer, but facilitator and deemed-supplier statutes still attach by law (step 8) - a lighter review, never none.
- efficiency: `developer-billed while zero-take > marketplace-billed once charging > configurable per app`
- **Default rung: developer-billed (vendor-as-MoR) - but only while the take-rate is zero.** Each developer bills its own customers and carries its own tax, disputes, and dunning; the marketplace builds almost nothing. When the strategy layer chose zero-take as a retention asset, there is no cut to collect, so building collection machinery buys nothing.
- **Promotion condition: the moment a take-rate is charged, promote to marketplace-billed (platform-as-MoR).** Collection at source - netting the platform's share out of money that already flows through it - is the only collection mechanism that doesn't depend on developer self-reporting, and it is what lets the marketplace bundle tax handling, chargeback absorption, and billing automation into its developer pitch. Every mature charging marketplace in the sourced landscape converged here. When you already bill these customers on a cycle (question 2), the strongest variant is consolidating app charges onto that existing invoice - one bill for the customer, near-zero marginal checkout build.
- **Starved option: configurable per app (both postures at once).** It runs two billing branches, two tax postures, two payout systems, and doubled developer documentation, so it loses every efficiency round. Question 7 promotes it anyway: a legacy developer-billed population that can't migrate in one cycle forces running both - and the one sourced platform doing this treats the developer-billed branch as a closing legacy path with a stated end direction, not a permanent choice it offers new developers. If question 7 is a clean no, delete this rung from the discussion entirely.
Marketplace-billed is the high-effort, high-value rung - it wins on value and on efficiency-once-charging simultaneously, which is why the promotion condition is about when, not whether.
## 3. Billing rails
Under a marketplace-billed posture, three dials configure the rails:
- Who the end customer's charge is created against
- Who absorbs unresolved losses
- What dashboard the developer sees
The sourced rails provider exposes them independently, but the compatibility matrix collapses them into two coherent bundles: a marketplace-shaped bundle (platform owns the charge, the losses, and a lightweight branded developer view) and a SaaS-shaped bundle (developer owns all three). À-la-carte combinations outside those bundles are blocked or silently shift liability. Pick the bundle matching the step 2 posture; per-dial detail and the payout-timing patterns each bundle allows are in [references/mor-and-billing-rails.md](references/mor-and-billing-rails.md).
Whatever the rails, budget their real cost against the take-rate: managed marketplace rails carry per-account and per-payout fees on top of processing, and at low per-developer volume those flat fees can outweigh the percentage collected. Build the unit economics per active developer, not per transaction.
## 4. Fee-stack composition
The take-rate level and tiers come from the strategy layer; this step decides which instruments collect it. Four instruments, ranked. Named fee stacks with figures and dates: [references/fee-stack-and-incentives.md](references/fee-stack-and-incentives.md).
- collection effort (descending): `audited self-reported share > revenue share netted at source > flat program fees == processing pass-through`
- revenue and enforcement value (descending): `revenue share netted at source > audited self-reported share > flat program fees > processing pass-through`
- efficiency: `revenue share netted at source > flat program fees > processing pass-through > audited self-reported share`
- **Default rung: revenue share netted at source.** Once marketplace-billed, the platform's cut is deducted before payout - no invoicing, no audit, no chasing. Its build sits upstream in step 3, so what remains here is netting and reconciliation: more setup than a flat charge, far less than a standing audit function, and it collects a percentage neither flat instrument can.
- **Flat program fees** (one-time registration, per-app review fee, annual listing fee) complement the share where they price a real cost or filter low-intent submissions - the sourced stacks charge a review fee that funds the security review and a registration fee small enough to deter spam without deterring developers. The `==` with processing pass-through is genuine: both are simple flat charges with no per-transaction machinery.
- **Processing pass-through**: keep payment-processing cost a separately labeled flat line, as the sourced marketplaces do, rather than burying it inside the share - a share that silently includes processing reads as a higher take than it is, and can't be compared honestly against competitors' headline rates.
- **Starved option: audited self-reported share.** Under a developer-billed posture it is the only way to collect a percentage, and it loses every round on enforcement - the platform learns its own revenue from numbers the payer reports. It is a fallback forced by posture, never a choice; if step 2 landed on marketplace-billed, delete it. Where it must exist, it needs the anti-circumvention rule and delisting path from step 9 more than any other instrument.
## 5. Pricing-model menu for developers
Decide which of question 3's models the marketplace supports:
- Flat subscription
- Per-seat
- Usage-based
- One-time
- Free with paid tiers
This menu is deliberately unranked: developer demand and rails capability decide it jointly, so there is no operator trade-off left for an efficiency order to resolve.
The trap is ordering: the rails choice caps this menu, not the other way around. One sourced enterprise marketplace's checkout supports only one-time and subscription - no usage-based - so developers wanting consumption pricing simply can't offer it there; another platform's billing supports recurring, usage-based, and one-time charges natively. Verify each promised model against the step 3 rails before publishing the menu, and treat usage-based as a maturity ladder (simple metering versus dimensional, contract-grade metering) rather than one feature - scope which rung developers actually need.
Two rules are worth adopting whatever the rails:
- Model each pricing tier as its own product object, never as price-variants of one product: variants of one product become indistinguishable on customer invoices.
- Let the marketplace recommend defaults, such as free trials or an entry plan, rather than mandate them. This is how the sourced platforms shape pricing adoption without owning developers' pricing decisions.
## 6. Fee waivers and incentives
Waivers are now a standard menu item across major marketplaces, not an exceptional discount - expect to offer at least one shape. Three shapes, ranked; program details and dates in [references/fee-stack-and-incentives.md](references/fee-stack-and-incentives.md).
- effort (descending): `migration incentive > behavior-based discount > revenue-exemption tier`
- supply-breadth value (descending): `revenue-exemption tier > migration incentive > behavior-based discount`
- steering value (descending): `behavior-based discount == migration incentive > revenue-exemption tier`
- efficiency: `revenue-exemption tier > behavior-based discount > migration incentive`
- **Default rung: a revenue-exemption tier** - zero or reduced share below a revenue threshold. The sourced programs cluster tightly around a $1M threshold (annual for most, lifetime for one), so anchor there rather than inventing a number; the honest variation to decide is annual-reset versus lifetime, a one-way tightening one platform made explicit. Default eligible developers in automatically: two major programs require manual enrollment, and a qualifying developer who misses it silently pays the full rate - an opt-in waiver changes paper, not behavior.
- **Promote behavior-based discounts** (a lower rate for a pricing or architecture choice - subscriptions over one-time, the platform's preferred framework over a legacy one) when you have a specific choice to steer developers toward. The `==` with migration incentives is argued: both pay for a named choice rather than a revenue level - one prospective, one retrospective.
- **Starved option: migration incentives** - waived or discounted fees for moving existing off-marketplace agreements or legacy-architecture apps onto the marketplace. Verification, attestation, and eligibility tooling make it the costliest shape, and it loses every efficiency round. A measurable back-book of existing off-platform revenue promotes it anyway: the sourced cases use differential rates as a migration lever worth more than the waived fees, pairing an accelerated benefit on the preferred path with a deferred increase on the legacy one. With no back-book to migrate, delete this shape from the menu rather than parking it at the bottom.
## 7. Payout design
Four cadences, ranked. The seven-platform payout comparison behind these rungs: [references/payout-and-tax-mechanics.md](references/payout-and-tax-mechanics.md).
- operator risk and effort (descending): `instant for a fee > rolling with reserves > monthly plus hold window > invoice-cycle consolidation`
- developer cash-flow value (descending): `instant for a fee > rolling with reserves > monthly plus hold window == invoice-cycle consolidation`
- efficiency: `monthly plus hold window > invoice-cycle consolidation > rolling with reserves > instant for a fee`
- **Default rung: monthly cycle plus an explicit hold window** sized to your refund/chargeback exposure - the norm across the sourced platform-as-MoR stores, whose holds run roughly thirty to sixty days. The `==` on value is argued: consolidation and monthly-plus-hold both land developer money in the same order of magnitude - weeks from sale to bank - so developers feel no difference between them.
- **Invoice-cycle consolidation** outranks the default on efficiency when question 2 is yes: app payouts riding the settlement cycle you already run cost near-zero marginal build. It only exists behind that precondition - without an existing cycle, delete it.
- **Promote to rolling payouts with reserves** (daily or weekly, with a percentage held on a rolling window against disputes) when you compete for supply against faster-paying alternatives - managed rails make this the fastest configurable shape.
- **Starved option: instant payouts for a fee.** Highest developer value, and it loses every round on operator risk and cost. A supply side of small developers for whom cash flow is the binding adoption constraint promotes it - as an option layered on a slower default, never as the default.
Two rules apply whatever the rung:
- The cash-flow lever developers actually feel is the hold window, not the minimum payout threshold. Sourced thresholds are small enough that active developers clear them every cycle, while real sale-to-bank lags run weeks past the headline "monthly" language. Publish the honest end-to-end timeline.
- Under marketplace-billed, the platform owns cross-border mechanics, such as payout currency conversion and rail choice, as part of the posture. Budget it, don't discover it.
## 8. The tax layer
Tax is a separate legal layer that can override the step 2 posture: US marketplace-facilitator statutes (in most sales-tax states since the 2018 _Wayfair_ decision) and the EU's deemed-supplier VAT rule can force the platform to collect and remit tax on transactions it doesn't bill. Marketplace-facilitator or deemed-supplier status is tax law; merchant of record is card-network status - they are legally distinct and don't always coincide, a distinction the sourced rails provider's own documentation states verbatim.
The design deliverable is a published, jurisdiction-by-jurisdiction split of who handles which tax, never a single "we handle tax" or "you handle tax" toggle. The sourced counter-examples make the point: one platform splits by country (platform-managed in some, developer-managed in others), another by tax regime (platform collects US sales tax, developers keep VAT liability).
Detail, legal framework summaries, and the silent-failure trap live in [references/payout-and-tax-mechanics.md](references/payout-and-tax-mechanics.md). This skill is not tax advice: route the published split through qualified counsel before shipping it.
## 9. Enforcement and notice
Every percentage instrument needs two enforcement commitments.
- **Anti-circumvention rule.** Routing billing around the marketplace to dodge the share is a terms violation, backed by a delisting path. The sourced precedent is high-revenue apps rerouting payments through an external processor and reversing only under delisting threat: circumvention pressure rises with the rate, and a rule without a removal path is a preference.
- **Notice period for fee changes, committed in writing.** The sourced pattern is six months for standard-rate changes, with unfavorable changes deferred and favorable ones accelerated. Publish it with the fee schedule.
## 10. Measurement
The design passes when three gates hold - self-set from the sourced rules above, since no industry pass-standard exists for a monetization-design artifact; iterate until all three pass:
1. The merchant-of-record posture is stated per app population, with tax, chargeback, and payout ownership each explicitly assigned - no transaction type left ambiguous.
2. Every fee instrument names its collection mechanism, its enforcement pair, and its notice commitment in writing.
3. The published developer docs state the end-to-end sale-to-bank payout timeline and the jurisdiction-by-jurisdiction tax split.
Post-launch, track:
- Net take revenue against billing-ops cost (the model's actual margin, not its headline rate)
- Median sale-to-bank days against the published timeline
- Dispute and chargeback rate, with losses attributed to whoever the posture assigned them
- Waiver coverage among eligible developers (an enrollment gap means the default-in rule failed)
- Tax-registration coverage of transaction volume
- Circumvention incidents, with their resolution
Baseline against your own first quarter: the platform figures in the references are context, not targets.
If your harness has persistent memory, record these decisions so later runs (fee changes, new jurisdiction, payout renegotiation) inherit them instead of re-deriving them:
- The chosen posture
- The rails bundle
- Each menu's chosen rung, with its promotion condition
- The published notice period
- The tax split
## Failure modes
- **Tax-layer/MoR confusion.** Choosing developer-billed and assuming tax went with it - facilitator and deemed-supplier obligations attach by law regardless of billing posture. Fix: step 8's published split, checked by counsel.
- **Silent zero-tax collection.** Automatic tax calculation with no active registration in a jurisdiction collects nothing, returns no error, and cannot be retroactively corrected. Verify tax collection as its own monitored system - watching payouts won't surface it.
- **Liability mismatch in the rails.** Picking rails dials à la carte outside the two coherent bundles leaves the platform carrying dispute losses it believes it pushed to developers. Fix: pick a bundle in step 3, never dials.
- **Rails capping the pricing menu.** Promising developers usage-based pricing before confirming the checkout supports it - the sourced enterprise marketplace's checkout doesn't. Fix: step 5's verify-before-publish order.
- **Circumvention with no enforcement pair.** A share with no anti-circumvention rule and delisting path erodes exactly as fast as the rate makes rerouting worth it.
- **The opt-in waiver.** A manual-enrollment exemption silently charges qualifying developers full rate; the program exists on paper and changes nothing. Default eligible developers in.
- **Rate changes without notice.** An unannounced increase burns partner trust the marketplace spent years buying; adopt the six-months-notice pattern before the first change, not after the backlash.
- **Modeling cash flow on headline language.** "Monthly payouts" reads as thirty days; sourced sale-to-bank lags run to twice that once holds and escrows stack. Publish and plan on the real number.
## Invocation examples
- "We're adding paid apps to our marketplace - should we bill customers ourselves or let developers charge directly, and what does each choice mean for tax and chargebacks?"
- "Our marketplace take-rate is set at 15% above a revenue threshold - design how it actually gets collected, paid out, and enforced."
- "Design our marketplace fee stack and payout schedule: rev-share collection, a small-developer waiver, and a sale-to-bank timeline we can publish to partners."
## References
- [references/mor-and-billing-rails.md](references/mor-and-billing-rails.md) - the merchant-of-record taxonomy table, charge patterns and account-configuration bundles, per-platform postures, and the tax-vs-MoR legal distinction.
- [references/fee-stack-and-incentives.md](references/fee-stack-and-incentives.md) - named fee stacks with figures and dates, the waiver-program taxonomy, and enforcement precedents.
- [references/payout-and-tax-mechanics.md](references/payout-and-tax-mechanics.md) - the seven-platform payout comparison, holds and thresholds, cross-border handling, and the US/EU tax-law frameworks.
See also, same collection:
- `samber/developer-platform-skills@app-marketplace-review` - the review and approval process a per-app review fee funds.
- `samber/developer-platform-skills@app-marketplace-listing-standards` - listing quality standards and the approval rubric, separate from what a listing costs.
- `samber/developer-platform-skills@app-marketplace-launch-marketing` - launch and co-marketing budgets for the marketplace, spend rather than revenue design.
- `samber/developer-platform-skills@partner-app-onboarding` - the partner journey where registration fees and seller agreements actually land on developers.