# Callbacks
When initiating the payment session in Inbank Partner API the e-shop should provide 3 URLs:
- <b>redirect URL</b> - the URL to which the customer's browser will be redirected back after the customer has completed the credit application dialog. Regardless of the outcome of the credit application process, the customer is redirected here, even if the credit is not granted.
- <b>cancel URL</b> - the URL to which the customer's browser is redirected if the customer deliberately chooses to cancel the credit application dialog.
- <b>callback URL</b> - the URL to which Inbank will send server-to-server callback notifications on session status change events.

Inbank sends callbacks about the following state transition events:
- Credit application is cancelled
- Credit application is denied
- Contract is cancelled
- Contract is granted (applicable if the flow requires merchant approval of credit contracts)
- Contract is activated (state indicating that the financing of the purchase has been completed)

If you are integrating with Inbank's Pay next month payment product, there can be cases when a customer already has an active credit contract and the new purchase is added to it. In this case, the following callbacks will be sent:
- Purchase is rejected (credit for the purchase has been declined by Inbank, the payment session status becomes Declined)
- Purchase is cancelled (the customer has cancelled the financing process, the payment session status becomes Cancelled)
- Purchase is activated (financing for the purchase has been successfully provided, the payment session status becomes Completed)

Once the financing process is finalized, Inbank will send two callbacks, both with the same structure and content:
- First one is performed on redirectUrl, via the customer's browser.
- Second one is server-to-server callback which ensures that the merchant receives the callback. It is done on callbackUrl.

<b>Note</b> in case duplicated callbacks should arrive for a single payment session, please make sure that only the first callback is processed.
Note that the first callback may not arrive if the customer does not press the "<b>back to merchant</b>" button, or if there are connectivity or technical problems at the customer's device/browser. Thus there is no guarantee that the first callback will arrive, or which one of the two callbacks will arrive first. Callback requests are lightweight triggers for initiating activities on the merchant side. They contain only minimal information.
To avoid processing accidental or malicious traffic to callback endpoints, the handlers should first verify the authenticity of the request. For more details, see the [Callback authenticity validation](#callbackauthenticityvalidation) chapter.
E-shop should process the incoming messages, at a minimum, in the following way:
- Validate the authenticity of the request, to avoid further processing of invalid traffic.
- Look up the `pos_session` identifier either from the incoming message, or from the internal database as it was persisted when the session was initiated.
- Inspect `pos_session` status and process the order payment status based on the `pos_session` state. If needed, you can also check the purchase reference.
- Redirect the user to the respective dialog, i.e. the "payment complete" page.