# 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 application dialog. Regardless of the outcome of the application process, the customer is redirected here, even if rent 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 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:
- Application is cancelled
- Application is denied
- Contract is cancelled
- Contract is granted (the flow now requires partner approval of the agreement)
- Contract is activated (state indicating that the rental agreement is now active)

Once the process is finalised, 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 partner receives the callback. It is done on callbackUrl.

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 partner 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.