Callbacks

Checkout sends an HTTP POST to your notification_URL as the result of each operation.

Webhook registration

To start receiving these notifications, contact the tech team and send them the webhook URL (notification_URL) where you want to receive the callbacks.

Events that trigger a callback

Checkout may fire more than one callback for the same payment, as it moves through different states:

1. type=redirect, status=success — fires when the payment reaches the redirect stage (e.g. when the transfer link/voucher is generated). It may arrive duplicated (it can arrive more than once with the same type/status).
2. type=sale, status=waiting — the charge is in progress (waiting for the transfer to clear).
3. type=sale, status=success — when the payment clears and becomes settled.

Duplicate callbacks

Checkout may resend the same callback (same id, type and status) more than once. Your endpoint should be idempotent — use the id field to detect whether you already processed that event before applying changes in your system.

info

The exact set of events (redirect, sale, or others) depends on the payment method. Methods with a redirect (bank transfer, cash, wallets) will send the redirect callback before the sale one; direct methods (card) may send sale straight away.

Transaction statuses

Transaction Status	Description
success	Completed successfully
fail	Errored, not validated
waiting	In processing
undefined	Uncertain status due to a provider issue

warning

success does not necessarily mean the payment has a final successful status — also check order_status (see the payload table below).

Callback payload

Parameter	Type	Description
id	string	Public payment ID
order_number	string	Your order ID
order_amount	float	Amount (XX.XX)
order_currency	string	Currency code
order_description	string	Product description
order_status	string	prepare, settled, pending, redirect, decline, refund, reversal, etc.
type	string	redirect, sale, or another payment stage
status	string	success, fail, waiting, undefined
reason	string	Decline/error reason (only if fail)
card	string	Card mask XXXXXX******XXXX
card_expiration_date	string	mm/yyyy
card_token	string	Only if req_token was enabled
customer_name, customer_email, customer_country, customer_state, customer_city, customer_address, customer_ip	—	Customer details (customer_ip is required)
crypto_network, crypto_address	—	Crypto payments only
digital_wallet, pan_type	—	Only if Google Pay / Apple Pay was used
exchange_rate, exchange_rate_base, exchange_currency, exchange_amount	—	Only if currency conversion took place
recurring_init_trans_id, recurring_token, schedule_id	—	Only if recurring_init was used
vat_amount	float	Only if VAT was calculated (vat_calc)
custom_data	object	Echo of what you sent in the request
extended_data*	string	Only if "Add Extended Data to Callback" is configured
connector_name, rrn, arn, approval_code, brand, gateway_id, extra_gateway_id, merchant_name, mid_name, issuer_country, issuer_bank*	—	Extended connector/acquirer data
hash	string	Signature — see Signature

* Only included if configured under Configuration → Protocol Mappings.

Delivery rules

• Your endpoint must respond with HTTP 2xx to acknowledge receipt.
• If you do not respond 2xx, the callback is not retried automatically.

Blocking on timeouts

If 5 timeouts accumulate within 5 minutes for your notification_URL, it is blocked for 15 minutes (this affects every merchant sharing that URL). The block is lifted automatically, or manually from Configuration → Merchants → Edit Merchant. The timeout counter resets after a successful response.

Cascading

If cascading is triggered for the order, you will generally receive only the callback of the last attempt (where the final status is determined: settled or declined). In specific cases, you may receive the callback of the first attempt if the customer needs to be redirected. Intermediate attempts do not generate a callback.

Actual callback format

Callback format

The callback arrives as application/x-www-form-urlencoded (key=value pairs separated by &), not as JSON. The status and type values arrive in lowercase (status=success, type=sale). Spaces arrive as + and special characters (such as @, :) are encoded (e.g. %40, %3A).

Example of a real callback

This is what a real callback looks like (raw, application/x-www-form-urlencoded) for a bank transfer method (ARS):

id=****************************&order_number=1&order_amount=150000.00&order_currency=ARS&order_description=Purchase&order_status=redirect&type=sale&status=waiting&date=2026-07-15+15%3A01%3A52&hash=****************************************&customer_name=John+Doe&customer_email=john.doe%40example.com&customer_country=AR&customer_state=Cordoba&customer_city=Cordoba&customer_address=Av+Arequipa+1234&customer_ip=***************