# List captures Endpoint: GET /capture Version: 2.0 Security: accountId, apiKey ## Query parameters: - `cursor` (string) The cursor parameter is used for pagination. It specifies the pointer to the start of the next set of results in a sequence of paginated data. Typically, this is a unique identifier of the last item from the previous response. If not provided, the API fetches the first page of results. - `limit` (number) The limit parameter is used for pagination. It specifies the maximum number of entries to return in a single page of results. Max 100. - `created_at` (string) Filter records by creation datetime interval in UTC. Maximum allowed range is 30 days. Format: interval(YYYY-MM-DD HH:MM,YYYY-MM-DD HH:MM). Example: "interval(2006-01-02 15:04,2006-01-02 15:04)" - `updated_at` (string) Filter records by update datetime interval. Maximum range of 30 days. Format: interval(YYYY-MM-DD HH:MM,YYYY-MM-DD HH:MM) Example: "interval(2006-01-02 15:04,2006-01-02 15:04)" ## Response 200 fields (application/json): - `metadata` (object) An object containing additional information about the response. It includes details that help manage and navigate the retrieved data. - `metadata.next_cursor` (string) Provides the cursor for the next set of records. This value should be used as the cursor parameter in subsequent requests to continue paginating through the data. If the cursor is an empty string or null, it indicates that there are no more results. To retrieve all available results, continue making subsequent requests until next_cursor is empty or null. Example: "lL_j7ilk7rc" - `metadata.count` (number) The total number of records in the current response. This field indicates the number of items returned in the current set of results. Example: 10 - `data` (array) The Capture object contains all the necessary information for executing a fund capture action. It defines how and where the funds should be routed upon capturing a transaction. This object is essential for finalizing transactions and ensuring the correct allocation of funds. - `data.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: "c6056234-a3f9-42de-b944-3ed793fcb6bb" - `data.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" - `data.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". - `data.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. - `data.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. - `data.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. - `data.splits` (array) - `data.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. - `data.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" - `data.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. - `data.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.49 - `data.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. - `data.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. - `data.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. - `data.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: 12.6 - `data.splits.status` (any) The status of the Split. Enum: "waiting", "success" - `data.splits.reverts` (array) - `data.splits.reverts.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. - `data.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. - `data.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" - `data.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. - `data.created_at` (string) The timestamp indicating when the resource was created. It is formatted as "YYYY-MM-DD HH:MM". - `data.updated_at` (string) The timestamp indicating when the resource was created. It is formatted as "YYYY-MM-DD HH:MM". - `data.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. - `data.error.message` (string) A human-readable description of the error. ## 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 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.