If the payment is accepted and the customer is leaving FlexWin, they will be sent to the supplied "accepturl". When the customer is redirected to the "accepturl", they will usually be sent through port 80, but can in some cases be sent through port 20080.
The parameters sent to the "accepturl" can be through HTTP POST or HTTP GET depending on the "Skip accept page" configuration, which is found in the DIBS administration menu below.
If the "Skip accept page" is checked the return parameters will be sent through an HTTP GET call and if it is not checked, they will be sent through an HTTP POST .
The configuration of the parameters sent to the "accepturl" is described here.
If the payment is cancelled by the user and the customer is leaving FlexWin, they will be sent to the supplied "cancelurl". When the customer is sent back through the "cancelurl", they will usually be sent through port 80 but can in some cases be sent through port 20080.
If no "cancelurl" is defined, there will be no cancel button in the payment window and the customer can therefore not "cancel" the payment.
The cancelurl's return parameters will always be sent through an HTTP POST call.
If the customer cancels the payment it will not be completed, and therefore the return parameters cannot consist of the following values even if they are configured to be returned.
|Card number with last four digits unmasked|
|Card issuing country (only VISA and MC)|
|Card enrollment status (3DSecure transactions only)|
|Transaction status code|
See the configuration of the returned parameters here.
There is a potential risk that the customer will not follow the link to the receipt (Step 3) and subsequently they will never see one. If the shop only processes the order when the "accepturl" is called, the order may never be registrered or processed by the shop. This would be rather unfortunate since a payment is authorized with DIBS 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 provides a "callback" procedure to communicate with the shop without the customer being involved. 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”.
The call is created as a post and it is only sent through port 80 (HTTP), 443 (HTTPS) and 20080 (both HTTP and HTTPS). All the return parameters are sent to the callbackurl, and the callback will come from IP 184.108.40.206.
Multible callback attempts
You can activate multible callback attempts through DIBS admin. If you activate this function, DIBS will try to resend the callback up to 5 times, if a valid response hasen't been received. A mail notification can also be setup if all 5 callback attempts fails.
To activate these functions, please open DIBS admin and go to:
Processing callback response codes
DIBS listens to the HTTP status code when a post has been made to your callbackurl. The HTTP status codes is used to determine whether your system successfully received the callback from DIBS (based on the listing below). DIBS will resubmit the callback if the function for multible callbacks is activated and the HTTP response is a failure of any kind. Our service will wait for 15 seconds for a valid HTTP response before it is registered as a failed attempt.
If the initial HTTP response from your callbackurl indicate a failure to receive the callback, DIBS can automatically re-send the callback, and make up to 5 callbacks.
The following HTTP status responses are regarded as successfully processed:
- All status codes in the range 200-299.
- Codes 301, 302, 304 and 307 will be accepted. However, the information will not be redirected and the callback will not be sent back.
- Codes 204, 205 and 304 that do no contain the header 'Content Type'. The body of the response will be ignored, but the callback will be processed as successful
The return parameters are sent to the return page either as an HTTP POST or an HTTP GET call. The return parameters from FlexWin depends on the configuration of return values (found in the DIBS administration under the menu "Integration"/"Return values"), what type of transaction is made, and which return page is called. This makes the configuration crucial if you are using return parameters.
The minimal amount of return parameters to the accepturl and callback url is:
Regarding the cancelurl you have to send at least an empty HTTP POST call.