Skip to main content
POST
Void an authorization

Authorizations

Authorization
string
header
required

Merchant API key (fp_live_* for live, fp_test_* for sandbox) or an admin-tier JWT (company admin or root admin). Non-admin JWTs are rejected with 403; live API keys additionally require the merchant's API access to be enabled.

A company admin, company token or partner token also needs the role grant for the action, or gets 403: gateways.view, .create, .update or .delete (or the matching apm.* grant) for gateway configuration, transactions.update for purchase, authorize, verify, capture, void and credit, and transactions.view to read transactions. API keys, root admins and droplet tokens are not checked against roles.

Headers

Idempotency-Key
string

Optional client-generated key (UUID recommended) used to deduplicate retries: a stored response replays for up to 24 hours. A request whose outcome is unknown holds its key until support resolves it, and every retry under it answers 409 until then. Once support confirms that the request moved money, the key stays held for 24 hours; once support confirms that it did not, the key can be used again.

The key is bound to the exact request that first used it: the method, path and query string, Content-Type, body bytes, and whether a live or sandbox key sent it. Keep the serialized request and resend it unchanged, byte for byte, to retry; the retry replays the first response with X-Idempotent-Replayed: true. Any other request under the key answers 422 and does not run, so a key cannot be reused across operations, resources or amounts. Use a new key only for a new request. A client that cannot reproduce the original request must confirm the outcome by reading the transaction, not retry under a new key, which could move the money a second time.

Every authenticated caller is guarded: API keys, JWTs, and company, partner, public and droplet tokens. A retry must use the same kind of credential as the request it retries, because an API key and any other credential never share a key.

A concurrent retry while the first request is still in flight returns 409. The cache stores whatever the first execution returned, including error responses such as 404 or 422. Keys longer than 255 characters are rejected with an unhandled 500. A key must not end with :lock, which is reserved; such a key answers 422 and the request does not run. A response already cached under such a key, from before the suffix was reserved, still replays on a retry of its request.

Maximum string length: 255

Path Parameters

id
string
required

Transaction slug (authorization to void)

Body

application/json
transaction
object

Response

Void completed

data
object
required
meta
object
required