marketplace-payouts-review

マーケットプレイスの支払いレビュー

このスキルを使用して、マーケットプレイスの支払いを追跡可能で、公平かつサポート可能なものにし、返金や不正利用に対する耐性を高めます。

ワークフロー

1. マーケットプレイスの種類、関係者、取引モデル、手数料モデル、支払いスケジュール、リスク期間、プロバイダーの制約を特定します。
2. references/marketplace-payout-systems.md を読みます。
3. 購入者の支払い、プラットフォーム手数料、販売者の収益、保留中の残高、保留、返金、異議申し立て、調整、支払い、照合をマッピングします。
4. 台帳上の真実、表示残高、プロバイダーの状態、ポリシー上の判断、サポート用の証拠を分けて扱います。
5. 準備金／保留のガバナンスを定義します。理由コード、解除基準、SLA、担当者、証拠、エスカレーション、異議申し立ての経路を含めます。
6. 税務フォーム、該当する場合はフォーム名／ステータスの例、税務フォームのライフサイクル状態、源泉徴収、法定報告への引き継ぎ、制裁対象者のスクリーニング、国の利用資格、支払いプロバイダーの制約、送金失敗、マイナス残高を網羅します。
7. 支払いポリシーを具体化します。精算までの遅延、準備金の割合／期間、支払い頻度、最低金額、対応通貨、プロバイダー手数料、換算ポリシー、手数料の負担者を含めます。
8. 正式な支払い状態機械、手数料表、リスク管理策、コンプライアンス対応状況マトリックス、販売者向けダッシュボード／サポートワークフロー、信頼性指標、監査上の不変条件、照合チェックを作成します。
9. プロバイダーの障害、一部のみの支払いファイル、Webhook の再送、または財務部門による手作業の回避策について、運用状態を明示的に定義します。キュー登録済み、一時停止中、プロバイダー処理待ち、一部送信済み、失敗、再試行ブロック中、照合済み、解除済み、取り消し済み、手動レビュー中を含めます。
10. インシデント状態には、担当者、開始時の証拠、終了条件、プロバイダー／ステータスページのシグナル、サポートメッセージ、監査上の不変条件を付与します。復旧から得た知見には、プロバイダーの SLA に関する証拠、モニタリング、インシデント後の管理策の修正、将来のレジリエンス向上策を含めます。
11. 不正利用に対する保留では、シグナルと結論を分けて扱います。返金の急増、自作自演の購入、レビュー操作、関連アカウント、支払い最低額を狙った収益稼ぎ、正当なローンチでの成功、誤検知、購入者保護に関するリスク、回収／マイナス残高への対応経路、一部準備金、解除基準、異議申し立ての証拠、レビュアーの品質保証を区別します。

使用しない場合

• 主な目的が、販売者の収益や支払いではなく、購入者のチェックアウト、支払いの取り込み、または製品の利用権付与である場合は、payment-platform-readiness を使用します。
• 残高、保留、回収、支払い権限に影響しない、コンテンツ／リスティングに関する異議申し立てには使用しないでください。

情報源の確認

• 使用時点で、プロバイダー、税務当局、制裁、国の利用資格、報告要件に関する最新情報を、信頼できる情報源で確認します。
• 管轄地域、発効日／アクセス日、情報源の管理者、未解決の専門家レビュー上の判断を明記します。このスキルに記載されたフォーム名や基準値を、現行の法的助言として扱ってはなりません。

ガードレール

• 表示残高を台帳上の真実として扱ってはなりません。
• リスクを明示的に受け入れない限り、返金、不正、チャージバック、配送に関するリスク期間内にある資金を支払ってはなりません。
• 理由、証拠、異議申し立て／サポート経路を示さず、不透明な保留や回収を行ってはなりません。
• 税務／コンプライアンスへの引き継ぎ、プロバイダーの利用資格に関する制約、クリエイターから確認できるサポート状況が整っていないまま、全世界への支払いを承認してはなりません。
• 税務や制裁に関する助言は行わないでください。管轄地域、フォーム、源泉徴収、報告、制裁に関する判断は適格な担当者に委ねつつ、プロダクトの状態、証拠、支払いを妨げる条件は定義してください。

出力形式

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>