Paid feedback campaigns

New catalog purchases use immutable fixed-v2 terms. Previously funded weighted-v1 rounds retain their original amounts, weights, deadlines, compensation and settlement rules.

Offers

Founding is limited to 20 purchases or 14 days after the recorded launch, whichever occurs first; one per verified developer organization. Pending Checkout orders reserve availability. Only confirmed expiration releases those reservations. The server enforces the limit and never resets the window. $499 is a future experiment; the launch offer is $500.

Premium requires recorded deliverables, audience, schedule, named owner, included work and internal compensation commitments, operator approval and customer acceptance before Checkout. It renews until canceled before the next renewal. Cancellation preserves the paid month. There are no unused-budget credits, automatic refunds, advertised tester allowances or unlimited-work entitlements. Scope changes require an accepted amendment. Duplicate-charge corrections and provider-required reversals remain administrative exceptions.

Customer activation

1. Seed the published tasks with the paid dashboard or seed_paid_question. Standard packages require ten distinct safety-cleared zones.
2. Have the developer organization verified. For curated or premium, accept the operator-approved scope.
3. Purchase through hosted Stripe Checkout. Only a matching signed payment event funds the order; payment leaves the campaign paid/setup pending.
4. Connect the developer-owned MCP worker, save the target URL, exact build and delivery mode, and confirm the tasks.
5. Preview the experience. The connected worker records confirm_paid_campaign_preview for the matching URL/build.
6. Select Go live. Launch checks payment, payout funding, current preview, eligible invited participants, beta delivery and approval-required production.
7. Collect for seven calendar days from launch. Review and replace unfinished/invalid work without deleting accepted work.
8. Close after full delivery or the deadline, once reviews and appeals are resolved. Accepted evidence feeds the existing developer-owned campaign worker. Production promotion still needs separate approval.

MCP connects the workflow; it does not install overlays. The extension renders its own interface for extension users. Ordinary website visitors need the SDK installed in the target build.

Tester work and QA

Standard: No additional ADapptive ID check; payout-provider verification may apply. All paid testers must complete Stripe-required recipient onboarding, with an active payout capability, current eligible country/currency corridor and payout details. Holds, duplicate review, invitations, active membership and destination minimums still apply. Separate Stripe Identity permission, availability and corridor support do not gate Standard work or earned payouts.

Premium+: Opt-in tester assurance. Identity checked through Stripe; participation and feedback quality evaluated separately. These rounds additionally require provider-confirmed Identity VERIFIED and a supported Identity corridor at qualification, reservation and submission. This is separate from the developer packageKey premium subscription; package prices are unchanged. ADapptive stores provider references/status, not identity documents. Reviewed recovery links unify login methods under one platform person.

Developers select testerAssurance (STANDARD or IDENTITY_VERIFIED) before purchase; new orders explicitly default Standard. Assurance is immutable from creation and recorded in new purchase/participation terms and result snapshots. Existing rounds retain Identity-required assurance through the additive migration without rewriting accepted terms, funded amounts or historical snapshots. Subscription renewals inherit the original assurance. Later Identity failures never erase earned obligations; payout compliance, holds, funding and manual approval still govern disbursement. Unpaid participation remains unchanged.

A reservation, submitted response, requested revision, or unresolved rejection appeal occupies one place. Accepted work remains permanently counted. One platform person can earn once per zone and round across linked login methods. Standard does not guarantee one human per account or bot-free feedback. Accepted responses earn the fixed rate regardless of vote direction, reputation or implementation. Seven accepted $4 responses earn $28; replacing three unfinished assignments never reallocates that $28.

Review is due within two business days (UTC weekdays). Reasons, revisions and 48-hour appeals are retained. Identity and bank details are not proof that later responses are human-authored: task evidence, behavioral signals and reviewed duplicate reports also matter.

An administrator and one named, revocable delegate per campaign have unpaid QA access in the tester dashboard. Repeated QA never creates paid reservations, earnings, public votes, customer evidence or workflow thresholds. Additional paid capacity needs a funded scope; QA cannot increase it.

Refunds and subscriptions

For founding, entry and curated, replace undelivered places first. At close, each remaining undelivered place is refundable at its integer-cent share of the actual purchase price, not merely its unused tester reward. Stable place ordinals allocate remainder cents. Multiple refund records are supported, with idempotent request keys and a database cumulative cap. Partial delivery refunds do not cancel accepted earnings.

Premium entitlements are created once per successfully paid billing period. Failed renewal creates no new-period work and does not erase prior results or earned compensation. Cancellation is at period end. Invoice/subscription relationships, current provider retrieval and database uniqueness handle duplicate/out-of-order events.

Account isolation and manual payouts

Only acct_1UCbw2LxZ9fM8ShN is permitted. Configure ADAPPTIVE_STRIPE_ACCOUNT_ID, explicit ADAPPTIVE_STRIPE_MODE=test|live, separate billing and restricted payout keys, and separate account-specific billing/payout webhook secrets. The provider account and Balance mode are checked; generic Stripe credentials are never a fallback. See the API .env.example for the complete configuration.

All tester payouts are manual. An authorized operator prepares a batch of earnings eligible after the 48-hour appeal period, reviews each tester's amount/destination, and explicitly approves each transfer with a maximum USD debit including fees. Preparation never sends money. The server checks funding, fees/FX quotes, currency minimums, current recipient details and holds, and records the approving operator. Changed amounts require fresh approval. Undisputed items can proceed independently. Unsubmitted obligations can move into the next manual batch; uncertain submissions cannot. There is no automatic Friday payment schedule for new orders.

Checkout receipts do not imply available payout funds. Configure and explicitly fund ADAPPTIVE_PAYOUT_FINANCIAL_ACCOUNT using an owner-approved amount and source. Funding is manual too; do not enable recurring transfers. Funding shortages appear in the operations dashboard.

Stable submission keys, committed allocations and provider reconciliation prevent duplicate jobs from initiating duplicate payments. UNKNOWN/SUBMITTING outcomes need the original provider reference before any retry. Confirmed returns restore obligations. SUBMITTED, provider POSTED and tester-confirmed DELIVERED are distinct.

Historical weighted earnings can enter a manual batch only after their account, person and recipient bindings are verified and earlier manual attempts reconciled. Original allocations, postings and funded purchase terms remain unchanged. Any historical payment deadline remains an operator obligation; switching execution to manual does not amend it. Legacy provider reconciliation remains available for historical obligations.

The dedicated fiat worker only expires unpaid checkouts and reconciles already-submitted payments. Enabling it cannot prepare or submit payouts. Stripe's own bank-payout schedule is also manual; that setting is separate from tester transfers.

Operations and rollout

The new dashboard surfaces are /campaigns/paid, /tester/paid and /admin/paid. The public /campaign-brief form separates requested follow-up from optional, confirmed promotional consent. SMTP is disabled by default and needs a verified sender, TLS transport, postal address and public URLs. Withdrawal suppresses promotions; uncertain or stranded SENDING messages require SMTP-log reconciliation before retry.

Readiness update supplied with the approved September 6, 2026 plan: live billing and restricted payout keys have been saved in Mac Keychain and the production Coolify runtime only, and basic account/balance GET checks passed. These facts were not rechecked during this implementation. Billing Identity permission was not granted, and user-reported business verification does not establish Stripe Identity application approval. Premium+ remains dependent on Identity product approval, permissions, supported corridors and hosted acceptance.

Signed webhook delivery, isolated Stripe sandbox acceptance through the actual app, Financial Account funding, reviewed migration rollout and explicit live activation remain unverified. Standard does not require separate Identity activation, but all mandatory payout-provider verification and ordinary payment readiness checks still apply.

Run pnpm --filter @adapptive/api payments:preflight with securely injected environment variables before approval. It performs read-only checks without enabling commerce or transferring funds; passing does not replace sandbox acceptance tests. Deployment operators should follow deploy/payment-activation.md in the repository.

Keep PAID_CAMPAIGNS_LIVE_APPROVED=false, ADAPPTIVE_FIAT_WORKER_ENABLED=false and DEVELOPER_EMAIL_ENABLED=false until the documented rollout checks pass. Live mode additionally requires an account-verification evidence reference. No production deployment, live configuration, payout funding, recurring transfer or email delivery was performed during implementation. Actual Stripe sandbox scenarios remain a rollout dependency; local provider simulations are not sandbox proof.

See the operations guide and the repository's deployment and internal verification reports. The developer-owned worker remains documented in its repository README.