An authorization reserves funds on a card without moving them. A capture moves them. Splitting the two is the right shape whenever you charge before you know the final amount, or before you can deliver.
The usual cases are shipping physical goods, orders that may be partly out of stock, and anything where the total can change between checkout and fulfillment.
- Your
Api-KeyandClient-Id— see Authentication - A processor integration configured for cards
POST /v1/transactions with type set to AUTH. The request is identical to a sale apart from that one field.
Keep the id from the response. Every later step quotes it in the URL.
POST /v1/transactions/{id}/capture, where {id} is the authorization's id.
The body is small: amount is required, tip is optional. There is no type field. It was removed from this request, and sending one is a common carry-over from older integrations.
There is no tax_amount either. Send it on the authorization, and the capture reports the same value. See Record tax.
The capture record. It is a new transaction whose reference_transaction_id points at the authorization it captured. expiry is null because expiry is not echoed back on capture responses. The capture joins the open batch and settles at the next batch close, so batch_id is null until then. tax_amount is the $5.00 sent on the authorization it captured, because a capture request has no tax_amount of its own.
{ "id": "TRANSACTION-01KEW35B8QP4M2X9YHFT0KDN47", "reference_transaction_id": "TRANSACTION-01KEW32V6YNV11T336VEDKL123", "type": "CAPTURE", "result": "APPROVED", "client_id": "CLIENT-01KFDKXMQ637EKEAY410MSQSXB", "client_dba": "Acme Jewelry", "integrations": [ "TSYS" ], "response_code": "00", "response_description": "Approved", "batch_id": null, "is_settled": false, "time_created": "2026-07-15T16:08:23Z", "amount": 10000, "tip": 0, "tax_amount": 500, "currency": "USD", "payment_method": { "type": "CARD", "truncated_pan": "****-****-****-5439", "payment_token": "CARD_TOKEN-01KFDKXMQ637EKEAY410MSQSXB", "expiry": null, "first_name": "John", "last_name": "Doe", "entry_method": "keyed", "auth_code": "123456", "retrieval_reference_number": "000000603076", "card_type": "UNKNOWN", "card_brand": "Visa", "cvv_result_code": "M" }, "recurring": false, "initiator": "CUSTOMER", "network_transaction_id": "000000004271003", "metadata": { "order_id": "ORD-10434", "sales_channel": "web", "customer_reference": "cust-8891" } }
Three things about that response surprise people.
- The capture is its own transaction, with its own
idand atypeofCAPTURE. It is not the authorization updated in place. reference_transaction_idpoints back at the authorization. That is the link between the two.expiryis null. Card expiry is not echoed on a capture response.
The capture joins the open batch, and the funds settle at the next batch close. batch_id stays null until then.
Send a smaller amount. This is the normal way to handle an order that ships short, or a final total below the estimate.
{
"amount": 7500
}You cannot capture more than you authorized. If the total has gone up, the authorization no longer covers it — release it and authorize the new amount.
If the order is canceled before you ship, void the authorization so the cardholder's funds are freed rather than left on hold until the issuer expires them.
A void takes only type. It always releases the full amount, so there is no amount field to send.
Cancel, void, and refund covers the difference between voiding and refunding, and which one applies when.
An uncaptured authorization does not last forever. The issuer decides how long, and it varies by card brand and issuer — commonly a few days to about a month.
The gateway does not expire authorizations on its own, and it does not notify you when an issuer does. If you are not going to capture, void explicitly rather than letting the hold lapse.