DIBS Payment Window (Method 1)

Shop identification. The Merchant number appears in the e-mail received from DIBS during registration with DIBS.

The smallest unit of an amount, e.g. øre for Danish crowns.

Currency specification as indicated in ISO4217 where the Danish crown is no. 208. Also see our list of currencies. Make sure that your acquirer agreement supports all the currencies that you want to use.

The shop’s order number for this particular purchase. It can be seen later when payment is captured, and will in some instances appear on the customer’s bank statement (max. 50 characters, both numerals and letters may be used).

The URL of the page to be displayed if the purchase is approved. NOTE: Can be omitted if using callbackurl.

The URL of the page to be displayed if the customer cancels the payment.

An optional ”server-to-server” call which tells the shop’s server that the payment was a success. Can be used for many purposes, the most important of these being the ability to register the order in your own system without depending on the customer’s browser hitting a specific page of the shop. See also the parameters accepturl and HTTP_COOKIE.

Regarding the start-up of the DIBS Payment Window, the user can be limited to the use of just one particular payment form. This is accomplished by using the parameter “paytype”.

This function can be used if you wish for example to use integration method 3 for payment cards and method 1 for eDankort. Furthermore, this function can be used if you wish to control the user’s selections of method of payment from your own website.

See our list of possible paytypes.

If this field exists, the orderid-field must be unique, i.e. there is no existing transaction with DIBS with the same order number. If such a transaction already exists, payment will be rejected with reason=7. Unless you are unable to generate unique order numbers, we strongly urge you to utilize this field.

Note: Order numbers can be composed of a maximum of 50 characters (DIBS automatically removes surplus characters) and that uniqueoid is therefore unable to work as intended if order numbers consisting of more than 50 characters are used. With eDankort a new uniqueoid has to be when the customer closes the window without having paid.

If multiple departments utilize the company’s acquirer agreement with PBS, it may prove practical to keep the transactions separate at DIBS. An ”account number” may be inserted in this field, so as to separate transactions at DIBS.

If this field exists, an "instant capture" is carried out, i.e. the amount is immediately transferred from the customer’s account to the shop’s account. This function can only be utilized in the event that there is no actual physical delivery of any items. Contact DIBS when using this function. (Note that instant capture requires unique order numbers – also see the description of uniqueoid above).

DIBS retains the IP-number from which a card transaction is carried out. The IP-number is used for ’fraud protection’, etc. Some implementations may send the IP number of the shop to DIBS rather than that of the customer's machine. In order to provide the same services to shops which utilize such a program for their DIBS hookup, we offer the option of sending the “ip” parameter. 

This field is used when tests are being conducted on the shop (e.g. test=yes). When this field is declared, the transaction is not dispatched to the card issuer, but is instead handled by the DIBS test module. Should the test system be used at a later date, this will be activated at DIBS (contact support(at)dibs.dk for reactivating the test mode of your shop). 

Cookies/sessions which are to be sent to callbackurl.

Must be sent along if you are using callbackurl and depend on cookies/sessions for keeping track of the user. Read how this is carried out in the description of automatic call-back further down this page. 

Indicates the language to be used in FlexWin. The following languages are currently supported:

da = Danish (default)
sv = Swedish
no = Norwegian
en = English
nl = Dutch
de = German
fr = French
fi = Finnish
es = Spanish
it = Italian
fo = Faroese
pl = Polish

If no language is indicated, Danish will automatically be selected. If you wish to use the DIBS Payment Window in a language other than the ones shown above, contact support(at)dibs.dk

The basic colour of the Payment Window. There is currently a choice of 'sand', 'grey' and 'blue'. Sand is used if there is no colour indication.

If the variable “calcfee” is declared (eg. calcfee=foo), the Payment Window will automatically affix the charge due to the transaction, i.e. the charge payable to the acquirer (e.g. PBS), and display this to the customer.

Simple order information sent to DIBS. This information is displayed to the customer in the Payment Window and is stored at DIBS.

Complex order information. If both simple and complex order information (ordertext) is declared, the simple order information is then ignored. This information is stored at DIBS.

Complex order information, see “Order information in DIBS”. If both complex and simple order information (ordertext) is declared, the simple order information is ignored. This information is displayed to the customer in the Payment Window and is stored at DIBS. It is a requirement that the number of fields be identical in all lines of the order (e.g. if there are four fields in the first line, the remaining lines must also contain four fields).

Complex order information. If both complex and simple order information is declared, the simple order information is ignored. This information is displayed to the customer in the Payment Window and is stored at DIBS.

Works like calling auth.cgi, i.e. the amount value is ignored (although it is mandatory), after which it performs a ticket registration instead of an authorisation. The transaction value returned is the ticket.

When using MD5 the "authkey" must be calculated from the string 'transact=xxxxxxxx&preauth=true&currency=yyy'.

This parameter is intended for the payment window, and actually performs two transactions. First it performs a regular authorisation. If, and only if, it is accepted, it is followed by a ticket registration.

Both a transaction and a ticket value are returned to 'accepturl' if it is specified.

If 'callbackurl' is specified, DIBS will perform two separate calls, corresponding to performing two transactions - one call to the regular authorisation, and another to the ticket registration. Both cases return a 'transact' parameter value (e.g. 'transact="78901234"'). In calls to 'callbackurl' containing 'preauth', the ticket value is composed of the 'transact' parameter value.

Please note, that when using 'maketicket', the return parameter 'authkey' is being calculated from 'transact=xxxxxxxxx&amount=0000&currency=xxx'.

You cannot use 'uniqueoid' or 'capturenow' along with 'maketicket'..

Set the value of this parameter to the same as defined by you in DIBS Admin.

This variable enables an MD5 key control of the parameters received by DIBS. This control confirms, that the parameters sent to DIBS, have not been tampered with during transfer. The MD5-key for auth.cgi is calculated as:

MD5(key2 + 
 MD5(key1 + 
  "merchant=xxxxxxx&orderid=xxxxxxx" +
  "&currency=xxx&amount=xxxx"))

Where key1 and key2 are shop specific keys available through the DIBS administration interface, and + is the concatenation operator. NB! MD5-key check must also be enabled through the DIBS administration interface in order to work. Please refer to MD5-key control for further details.

You cannot use 'maketicket' along with 'md5key'.

Note: If you use 'md5key', you have to use unique order IDs, i.e., you have to set the parameter 'uniqueoid'.