You need to understand that callbackUrl
is a parameter which same as others cancelReturnUrl
and acceptReturnUrl
parameters. Short description from your references
acceptReturnUrl
Upon returning to acceptReturnUrl, the customer will normally expect a
receipt to be displayed.
cancelReturnUrl
In case the customer cancels the purchase using the functionality in
the payment window (not by closing the window), he is returned to the
cancelReturnUrl
callbackUrl
When the customer finishes a payment, he is redirected to the
acceptReturnUrl along with the return parameters. If the customer
stops the communication (closes the browser, loses internet connection
ect.) before reaching the webshop, the shop system is not informed of
the result of the purchase. To avoid this situation, an automatic
server-to-server call can be sent to the shop backend, enabled by
sending along the "callbackUrl" parameter. This URL is then
automatically called with the return parameters when the purchase is
accepted.
The call is created as a post. All the previously described return
parameters are returned to the callbackUrl, and it accepts only port
80 (HTTP), 443 (HTTPS ) and 20080.
Because http is a stateless protocol which means that the connection between the browser and the server is lost once the transaction ends. To solve this problem your payment gateway(DIBS) suggest to use callbackUrl
parameter, give an url to this parameter which is listened at your side. If any problem occur like mentioned in the case (closes the browser, loses internet connection ect.) DIBS will return this url address which mentioned at your callbackUrl
parameter with payment return parameters.
So at backend you can update your payment information.