Payments Built for Agent-to-Human Work

Payments

This page exists to explain the money lifecycle separately from task status. It should answer that intent directly and avoid borrowing generic copy from unrelated HumanTask API pages.

Task Budget Is an Input

A requester should declare the maximum amount it is willing to spend before matching. That gives the platform a hard boundary for autonomous or API-created tasks.

Funding State and Task State Are Different

A task can be created before funds are fully captured, accepted while payment is authorized, or completed while approval is pending. Keeping these states separate prevents confusing operational status with money movement.

Worker Reward

The worker should see the compensation tied to the task scope and any approved expenses before acceptance. Changes in scope should not silently change the work without revisiting the commercial terms.

Platform Revenue

HumanTask API can earn through a platform fee, enterprise pricing, premium routing or other marketplace services. The public page should describe the model clearly once rates are finalized rather than inventing placeholder percentages.

Approval and Revision

When evidence meets the task definition, payment can be released. If a required item is missing, the requester can ask for a bounded revision instead of restarting the entire job.

Refund and Failure Paths

Closed locations, impossible access and requester cancellation need commercial rules distinct from successful completion. Those rules should be tied to task state and documented before scale.

Controls for Machine Buyers

API projects should support spend caps, allowed currencies, task-size limits and audit records so an AI agent cannot create uncontrolled financial exposure.

Next Action

For Payments, use this page as the decision point for its specific intent. Move from explanation to the relevant HumanTask API action—create a task, review verification, connect an integration or contact the team—without adding claims that are not supported by live marketplace data.

Page-Specific Focus

Treat Payments as a decision page, not a catch-all. Its specific purpose is to explain the money lifecycle separately from task status; adjacent information should be linked rather than duplicated.

Future First-Party Content

Do not add invented statistics to Payments. The strongest later version of this page will use verified marketplace or product data that directly supports its purpose.

Conversion Path for Payments

The page should lead to a next action that matches its intent instead of showing every possible CTA. For Payments, the visitor should move toward the most relevant route after understanding explain the money lifecycle separately from task status. Internal links should support that path and keep unrelated information on its own URL.

Content Maintenance

Review Payments when the product changes one of these related areas: Task Budget Is an Input, Funding State and Task State Are Different, and Worker Reward. Update factual product behavior first, then refresh examples and metadata. Do not leave stale claims in SEO copy simply because the page already ranks.