When a customer has made a payment in Flexwin, you need a response to your shop. Return pages is the main communication system in Flexwin where DIBS sends back a response.
The user can exit Flexwin in one of two ways:
- The customer returns to "acceptUrl" once the payment is approved.
- The customer cancels the payment, and is returned to "cancelUrl".
Furthermore an automatic server-to-server call can be made with the output parameters, in case the customer doesn't reach one of above pages. This response is sent to the "callbackUrl".
To minimize the parameters sent back to either the return pages or the callback, a configuration has to be made. Please see the configuration documentation here.
Merchants must be able to handle any future changes, such as additional parameters introduced by DIBS or any changes in the order in which they are returned.
Upon returning to acceptUrl, the customer will normally expect a receipt to be displayed. We therefore recommend you use the acceptUrl option for generating a customer receipt. Please refer to the output parameters section for parameters returned to the acceptUrl.
In case the customer cancels the purchase using the functionality in the payment window (not by closing the window), he is returned to the cancelUrl. The parameters returned along with the customer is described under output parameters.
There is a potential risk of the customer not following the link to the receipt and subsequently never seeing one. If the shop system is set up so that orders are stored in the database simultaneously with the receipt being displayed to the customer, the order may in fact escape registration within the shop’s own system. This would be rather unfortunate, since a payment is authorized with DIBS, the customer believes DIBS has authorized the payment, and the customer believes that the order has been carried out, yet the shop’s system has no knowledge of any such order.
To avoid such an occurrence, DIBS automatically enables the approved page to call a script in the shop’s system without involving the customer in the procedure. As is the case with the receipt page, this script must inform the shop’s order system, that the order has been carried out, and send an order confirmation to the customer, if required. It can also serve as an MD5 key control to ensure that the customer himself does not call the script, resulting in the shop interpreting the order status as “carried out”.