# How Recuut works (/guides/concepts/how-recuut-works)

Recuut sits between a seller application and a payer for the payment part of a request. The **merchant** is the seller account. The **payment boundary** is the point where your server asks Recuut whether it may release a protected result. An **agentic wallet** is software that can read payment instructions, approve them under a limit, and retry the request.

| Participant | Job |
| --- | --- |
| Your application | Identifies the resource, validates input, performs the protected work, and reports its outcome. |
| Recuut | Owns prices, accepted payment methods, settlement coordination, payout policy, and transaction records. |
| Payer or agentic wallet | Requests the resource, follows x402 payment instructions when needed, and retries with payment proof. |

This separation matters. A caller cannot choose the merchant account, price, environment, or payment method through request input. Your server keeps the merchant API key. The payer only receives the payment instructions needed for its own request.

| Order | Request flow |
| --- | --- |
| 1 | The payer calls your protected endpoint. |
| 2 | Your server asks Recuut for access. |
| 3 | Recuut either allows free access or returns payment instructions. |
| 4 | The payer’s wallet pays and retries; your server performs the work. |
| 5 | Your server completes the transaction and releases the result only after success. |

Recuut supports an API response or another digital item. A resource identifies the item. A published revision explains the values that your application reports after execution. A price determines what the payer is asked to pay.

[Follow one paid request →](/guides/concepts/paid-lifecycle/) · [Learn about resources and revisions →](/guides/concepts/resources-revisions/)