Possible Webhooks

OrderCreated

This webhook is triggered when a new order is created.

Request <!-- {docsify-ignore} -->

OrderIdentified

This webhook is triggered when a deposit order gets its bank transfer identified. It is NOT safe to add funds to the user balance yet. In most of the cases, sequentially, the OrderComplete (see next) webhook is sequentially called, but there might be cases when the user KYC status is not verified yet or the fraud detection systems have triggered a manual review.

This webhook will only be called for deposit orders.

Request <!-- {docsify-ignore} -->

OrderComplete

This webhook is triggered once an order is complete. At this point, after confirming in the Order > Get Details endpoint to ensure the request hasn't been forgered, it will be safe to settle user funds, if this is a deposit order.

Request <!-- {docsify-ignore} -->

OrderExpired

This webhook is triggered once an order is expired due to not being identified in time.

If the user transfers any funds after the order has expired, the deposit will not be identified automatically. Rather, the user should contact our support team and will be instructed to create a new deposit order.

Request <!-- {docsify-ignore} -->

OrderScheduled

This webhook is triggered for withdrawal orders only, and indicates that the order has passed any KYT procedures and has now been scheduled for processing.

Scheduled orders are processed, depending on the method:

• BankAccount: TED window (Monday to Friday (except holidays), 7 AM to 5 PM)
• PhoneTopup: 24/7
• Boleto: 7 AM to 10 PM

Request <!-- {docsify-ignore} -->

OrderCancelled

This webhook triggers when the user has requested one order to be cancelled.

It is only possible to cancel pending orders.

A order cancellation indicates that a deposit will not happen, or that a withdraw should be refunded back to the user's account.

Request <!-- {docsify-ignore} -->

OrderFailed

This webhook is called when a withdrawal order has failed to be sent and will no longer be re-attempted (you should refund the value at this point), or a deposit order has generated an alert that has been reviewed to be valid and, therefore, is not valid (and we've refunded the value to the origin account).

For withdrawals, this usually means the destination data is wrong or the destination bank is passing through technical difficulties.

For deposits, this usually means the user has tried to send funds from third parties.

Request <!-- {docsify-ignore} -->

UserKycVerified

This webhook is called when a user gets his profile verified successfully.

Users may be registered through the "Register Customer" endpoint (for ActiveDeposits-enabled setups) or through the creation of an order - if through the latter, the KYC is verified once that user's first deposit is received or withdrawal is executed.

Request <!-- {docsify-ignore} -->

UserKycFailed

This webhook is called when a user gets his profile verification failed.

Users may be registered through the "Register Customer" endpoint (for ActiveDeposits-enabled setups) or through the creation of an order - if through the latter, the KYC is verified once that user's first deposit is received or withdrawal is executed.

At this step, no sanctions or risk screening is performed (this is done at a separated step), and the only data verified at the moment of the registration is whether the taxpayer number holder's name matches the user's name on the partner's platfform. In this case, a new registration attempt (or order creation) should be done.

Request <!-- {docsify-ignore} -->

UserKycDenied

This webhook is sent when a user’s KYC is denied (permanently rejected).

Unlike a temporary failure, a denial means the user cannot submit a new KYC attempt through your platform.

This KYC denied occurs when we identify a fraud risk. At this stage we only check whether the taxpayer ID holder’s name matches the user’s name on the partner’s platform. If you believe the denial was issued in error, contact support with the user’s reference and any supporting documents; otherwise you should block further KYC attempts for this user and prevent new orders that require verification.

Request <!-- {docsify-ignore} -->

UserComplienceReview

This webhook is triggered when a user reaches a quota limit alert.

There are three alert levels: yellow, red, and block.

• Yellow / Red → The user can still operate but should be notified of the restrictions, new documentation can be submitted for upgrading of their operating limits.
• Block → The user is blocked from operating normally until new documentation is submitted and approved.

At this stage, the user may send additional documents to request an upgrade of their operating limits. Even if the new documentation were reject in an Yellow or Red alert, the user will be able to operate until the block alert.

Request <!-- {docsify-ignore} -->