Coming soon. This webhook is not available yet.
POST /v2/debts/orders responses: 201, 422 ORDER_NOT_CREATED and 500. With any other one (for example, an invalid field, a contact that does not exist or a key already used), there is no webhook: the reason only reaches you in the response.
On a 500, this webhook may or may not arrive. If ORDER_CREATION_FAILED arrives with PROVIDER_UNAVAILABLE, it does not mean nothing was charged: retry with the same externalRequestId, as described in Retries and idempotency.
It is part of the order and payment method webhooks: it shares the endpoint, the security and the contract with them. Its idempotency key is
id.Creation and charge are separate notices
ORDER_CREATION_SUCCESS reports that the order was created, not that it was charged. The result of the charge reaches you later, with the order payment.
You can receive ORDER_CREATION_FAILED and then ORDER_PAYMENT_CONFIRMED for the same order, if the bank ended up processing the charge. In that case, take the charge as final: the money came in.
The payload
Reasons
creationError.code is a TapiPay code, not the bank’s. message comes in English and is meant for your logs, not for showing to the user.
Treat the list of codes as open: new codes can be added. If you receive one you do not know, treat it as a creation failure with no specific action.
Examples
An order that is created, one that is created but fails, and one whose creation failed before the order existed (withoutorderId). The examples correspond to an integration without a public key, which is why hash comes as null.
Recommendations
- Process each notification only once. The same notification can arrive more than once, always with the same
id. Store the processedidvalues in persistent storage. - Correlate by
externalOrderId. It is the only identifier that always comes:orderIdis missing if the order did not get to be created. - Do not assume an arrival order between this notice and the order payment ones.
- Ignore fields you do not know: new fields can be added.

