# Shows capture details Endpoint: GET /capture/{id} Version: 2.0 Security: accountId, apiKey ## Path parameters: - `id` (string, required) Resource Identification ## Response 200 fields (application/json): - `transaction_key` (string) A customizable text field for users to input their own identifier for the resource. This can be any string that helps the user uniquely identify or reference the resource in their own system. - `capture_date` (string) The date when the action should be executed. This field specifies the exact day for capturing the transaction, formatted as "YYYY-MM-DD" (e.g., "2024-06-30"). It is optional and defaults to the current date if not specified. Example: "2025-07-10" - `account` (object) An object within the capture request that specifies the details of the account to which the funds should be routed, different from the initially requested account. This ensures that the captured funds are directed to the correct destination as per the specific routing requirements. - `account.id` (string) A unique identifier for the resource. While typically formatted as a UUID (Universally Unique Identifier), it can also be in other formats as defined by the user. This field ensures the resource can be distinctly recognized and referenced. Example: "c0151524-79e6-437a-a549-2ddd7c95e245" - `descriptive` (string) A text field that describes the transaction as it will appear on the end user's account statement. This is typically used to provide clear, recognizable information about the payment, such as "Payment of Invoice Nº 1982652" or "Ticket for Queen". - `value` (number) The monetary amount requested for the transaction. This field is formatted as a double, and will be rounded to two decimal places (e.g., "100.00"). The value must be greater than or equal to 0.5. Example: 38.98 - `status` (any) Indicates the current status of the capture. Possible values include: - delayed: The capture attempt is scheduled for a future date and does not require further user interaction due to prior consent (e.g., authorization or frequent). - waiting: The payment instruction has been given, but the chosen payment method requires confirmation from an external entity before the status of the operation is finalized. - pending: The capture is pending user completion. - success: The capture has been completed successfully. - failed: The capture could not be completed due to an error or issue. - refunded: The capture has been refunded. This field provides a clear indication of the current state of the capture, helping users understand its progress and outcome. Enum: "delayed", "waiting", "success", "pending", "failed", "refunded" - `payment_type` (any) Specifies the type of payment processed. Possible values include: - Single: A one-time payment transaction. - Frequent: A payment that occurs regularly but is not part of a subscription (e.g., recurring manual payments). - Subscription: A recurring payment that is part of a subscription plan, automatically processed at regular intervals. This field helps to categorize and manage different payment methods based on their frequency and nature. Enum: "single", "frequent", "subscription" - `payment_id` (string) A unique identifier for the resource. While typically formatted as a UUID (Universally Unique Identifier), it can also be in other formats as defined by the user. This field ensures the resource can be distinctly recognized and referenced. - `force_3ds` (boolean) A boolean field indicating whether to enforce 3D Secure (3DS) authentication for the transaction. If set to true, 3DS authentication will be required, adding an additional layer of security by verifying the cardholder's identity during the transaction process. If set to false, 3DS authentication will not be enforced. This field helps enhance security and reduce fraud in online payments. - `refunds` (object) The Refund object contains information required to process a refund. For payment methods that do not support direct refunds, additional fields are required to facilitate a fallback to a bank transfer. This ensures that the customer receives their refund even when the original payment method does not facilitate refunds. - `refunds.status` (any) Indicates the current status of the refund. Possible values include: - waiting: The payment instruction has been given, but the chosen payment method requires confirmation from an external entity before the status of the operation is finalized. - pending: This is the initial state, and it means that the refund is queued. - success: The refund has been completed successfully. - failed: The refund could not be completed due to an error or issue. This field provides a clear indication of the current state of the refund, helping users understand its progress and outcome. Enum: "waiting", "pending", "success", "failed" - `refunds.transaction_key` (string) Your internal key identifying this refund. Example: "example key" - `refunds.iban` (string) (Required for fallback): The International Bank Account Number of the account to which the refund will be sent. This field is used to uniquely identify the recipient's bank account across international borders. - `refunds.email` (string) (Required for fallback): The email address of the account holder. This field is used for communication purposes, including sending notifications about the refund stat. - `refunds.phone` (string) (Required for fallback): The contact phone number of the account holder, including the country code indicator (e.g., "+351"). This field is used for communication purposes, such as contacting the account holder for verification. - `refunds.account_holder` (string) Bank account holder name. - `splits` (array) - `splits.split_key` (string) A customizable text field for users to input their own identifier for the resource. This can be any string that helps the user uniquely identify or reference the resource in their own system. Example: "Example Key" - `splits.split_descriptive` (string) A text field that describes the transaction as it will appear on the end user's account statement. This is typically used to provide clear, recognizable information about the payment, such as "Payment of Invoice Nº 1982652" or "Ticket for Queen" Example: "Descriptive Example" - `splits.account` (object) The account to which the funds should be routed. This field is used to specify the destination account for the split payment, ensuring that the correct recipient receives their designated portion of the funds. - `splits.value` (number) The monetary amount requested for the transaction. This field is formatted as a double, and will be rounded to two decimal places (e.g., "100.00"). The value must be greater than or equal to 0.5 Example: 10.89 - `splits.clearing_date` (string) The clearing date refers to the specific date when a financial transaction is finalized and the funds are transferred from one account to another. This is the point at which the payment is officially completed and the amount is debited from the payer's account and credited to the payee's account. - `splits.clearing_period` (string) The clearing period must follow the format 1Y, 10W or 30D. Y for Years, W for weeks, D for days. Minimum is 7 days, maximum is 1 year. - `splits.margin_account` (object) The account to which the margin value should be routed. This field specifies the destination account for the margin portion of the funds, ensuring that the correct recipient receives the designated margin value. - `splits.margin_value` (number) The monetary amount designated as the margin in a split payment. This field is formatted as a double, and will be rounded to two decimal places (e.g., "10.00"). The value must be less than the total value of the split. This specifies the portion of the funds that should be routed to the margin account. Example: 10 - `splits.status` (any) The status of the Split. Enum: "waiting", "success" - `splits.reverts` (array) - `error` (object) Represents the reason why an operation failed. It includes a human-readable message describing the issue, which can help diagnose and resolve the failure. - `error.message` (string) Represents the reason why an operation failed. It includes a human-readable message describing the issue, which can help diagnose and resolve the failure. ## Response 401 fields (application/json): - `status` (string, required) - `message` (array, required) An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request. ## Response 403 fields (application/json): - `status` (string, required) - `message` (array, required) An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request. ## Response 404 fields (application/json): - `status` (string, required) - `message` (array, required) An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request. ## Response 412 fields (application/json): - `status` (string, required) - `message` (array, required) An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request. ## Response 429 fields (application/json): - `status` (string, required) - `message` (array, required) An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request. ## Response 500 fields (application/json): - `status` (string, required) - `message` (array, required) An array of human-readable messages included in the response. These messages provide detailed information about the success of the operation or explain the reasons for any failure. This field is always present in the response to ensure clarity and transparency regarding the outcome of the API request.