Capture an authorized payment
Captures the full amount of a successful, uncaptured authorization. Partial captures are not supported, and a payment that is already captured or being voided cannot be captured.
Authorization
basic Basic HTTP authentication
In: header
Path Parameters
Payment id (UUID v7)
Header Parameters
Optional client-supplied retry key (≤255 chars; UUID v4 recommended). Don't use sensitive data — emails, PANs, or other personal identifiers. Identical requests retried with the same key return the original response. Mismatched bodies return 422; in-flight duplicates return 409. Keys are scoped per merchant + endpoint and expire after 24 hours. On 5xx, retry with the same key: a retry cannot create a duplicate charge. The exception is a 500 that says the operation was accepted: do not retry it; poll the payment.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/payments/string/capture"{ "paymentId": "01928e1c-2a4d-7c8e-8b1a-1234567890ab", "status": "CAPTURED", "amount": 7200, "cardNumber": "555555xxxxxxxx4444"}{ "statusCode": 400, "message": "Some fields are invalid, please check the errors", "fieldErrors": { "amount": [ "amount must not be less than 1", "amount must be an integer number" ], "cardNumber": [ "cardNumber must be 12-19 digits with no spaces or separators" ] }}{ "statusCode": 401, "error": "Unauthorized", "message": "Invalid credentials"}{ "statusCode": 403, "error": "Forbidden", "message": "Merchant account can only process refunds and voids"}{ "statusCode": 404, "error": "Not Found", "message": "Payment not found: 01928e1c-2a4d-7c8e-8b1a-1234567890ab"}Authorize and capture a payment POST
Authorizes and captures the requested amount in a single operation. The request can optionally save the payment method for future use. When the issuer requires 3-D Secure, the call returns 201 with status REQUIRES_ACTION and a nextAction redirect for the customer; the final state settles asynchronously (poll GET /payments/:id).
Charge a saved payment method POST
Charges an active saved payment method again, with the customer present — an upsell after the checkout that saved it. The payment method must belong to the supplied customer and authenticated merchant. Every reuse is bounded by the card, whichever of its ids is charged (a checkout that saves a card again may return a new one): accepted for 24 hours after the card was first saved (never extended), at most 2 approved reuses per card (in-progress ones included; a decline does not count) and at most 5 attempts in all, counted together with reuses through the SDK, each for at most the amount of the payment that first saved the card; a reuse outside those bounds answers 409 with a `reason` and charges nothing. The gateway finds the payment that first saved the card itself. Depending on how your account processes payments, the charge either captures immediately (response status CAPTURED) or is accepted and collected asynchronously (response status PENDING — the payment settles to CAPTURED or DECLINED shortly after; follow it with GET /payments/{paymentId}). An issuer that asks for authentication declines the reuse (`Additional authentication required`): this flow has no way to show a challenge.