Skip to main content
After Attesso returns an authorization, your backend must gate execution, respect the deadline, and close the reservation exactly once.

​
Gate execution

Do not use the HTTP status, decision, or state alone. Execute only when the latest representation has:
If your execution starts asynchronously, ensure the external capability cannot act after execute_before.

​
Commit after acceptance

Commit means the executor accepted the authorized action. It does not mean a virtual card was created, a payment settled, or a service was later fulfilled.
A successful commit changes the authorization to COMMITTED and atomically changes the mandate to CONSUMED.

​
Cancel only when execution is impossible

Before cancellation, prove through your own controls that the external action can no longer occur. Disable any card, token, job, or provider capability first.
Use NEVER_BECAME_POSSIBLE only when no external execution capability ever became usable.

​
Retry safely

All lifecycle writes require an idempotency key.
  • Retry the same logical operation with the same key and identical canonical input.
  • Generate a new key for a new logical operation.
  • Reusing a key with different input returns a conflict.
  • A replay returns the same resource identity in its current state.

​
Resolve uncertain outcomes

1

Stop new execution

If a network failure makes the result uncertain, do not start another action.
2

Read the authorization

Call GET /v1/authorizations/{authorization_id} and reconcile its current state.
3

Replay when safe

Retry the original commit or cancellation with the same idempotency key and body.
4

Escalate terminal conflicts

A committed, cancelled, or expired authorization cannot transition to another terminal state. Treat a conflicting terminal outcome as an operational incident.
Never cancel or allow a reservation to expire while an external credential can still execute. Attesso records your disposition assertion but cannot independently disable that credential.