Approves a previously created cashout transaction, transitioning it from NEW status to PROCESSING status. This endpoint is used in the two-step approval workflow where a transaction is first created and then separately approved. Once approved, a background task is initiated to complete the transfer.
Headers
| Parameter | Type | Description | Required or Optional | Example |
|---|---|---|---|---|
| Authorization | String | Bearer + Access_token | required | Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNzEzMzAwOTMxLCJpYXQiOjE3MTMyOTczMzEsImp0aSI6Ijc2ZWI4ZTE5ZjM4YjQ4NmZiODdmNzNjNTdkMWVmNDJhIiwidXNlcl9pZCI6MjQ2fQ.5zekMa7CUj9p-MvNHns5ke4ZPhYV3Y1CLOsYL7hDUUo |
| hmac | String | HMAC (Hash-based Message Authentication Code) is an authentication algorithm that combines a private key with a message to create a Message Authentication Code (MAC). | required | hmac: 57373705c83bc5efe41001790c54642e670088c0c87d56bc8f990f2260c7740b99f4081ff231b87f82118c1e77a959e1f40eacf690a8fa61a827a9ba01d546f6 |
Body Details
{
"id": 789456
}
| Field | Type | Description | Required or Optional |
|---|---|---|---|
| id | Integer | The unique identifier of the transaction to approve. | required |
Request Examples
Approve a cashout transaction:
POST /approve-cashout
Authorization: Bearer <access_token>
hmac: <computed_hmac>
Content-Type: application/json
{
"id": 789456
}
Approve a manual cashout transaction:
POST /approve-cashout-manual
Authorization: Bearer <access_token>
hmac: <computed_hmac>
Content-Type: application/json
{
"id": 789457
}
Response Details
{
"worked": true,
"id": 789456,
"transaction_id": 789456,
"code_transaction": "E789456",
"status": "PROCESSING",
"amount": 100.5,
"fee": 0.0,
"key": "[email protected]",
"tag": "payment-reference-123",
"from_accout": "123456",
"recipient_instution": "12345678",
"recipient_instution_name": "Example Bank",
"recipient_account_id": "654321",
"recipient_branch_id": "0001",
"recipient_legal_id": "12345678901",
"recipient_name": "John Doe",
"recipient_account_type": "CONTA_CORRENTE",
"operationUuid": null,
"idempotency_key": null,
"erro_descriptor": null,
"new_erro_descriptor": null
}
| Field | Type | Description |
|---|---|---|
| worked | Boolean | Always true for successful requests. |
| id | Integer | Unique identifier of the transaction. |
| transaction_id | Integer | Transaction identifier (same as id). |
| code_transaction | String | Human-readable transaction code. |
| status | String | Current status of the transaction. Will be PROCESSING after approval. |
| amount | Float | Amount to be transferred. |
| fee | Float | Transaction fee charged. Currently 0.0 for PIX transactions. |
| key | String | PIX key used for the transfer, or null if manual details were provided. |
| tag | String | Reference tag provided when the transaction was created, or null. |
| from_accout | String | Source account number from which the transfer will be made. |
| recipient_instution | String | ISPB code of the recipient's financial institution. |
| recipient_instution_name | String | Name of the recipient's financial institution. |
| recipient_account_id | String | Recipient's account number. |
| recipient_branch_id | String | Recipient's branch identifier. |
| recipient_legal_id | String | Recipient's CPF or CNPJ. |
| recipient_name | String | Recipient's name. |
| recipient_account_type | String | Type of recipient's account (e.g., CONTA_CORRENTE, CONTA_POUPANCA). |
| operationUuid | String | Operation UUID from the payment system, or null if not yet assigned. |
| idempotency_key | String | The idempotency key if one was provided during creation, or null. |
| erro_descriptor | String | Error description if the transaction failed, or null if successful. |
| new_erro_descriptor | String | Additional error information, or null if not applicable. |
Error Responses
| HTTP Code | Error Message | Description |
|---|---|---|
| 400 | Transaction not found | The transaction does not exist. |
| 400 | Transaction in wrong status | The transaction is not in NEW status. Only transactions with NEW status can be approved. |
| 401 | Unauthorized | Invalid or missing authentication token. Ensure you are sending a valid Bearer token and HMAC signature. |
| 422 | Validation error | Request validation failed. Check that the transaction ID is valid. |
Business Rules
- Status Validation: The transaction must be in
NEWstatus to be approved. Transactions in other statuses cannot be approved. - HMAC Validation: The request body must be validated using the provided HMAC signature.
- Status Transition: Upon approval, the transaction status changes from
NEWtoPROCESSING. - Background Processing: After approval, a background task is initiated to complete the transfer.
- Transaction Locking: The transaction is locked during the approval process to prevent concurrent modifications.
Two-Step Approval Workflow
This endpoint is part of a two-step approval workflow:
Step 1: Create Transaction
Use one of the following endpoints to create a cashout transaction with NEW status:
- POST /create-cashout - Create cashout with PIX key
- POST /create-cashout-manual - Create cashout with manual account details
Step 2: Approve Transaction
Use this endpoint to approve the transaction, changing its status to PROCESSING and initiating the transfer.
Workflow Example
1. Create the transaction:
POST /create-cashout
Authorization: Bearer <access_token>
hmac: <computed_hmac>
Content-Type: application/json
{
"source_account_branch_identifier": "0001",
"source_account_number": "123456",
"amount": 100.50,
"key": "[email protected]"
}
Response:
{
"worked": true,
"id": 789456,
"status": "NEW",
...
}
2. Approve the transaction:
POST /approve-cashout
Authorization: Bearer <access_token>
hmac: <computed_hmac>
Content-Type: application/json
{
"id": 789456
}
Response:
{
"worked": true,
"id": 789456,
"status": "PROCESSING",
...
}
Use Cases
- Manual Approval Workflow: Organizations that require manual review and approval of transactions before processing.
- Compliance Requirements: Companies with compliance policies that mandate dual authorization for financial transactions.
- Risk Management: High-value transactions that need additional verification before being processed.
- Audit Trail: Separating creation and approval provides a clear audit trail showing who created and who approved each transaction.
- Different User Roles: One user creates the transaction, and another user with approval permissions reviews and approves it.
Differences from Self-Approve Endpoints
| Feature | Approve Cashout (Two-Step) | Self-Approve (One-Step) |
|---|---|---|
| Number of API Calls | 2 (Create + Approve) | 1 (Create with auto-approve) |
| Initial Status | NEW | PROCESSING |
| Required Permissions | CREATE (step 1) + APPROVE (step 2) | CREATE + APPROVE (both) |
| Use Case | Manual review/approval | Trusted automated operations |
| Transaction Visibility | Available before approval | Approved immediately |
| Flexibility | Can review before approval | No review opportunity |
| Audit Trail | Separate create/approve logs | Single approval log |
Transaction Status Flow
[Create Transaction] → NEW → [Approve Transaction] → PROCESSING → SUCCESS/FAILED
- NEW: Transaction created and waiting for approval
- PROCESSING: Transaction approved and being processed by the payment system
- SUCCESS: Transfer completed successfully
- FAILED: Transfer failed (insufficient funds, recipient issues, etc.)
Only transactions in NEW status can be approved. Once a transaction moves to PROCESSING or any other status, it cannot be approved again.
Related Endpoints
- POST /create-cashout - Create cashout transaction with PIX key (requires separate approval)
- POST /create-cashout-manual - Create cashout with manual details (requires separate approval)
- POST /create-cashout-self-approve - Create and auto-approve in one step
- POST /create-cashoutmanual-self-approve - Create manual cashout and auto-approve
