DIBS Payment Window (Method 1)

- Return pages

As previously mentioned, two situations allow the user to exit the DIBS Payment Window, these being:

1. The customer returns to ”accepturl” once payment is approved.
2. If the customer cancels payment, he returns to ”cancelurl".

Note: The security updates of recent browsers has necessitated that the shop's accept/cancel page is shown in the popup window, wherefrom an optional link (or autoloader) may be made to the originating window. This is done by naming the calling window and using this name as a link target on the accept/cancel page.

Payment Approved (accepturl)

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. Aside from the standard port 80, accepturl may also use port 20080. The following parameters are returned to the accepturl:

Payment Cancelled (cancelurl)

As with the accepturl a post is made to the ”cancelurl” page with all previous parameters sent to the DIBS Payment Window. CGI-parameters sent to the cancelurl are also returned (?x=1&y=4). Again, aside from the standard port 80, cancelurl may also use port 20080. Note: Reserved words cannot be used as declared cgi-parameters (see list of reserved words at bottom of page).

Automatic Call-back (callbackurl)

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 at the same time the receipt is 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 so 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”.

In order to activate the automatic call-back a callback-url must be passed on to the Payment Window. This is done through the callbackurl parameter. The URL is then automatically called when the approved-page is displayed. The call is created as a post and all parameters are sent to start.pml, cgi-parameters sent along to callbackurl (?x=1&y=4) and transact and the MD5-encryption key can be sent along (the same parameters that are returned via accepturl are always along). As with accepturl and cancelurl, callbackurl may also use port 20080.

Note: Reserved words cannot be used as declared cgi-parameters (see list of reserved words at bottom of page). If the callback script is dependent on cookies or sessionid, these must also be sent along to the Payment Window in the http_cookie parameter. The value of this variable must contain the form: name1=value1; name2=value2...

If you should wish to transfer all declared cookies, the content of the HTTP_COOKIE variable can be used, this containing all the cookies in the correct format. Below are a few examples of how to do this in ASP, PHP and JavaScript.

ASP:

<input type="hidden" name="HTTP_COOKIE" value=
  "<%=Request.ServerVariables("HTTP_COOKIE") %>" />

PHP:

<input type="hidden" name="HTTP_COOKIE" value="<?= getenv("HTTP_COOKIE"); ?>" />

or

printf('<input type="hidden" name="HTTP_COOKIE" value="%s">', getenv("HTTP_COOKIE"));

JavaScript:

<script type="text/javascript">
<!--
document.writeln('<input type="hidden" name="HTTP_COOKIE"
  value="' + document.cookie + '">');
//-->
</script>