Execution AVAILABLE
Doing the thing, and knowing what happened — including when nobody knows.
What it is
- On an ALLOW, the Gateway can perform the action against a configured merchant and record the outcome: SUCCEEDED, FAILED or UNKNOWN.
Why it exists
- The interesting failure is not an error. It is a timeout: the request may have arrived, been performed, and the response lost. Systems that call that FAILED and retry produce two purchases.
How it works
- Send an `execution` block with a nonce. The nonce binds one execution to one action.
- A repeat with the same nonce replays the stored outcome and calls nothing.
- An UNKNOWN holds the budget and waits for a person to establish what happened.
Who uses it
- Anybody integrating a payment, a booking or anything else that is not free to repeat
Security boundary
- UNKNOWN ≠ FAILED, and there is no blind retry.
- There is no `url` field. The caller names a merchant; where that points is the deployment's configuration.
- A resolution is somebody's statement about what they checked, recorded as such.
Example flow
A timeout
- The merchant accepts the request and the connection drops before the response.
- The execution is UNKNOWN. The budget stays held.
- An operator checks the merchant's own records and finds the order was created.
- They resolve it as SUCCEEDED with a note. Nothing was retried, and nothing was bought twice.
Current status
| Capability | Status | Where |
|---|---|---|
| See executions and filter by status Listing and filtering. Only an execution needing reconciliation offers an action, and only to ADMIN. | READ ONLY | /projects/:id/executions |
| Reconcile an UNKNOWN execution | AVAILABLE | /projects/:id/executions |
Related API
POST /v1/authorizePOST /v1/projects/:id/executions/resolve