Create an authorization
Authorizes (holds funds on) the payment method for amount_cents without
capturing. Creates an authorize transaction and returns it with 201;
capture it later via the transaction capture endpoint or release it with
void. A 201 means the request was processed — read the outcome from
data.status (success, declined, or error). Pass an Idempotency-Key
header to make retries safe. Returns 404 when the gateway is not found,
or a referenced payment_method_id is unknown or owned by a different
merchant, 409 on an in-flight duplicate key, and
422 when the request fails validation. On success, API-key-authenticated
requests emit a payment.completed webhook.
Authorizations
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.
Headers
Optional client-generated key (UUID recommended) used to deduplicate
retries. The first request with a given key executes normally; a retry
with the same key replays that first response with
X-Idempotent-Replayed: true for up to 24 hours. A concurrent retry
while the first request is still in flight returns 409.
The response cache is keyed on the authenticated merchant and this key ONLY — not on the operation, path, or request body. Use a fresh, unique key per logical request: reusing one key across different operations (for example a purchase and then a capture) replays the first operation's cached status and body instead of performing the second.
Idempotency applies to API-key-authenticated requests only. On
JWT-authenticated requests the header is accepted but ignored — no
deduplication, no 409, no replay. 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.
255Path Parameters
Gateway slug