Paid feedback campaigns

New purchases use fixed-v2 rewards and immutable commerce-v4 purchase 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.

Curated, Custom and Enterprise require operator-approved scope and customer acceptance before Checkout. Custom and Enterprise record deliverables, audience, schedule, named owner, included work and internal compensation commitments. New campaigns are one-time purchases. There are no unused-budget credits, advertised tester allowances or unlimited-work entitlements. Scope changes need an accepted amendment; historical subscription terms are preserved.

Customer activation

1. Start with a brief. Founding and Entry may purchase before binding their ten standard tasks; the tasks must be configured before launch. Other offers use the agreed scope and safety-cleared zones.
2. Founding requires verified developer-organization eligibility. For Curated, Custom or Enterprise, 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 a launch date in your local timezone. Collection starts automatically on or after that time once payment, payout funding, current preview, eligible invited participants, beta delivery and approval-required production checks pass. Blocked launches stay setup-pending with a visible reason. You may reschedule before launch.
7. Collect for seven calendar days from launch. Review and replace unfinished/invalid work without deleting accepted work.
8. Close after full delivery once reviews and appeals are resolved. For new orders, incomplete delivery enters replacement work after the initial collection window; it is not silently declared fulfilled. 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 Custom package (internal packageKey premium); 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

New commerce-v4 orders retain purchased delivery until fulfilled. Refund requests are reviewed case by case by an administrator; scheduling changes and campaign commencement do not automatically entitle a buyer to a refund. Duplicate charges and required reversals retain correction mechanisms. A full refund stops new assignments; refunds never erase accepted work or earned compensation.

Historical purchases retain their original refund commitments, including proportional integer-cent refunds for undelivered places where promised. Multiple refunds retain idempotent request keys, original payment references and a cumulative cap at the actual charge.

Historical Premium and Enterprise subscriptions remain billed monthly until canceled before renewal; new Custom and Enterprise purchases are one-time. Each successful paid period creates one scoped campaign entitlement. Failed renewal creates no new-period work and never deletes earlier results or compensation. Cancellation preserves the paid period; already owed delivery remains recorded.

Account isolation and manual payouts

Production uses only acct_1UCbw2LxZ9fM8ShN. A separately provisioned designated sandbox is permitted only in test mode with its own isolated database and credentials. 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.

Billing maintenance expires unpaid checkouts independently. The fiat maintenance path only 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.

Billing and fulfillment have independent approval gates. The billing-only preflight is pnpm --filter @adapptive/api payments:preflight --billing; the full preflight remains available without that flag. Billing still requires account/mode checks, working signed billing webhooks and real Checkout, refund and subscription acceptance. Missing payout funding or optional Identity approval does not prevent receiving payments, but paid work remains blocked until fulfillment checks pass.

ADAPPTIVE_STRIPE_BILLING_LIVE_APPROVED and its billing evidence reference control new purchases. Turning purchases off does not stop signed payment/refund/subscription reconciliation. PAID_CAMPAIGNS_LIVE_APPROVED retains the fulfillment gate. Billing maintenance, campaign scheduling, fiat maintenance and email have separate switches. No worker may submit tester payouts.

See the operations guide and the repository's activation report for verified deployment status. Local simulations are not Stripe sandbox acceptance. Tax collection requires separately verified registrations and configuration; billing activation does not automatically enable Stripe Tax.