Approve cashout pix key

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

ParameterTypeDescriptionRequired or OptionalExample
AuthorizationStringBearer + Access_tokenrequiredBearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNzEzMzAwOTMxLCJpYXQiOjE3MTMyOTczMzEsImp0aSI6Ijc2ZWI4ZTE5ZjM4YjQ4NmZiODdmNzNjNTdkMWVmNDJhIiwidXNlcl9pZCI6MjQ2fQ.5zekMa7CUj9p-MvNHns5ke4ZPhYV3Y1CLOsYL7hDUUo
hmacStringHMAC (Hash-based Message Authentication Code) is an authentication algorithm that combines a private key with a message to create a Message Authentication Code (MAC).requiredhmac: 57373705c83bc5efe41001790c54642e670088c0c87d56bc8f990f2260c7740b99f4081ff231b87f82118c1e77a959e1f40eacf690a8fa61a827a9ba01d546f6

Body Details

{
  "id": 789456
}
FieldTypeDescriptionRequired or Optional
idIntegerThe 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
}
FieldTypeDescription
workedBooleanAlways true for successful requests.
idIntegerUnique identifier of the transaction.
transaction_idIntegerTransaction identifier (same as id).
code_transactionStringHuman-readable transaction code.
statusStringCurrent status of the transaction. Will be PROCESSING after approval.
amountFloatAmount to be transferred.
feeFloatTransaction fee charged. Currently 0.0 for PIX transactions.
keyStringPIX key used for the transfer, or null if manual details were provided.
tagStringReference tag provided when the transaction was created, or null.
from_accoutStringSource account number from which the transfer will be made.
recipient_instutionStringISPB code of the recipient's financial institution.
recipient_instution_nameStringName of the recipient's financial institution.
recipient_account_idStringRecipient's account number.
recipient_branch_idStringRecipient's branch identifier.
recipient_legal_idStringRecipient's CPF or CNPJ.
recipient_nameStringRecipient's name.
recipient_account_typeStringType of recipient's account (e.g., CONTA_CORRENTE, CONTA_POUPANCA).
operationUuidStringOperation UUID from the payment system, or null if not yet assigned.
idempotency_keyStringThe idempotency key if one was provided during creation, or null.
erro_descriptorStringError description if the transaction failed, or null if successful.
new_erro_descriptorStringAdditional error information, or null if not applicable.

Error Responses

HTTP CodeError MessageDescription
400Transaction not foundThe transaction does not exist.
400Transaction in wrong statusThe transaction is not in NEW status. Only transactions with NEW status can be approved.
401UnauthorizedInvalid or missing authentication token. Ensure you are sending a valid Bearer token and HMAC signature.
422Validation errorRequest validation failed. Check that the transaction ID is valid.

Business Rules

  1. Status Validation: The transaction must be in NEW status to be approved. Transactions in other statuses cannot be approved.
  2. HMAC Validation: The request body must be validated using the provided HMAC signature.
  3. Status Transition: Upon approval, the transaction status changes from NEW to PROCESSING.
  4. Background Processing: After approval, a background task is initiated to complete the transfer.
  5. 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:

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

  1. Manual Approval Workflow: Organizations that require manual review and approval of transactions before processing.
  2. Compliance Requirements: Companies with compliance policies that mandate dual authorization for financial transactions.
  3. Risk Management: High-value transactions that need additional verification before being processed.
  4. Audit Trail: Separating creation and approval provides a clear audit trail showing who created and who approved each transaction.
  5. Different User Roles: One user creates the transaction, and another user with approval permissions reviews and approves it.

Differences from Self-Approve Endpoints

FeatureApprove Cashout (Two-Step)Self-Approve (One-Step)
Number of API Calls2 (Create + Approve)1 (Create with auto-approve)
Initial StatusNEWPROCESSING
Required PermissionsCREATE (step 1) + APPROVE (step 2)CREATE + APPROVE (both)
Use CaseManual review/approvalTrusted automated operations
Transaction VisibilityAvailable before approvalApproved immediately
FlexibilityCan review before approvalNo review opportunity
Audit TrailSeparate create/approve logsSingle 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

Headers
string
enum
Defaults to application/json

Generated from available response content types

Allowed:
Responses

Language
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json
text/plain