# Access, execution, and completion (/guides/concepts/access-execution-completion)

This is the merchant-side view of a paid request. It explains responsibility; the [paid request lifecycle](/guides/concepts/paid-lifecycle/) explains the full payer exchange.

| Step | Recuut | Your application |
| --- | --- | --- |
| Access | Applies the active payment policy and checks payment proof. | Validates input and identifies the protected resource and revision. |
| Execution | Keeps the request’s payment state. | Performs the protected work and reports revision-required values. |
| Completion | Finishes the transaction and records the outcome. | Releases the result only after successful completion. |

Recuut owns pricing, accepted payment methods, settlement coordination, and payout policy. Your application does not accept a replacement price or payment method from caller input.

At access, preserve a retryable `402` response and its `PAYMENT-REQUIRED` header exactly. At completion, keep the result private unless the transaction succeeds. A pending completion is not a successful payment.

Completion may include safe execution metadata: the HTTP status, elapsed milliseconds, response media type, and response size in bytes. recuut does not accept the response body, response headers, or exception message. A maintained framework integration reports a returned `4xx` or `5xx` response as failed and does not settle the transaction.

| Recuut response | Server branch |
| --- | --- |
| Access `402` | Return the JSON body and `PAYMENT-REQUIRED`; do no protected work. |
| Access `200` with no transaction ID | Perform and return the free result. |
| Access `200` with a transaction ID | Perform the work, retain the result privately, then call completion. |
| Completion `200` + `succeeded` | Return the result with `PAYMENT-RESPONSE`. |
| Completion `202` or a non-success status | Do not return the result; keep the transaction ID for reconciliation. |

If your framework has a Recuut integration, it manages this boundary for you. A direct HTTP integration performs the same two Merchant API calls explicitly.

[Build a direct HTTP integration →](/guides/http/)
