Marketplace payouts review
Design and audit marketplace payout, earnings, fee, revenue share, seller balance, creator payout, refund, chargeback, hold, clawback, split payment, ledger, tax/compliance handoff, payout support, and dispute flows for creator marketplaces, app/plugin stores, gig marketplaces, game marketplaces, affiliate programs, and two-sided platforms. Use when money moves from buyers through the platform to sellers or creators.From its SKILL.md
npx -y skills add SylphxAI/skills --skill marketplace-payouts-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.4 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Marketplace Payouts Review
Use this skill to make marketplace payouts traceable, fair, supportable, and resilient to refunds or abuse.
Workflow
- Identify marketplace type, parties, transaction model, fee model, payout schedule, risk window, and provider constraints.
- Read
references/marketplace-payout-systems.md. - Map buyer payment, platform fee, seller earnings, pending balance, holds, refunds, disputes, adjustments, payout, and reconciliation.
- Separate ledger truth, displayed balances, provider state, policy decisions, and support evidence.
- Define reserve/hold governance: reason codes, release criteria, SLA, owner, evidence, escalation, and appeal path.
- Cover tax forms, named form/status examples when relevant, tax-form lifecycle states, withholding, statutory reporting handoff, sanctions screening, country eligibility, payout provider constraints, failed transfers, and negative balances.
- Make payout policy concrete: clearing delay, reserve percent/duration, payout cadence, minimum threshold, supported currencies, provider fees, conversion policy, and fee responsibility.
- Produce formal payout state machine, fee table, risk controls, compliance readiness matrix, seller dashboard/support workflow, trust metrics, audit invariants, and reconciliation checks.
- For provider outages, partial payout files, webhook replays, or manual finance workarounds, name operational states explicitly: queued, paused, provider-pending, partially-submitted, failed, retry-blocked, reconciled, released, reversed, and manual-review.
- For incident states, attach owner, entry evidence, exit gate, provider/status-page signal, support message, and audit invariant; recovery learning must include provider SLA evidence, monitoring, post-incident control fixes, and future resilience work.
- For abuse holds, segment signals from conclusions: distinguish refund spikes, self-purchases, review manipulation, linked accounts, payout-threshold farming, legitimate launch winners, false positives, buyer-protection exposure, clawback/negative-balance paths, partial reserves, release criteria, appeal evidence, and reviewer QA.
When not to use
- Use
payment-platform-readinesswhen the primary job is buyer checkout, payment ingestion, or product entitlement rather than seller earnings and payout. - Do not use for a content/listing dispute that does not change balances, holds, clawbacks, or payout authority.
Source verification
- Verify current provider, tax-authority, sanctions, country-eligibility, and reporting requirements from authoritative sources at use.
- Label jurisdiction, effective/access date, source owner, and unresolved qualified-review decision; never treat a named form or threshold in this skill as current legal advice.
Guardrails
- Do not treat displayed balance as ledger truth.
- Do not pay out funds that remain within a refund, fraud, chargeback, or delivery-risk window unless risk is explicitly accepted.
- Do not make opaque holds or clawbacks without reason, evidence, and appeal/support path.
- Do not approve global payouts without tax/compliance handoff, provider eligibility constraints, and creator-visible support status.
- Do not give tax or sanctions advice; route jurisdiction, form, withholding, reporting, and sanctions decisions to a qualified owner while still defining product states, evidence, and payout blockers.
Output format
Marketplace/payout context:
Fee and risk model:
Payout policy:
- Cadence / clearing delay / minimum threshold / currencies / provider fees:
Payout flow:
- <state> -> owner, evidence, user message
Formal state machine:
- <from_state> -> <event> -> <to_state>, owner, evidence, exit gate, ledger effect, audit invariant
- Outage/retry branch when relevant: queued -> paused -> provider-pending/partially-submitted -> failed/retry-blocked/manual-review -> reconciled -> released or reversed
Decision table:
- <scenario> -> balance action, payout action, support action
Seller dashboard and support workflow:
- <seller-visible status> -> explanation, evidence, next action, SLA, support/admin control
Reserve/hold governance:
- <hold/reserve type> -> trigger, scope, release criteria, SLA, owner, appeal/support path
- Abuse holds -> signal, affected earnings, reserve percent/duration, buyer-protection exposure, clawback/negative-balance rule, false-positive release criteria, appeal evidence, reviewer QA
Compliance/provider readiness:
- <tax form / withholding / statutory reporting / sanctions / country / provider constraint> -> product state, payout effect, evidence, support message, qualified-review owner
- Named examples to verify, not legal advice: W-9, W-8BEN, W-8BEN-E, 1099-K, 1042-S, VAT/GST tax ID or local equivalent
Ledger/events:
- <event> with properties
Audit invariants:
- <invariant that must always hold across ledger, balances, provider state, and support evidence>
Open risks:
- <risk> -> mitigation
Trust metrics:
- <creator trust, support load, reversal loss, payout latency, reconciliation health metric>