Concepts

Access, execution, and completion

See the boundary between Recuut and your application during a paid request.

This is the merchant-side view of a paid request. It explains responsibility; the paid request lifecycle explains the full payer exchange.

StepRecuutYour application
AccessApplies the active payment policy and checks payment proof.Validates input and identifies the protected resource and revision.
ExecutionKeeps the request’s payment state.Performs the protected work and reports revision-required values.
CompletionFinishes 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 responseServer branch
Access 402Return the JSON body and PAYMENT-REQUIRED; do no protected work.
Access 200 with no transaction IDPerform and return the free result.
Access 200 with a transaction IDPerform the work, retain the result privately, then call completion.
Completion 200 + succeededReturn the result with PAYMENT-RESPONSE.
Completion 202 or a non-success statusDo 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 →