3dsecure.cgi

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

The smallest unit of an amount, eg. øre for Danish crowns, cent for EUR

Currency specification as indicated in ISO4217 where the EUR is no. 978. Also see our list of currencies.

The shop’s order number for this particular puchase.  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.

The same as declineurl

The URL of the page to be displayed if the purchase is denied.

Card number with no spacing.

Card expiry month in two digits, 01 for january.

Card expiry year in two digits, 06 for 2006.

When preauth=true is sent as part of the request to auth.cgi the DIBS server identifies the authorisation as a ticket authorisation rather than a normal transaction. Please note that the pre-authorised transaction is NOT available among the transactions in the DIBS administration interface. When using MD5 the Authkey must be calculated from the string transact=12345678&preauth=true&currency=123

Card control values.

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

MD5(key2 + MD5(key1 + “merchant=<merchant>&orderid=<orderid> &currency=<cur>&amount=<amount>))

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. Further details on MD5-key control.

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.

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 control’, 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. See also Step 5 of the 10 Step Guide for more information.  During your initial integration with DIBS, there is no need to insert this parameter, since all default transactions will hit the DIBS test system until DIBS has approved integration.  Should the test system be used at a later date, this will be activated at DIBS (contact DIBS support for reactivating the test mode of your shop).

An optional ”server-to-server” call which tells the shop’s server that 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 HTTP_COOKIE. 

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.

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 displayed to the customer in the payment window and is stored at DIBS.

Complex order information, see “Order information at 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 (eg. 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.

Transaction number – whole numbers consisting of 7 to 9 digits.

The type of payment the customer has used for a particular payment.  The payment type is returned as a string. Paytype is only returned if a member of the DIBS administration has activated a return of all values (under installation + return values).

The acquirer used for the specific trasaction. See also our list of valid values for acquirer.

The MD5 check sum for verification of the authenticity of the transaction.  This is only returned if an MD5 key is created within the administration (under installation + MD5 keys). You may read more about MD5 key control.  

Note:  When using a payment window and the calcfee function, amount+fee is used as a basis for calculations rather the amount only.

Is returned if there is a subscription to fraud control and this is activated in the administration interface (in such a case, this may have the value ”true”).

When calcfee is used, the calculated fee is returned so it can be shown on the receipt.

Whole numbers. Is returned if fraud control has noted the transaction as a potential fraud, if there is a subscription to fraud control and if this is activated in the administration interface.  The higher the amount, the more questionable the transaction.  We generally recommend closer checks of transactions with severity > 5.

All parameters sent to start.pml are returned to accepturl.

All cgi-parameters included with the accepturl via POST – this also applies to cancelurl.  Reserved words cannot be used as declared cgi-parameters (see list of reserved words at bottom of page). If several parameters are declared via DIBS, it should be noted that browsers use various maximum lengths of query-strings (eg. 2083 characters for IE).