auth.cgi

The "merchant" parameter is the shop's DIBS identification number. The merchant number is available in the order confirmation email, and is a 7-digit integer.

The amount to be transferred. The amount must be given in smallest possible unit, e.g. cents 100 = USD 1.

The currency code of the transfer in the ISO4217 form, e.g. 208 for DKK (see list of other ISO4217 currency codes).

The credit card number. Credit card numbers consist of between 11 and 19 digits depending on the card type.

Expiry month of the credit card in the format 'mm', e.g. 02 for February.

Expiry year of the credit card in the format 'yy', e.g. 09 for 2009.

The shop's order number, which may contain a maximum of 50 characters.

If this variable is set to be true (e.g. textreply=yes), then the DIBS system returns its answer in simple text format. If you are not using the standard DIBS payment window, e.g. using server-to-server requests, this significantly simplifies parsing the answer from DIBS. You may use either port 80 or port 20080.

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'.

If this variable is set, all variables will be returned (as defined in the DIBS admin). Note: This only works when used together with textreply.

This variable enables a MD5 key control of the parameters received by DIBS. This control confirms that the parameters sent to DIBS have 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.

Card Verification Code. CVC check must be enabled through the DIBS administration interface. NB! The use of CVC codes may require special explanations to the customer. See the DIBS website for information on how to present this information to the user.

This variable indicates to the DIBS server that the transaction is a test transaction. If 'test=true' is included in the post to the DIBS server, the transaction is handled by a dedicated test server, and is not transferred to the acquirer. See the integration guide on the DIBS website for further explanation. Please note, that during the initial implementation phase, all transactions are automatically regarded as test transactions, regardless of the "test" parameter. Once DIBS has approved the implementation, the "test" parameter must be set when doing further testing. Please contact DIBS support if you require the full test mode to be re-enabled after your payment facility has gone live.

If this parameter is set, the DIBS server checks whether the order number is unique. That is, if a previous transaction contains the same order number, the authorisation is rejected with reason=7. Unless the shop is unable to create unique order numbers, it is strongly recommended to enable uniqueoid. NB! Order numbers must be less than 50 characters.

The DIBS system saves the IP number of the computer from which the form was submitted. The IP number is, among other things, used for fraud protection. The "ip" parameter is particularly useful in cases, where the web server's IP number is transfered, rather than that of the user's machine.

If this parameter is set, the DIBS server tries to capture the transaction immediately following the authorisation (if this was successful). Instant capture is only allowed for shops that sell products that are not physically shipped to the customer, e.g. conference fees, or services on the internet. NB! "capturenow" requires "uniqueoid" to be enabled. Please contact DIBS if you intend to use "capturenow".

If several departments within a company use the same acquirer contract, it may be beneficial to keep track of the transactions per department. Setting the "account" parameter enables separation of the transactions by department in the DIBS administration interface.

"split" is used for splitting up a transaction into two or more sub-transactions. This enables part of an order to be paid for when shipped in part. It requires that the amount and currency of the part payments are known at the time of the order, and are posted to the DIBS server as:

split=2&amount1=<amount1>&amount2=<amount2>

i.e., a set of "amount" parameters replaces the original "amount" parameter. If the number of "amount" parameters is inconsistent with the number given in the "split" parameter, the authorisation fails with reason=8. Part transactions will show up in the DIBS administration interface as separate transactions with separat transaction numbers, but with the same order number. In the response from DIBS, the parameter "transact" is replaced with "transact1", "transact2", etc. If you are also using MD5-key control, please note, that the key is calculated using the sum total of the transactions.

"cardtype" is used when one wishes to limit the type of credit cards the shop accepts. If "cardtype" is set, then only that specific card type will be accepted. All other card types will be rejected with reason=10. See our list of valid cardtypes.

"postype" (one 't') is used when one wishes to register the transaction origin. For normal internet transaction it is not required to include "postype", as it is automatically set to SSL. Possible values are:

ssl = internet transactions,
magnetic = magnetic stripe read, and signature is available,
magnosig = magnetic stripe read, and no signature is available,
mail = mail order,
manual = manually entered,
phone = phone order,
signature = card and signature available, manually entered.

This parameter is used for enforcing either the two-stage or the three-stage model. Possible values are:

now = enforce two-stage model.
later = enforce three-stage model (if allowed).

You are always allowed to enforce the two-stage model. However, the three-stage model has some restrictions, such as, it must be a Dankort payment, or the "capturenow" option will override "confirm".

If "return_checksum" is sent to the DIBS server, the parameter "checksum" is returned. The parameter is a one-way calculated checksum based on the card number, and will always be the same for each card number. E.g. it can be used to check whether a specific credit card has been used before.

Card authentication verification value. Is used in relation to 3D-secure transactions.

Transaction identification number for 3D-secure transactions.

Various Swedish bank cards support transactions both as debit and credit. If such a card is used, and the parameter "account_type=debit" is included, then the transaction will be treated as a debit transaction. Otherwise, if "account_type=credit", it is treated as a credit transaction.

integer

All transactions are given a unique DIBS identification number. It is at minimum a 6-digit integer, e.g. transact=123456. If "split" is used, then "transact" is replaced by "transact1", "transact2", etc.

string

ACCEPTED/DECLINED

string

Contains the acquirer, e.g. PBS, Teller, Euroline etc. (list of possible values). In order for the DIBS server to return the acquirer, the feature has to be activated through the DIBS administration interface.

boolean

If the DIBS fraud protection finds the transaction to be suspect, the parameter "suspect=true" will be returned. The fraud protection feature needs to be activated through the DIBS administration interface.

integer

If the fraud protection is activated and swindle control is part of your agreement with DIBS, then the severity of a suspect authorisation is returned in this parameter. The higher the number, the more suspect the transaction is. DIBS recommends to check all authorisations with severity > 5.

string

Is returned only if "return_checksum" is sent when calling auth.cgi. The checksum is a one-way calculated 32-character string, based on the credit card number. The checksum is used for verifying that the information returned from DIBS. It can be used to check if a specific credit card has been used before.

string

The shop's original order identification number is returned.

optional

Parameters sent to auth.cgi as part of the accepturl are returned.

not a parameter

In the DIBS administration interface it is possible to enable the return of all parameters sent to auth.cgi, except credit card details.

string

ACCEPTED/DECLINED

integer

If the transaction is rejected, it returns with a reason for the rejection. Please refer to error codes for a list of possible values.

optional

All parameters sent to the DIBS server, as part of the cancelurl, are returned.

not a parameter

In the DIBS administration interface it is possible to enable the return of all parameters sent to auth.cgi, except credit card details.