Skip to main content

Rejection reasons payout

A payout can be refused at two different moments:
  1. When the request is sent: the API answers with an HTTP error and the payout is not created. See Request refused.
  2. After the payout is created: the API answers 201 with status Awaiting (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 HTTP 422 with the list of invalid fields in errors. Each field can have more than one message.
Besides the standard messages for required fields, formats and sizes, these are the most common validation errors:

Payout canceled or rejected after creation

After a payout is created, it can be Canceled (status 6) during processing. When this happens, the payout webhook includes the status_detail object with the reason:
  • status_detail.code identifies the reason. Use this field in your integration.
  • status_detail.detail is a human-readable description, in the language configured for your user. The text may change, so do not use it to implement rules.
The same description is returned in the 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

A payout returned by the beneficiary after it was paid is not a rejection: it keeps the Paid status and receives a refund substatus.
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 40 and 41
  • KYC restrictions: code 43
  • Other compliance restrictions: code 28
Payouts can also be canceled after a preventative antifraud review (codes 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.
Validate Recipient Data: Ensure recipient information is accurate and complete before processing payments.
Handle Compliance Rejections: Implement proper error handling for compliance-related rejections. These cannot be retried and require manual review.

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