Rejection reasons payout
A payout can be refused at two different moments:- When the request is sent: the API answers with an HTTP error and the payout is not created. See Request refused.
- After the payout is created: the API answers
201with statusAwaiting(7), and the payout is later Canceled (6) or Rejected (4) during processing (compliance checks, balance, limits, beneficiary data, Pix key or bank response). See Payout canceled or rejected after creation.
This page describes the behavior of the Create Payment endpoint (
POST /v2/payout/payments).Request refused
When the request is refused, no payout is created and you can fix the data and send the request again.Validation errors
Validation errors return HTTP422 with the list of invalid fields in errors. Each field can have more than one message.
Payout canceled or rejected after creation
After a payout is created, it can be Canceled (status6) during processing. When this happens, the payout webhook includes the status_detail object with the reason:
status_detail.codeidentifies the reason. Use this field in your integration.status_detail.detailis a human-readable description, in the language configured for your user. The text may change, so do not use it to implement rules.
rejection_description field when you get the payout.
TED payouts rejected by the beneficiary bank end with status Rejected (
4). In this case, the reason is available in the rejection_description field.Rejection codes table
Beneficiary and bank data
Pix
Compliance and antifraud
See Compliance for more details. Compliance cancellations cannot be retried.
Balance and limits
Account restrictions
Other reasons
To check the list of rejection reasons for payin, please see the Rejection reasons payin page.
Compliance
Every payout goes through compliance checks. The beneficiary document is verified against restrictive lists and compliance policies:- OFAC list (Office of Foreign Assets Control): code
33 - INTERPOL list: code
34 - UN list (United Nations Security Council): code
35 - European Union list: code
36 - Deceased persons (document disabled): code
37 - PEP list (Politically Exposed Persons): code
38 - Brazilian Federal Revenue (document irregular or blocked): code
39 - Age restrictions (underage or over 80 years old): codes
40and41 - KYC restrictions: code
43 - Other compliance restrictions: code
28
51, 52 and 54).
When the compliance check needs a manual review, the payout is not canceled: it goes to In Review (
5) until the review is finished. See Payout Status Flow.Handling Rejection Errors
1
Identify the Error
If the request was refused, check the HTTP status and the
errors object. If the payout was canceled after creation, check status_detail.code in the webhook.2
Review the Description
Use the tables on this page to understand the reason for the rejection.
3
Take Corrective Action
Based on the error code, take appropriate action:
- Check wallet balance
- Verify recipient information
- Review compliance requirements
- Contact support if needed
4
Retry the Request
After correcting the issue, send a new payout request. Compliance cancellations cannot be retried.
Common Scenarios
Insufficient Balance
Code:
47Solution: Check wallet balance before creating payment. Use Get Balance endpoint.Invalid Pix Key
Code:
17Solution: Verify the Pix key with the beneficiary before sending the payout again.Compliance Block
Codes:
28, 33 to 43Solution: Recipient appears on restrictive lists (OFAC, PEP, etc.) or does not meet compliance policies. Cannot proceed with payment.Transactional Limit Exceeded
Code:
49Solution: Payment amount exceeds your transactional limit. Split into smaller payments or contact support to review your limits.Best Practices
Check Balance First: Always verify wallet balance before attempting to create a payment to avoid rejection.
Related Resources
Create Payment
Learn how to create payments with proper validation
About Payments
Understand the Payout solution and payment types
Get Balance
Check wallet balance before payments
Callback Payment
Receive payment status updates

