auth.cgi

Description

The function auth.cgi performs the first part of a credit card transaction (the authorisation). The authorisation includes e.g. credit- and debit-card control and reservation of the required amount for later capture. auth.cgi can be used straight from a standard HTML form embedded in the website (web shop) using the DIBS payment window, but may also be called directly from one's own script. The latter requires a valid SSL certificate and the ability to perform an HTTPS request, e.g. through the DIBS DOT-NET , DIBS PHP Functions or DIBS Java Bean. Please note, that SSL connections require a PCI certification, as directed by Visa International.

Function call

https://payment.architrade.com/cgi-ssl/auth.cgi

Input parameters

The function auth.cgi accepts the following input parameters:

Parameter	Description
merchant	Shop identification. The Merchant number appears in the e-mail received from DIBS during registration with DIBS or on your contract. Your merchant number can also be retreived by contacting your respective DIBS support department below. Denmark Norway Sweden
amount	The smallest unit of an amount, eg. cent for EUR , øre for Danish crowns, Example: 1,00 EUR = 100 or 1,50 EUR =150
orderId	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 (both numerals and letters may be used).
textreply	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.
expyear	Card expiry year in two digits, 06 for 2006.
expmon	Card expiry month in two digits, 01 for january.
currency	Currency specification as indicated in ISO4217 where the EUR is no. 978. Either the numeric or alphabetic code is accepted. Also see our list of currencies.
cardno	Card number with no spacing.
[xid]	Transaction identification number for 3D-secure transactions.
[uniqueoid]	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.
[test]	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. 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).
[return_checksum]	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.
[preauth]	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 You cannot use "capturenow" along with "preauth".
[postype]	"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.
[md5key]	This variable enables a MD5 key control of the values received by DIBS. This control confirms that the values sent to DIBS has not been tampered with during the transfer. The MD5 key is calculated as: MD5(key2 + MD5(key1 + "merchant=<merchant>&orderid=<orderid>&currency= <currency>&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.
[ip]	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.
[fullreply]	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.
[cvc]	Card control values.
[confirm]	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".
[cavv]	Card authentication verification value. Is used in relation to 3D-secure transactions.
[cardtype]	"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.
[capturenow]	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).
[account_type]	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.
[account]	If multiple departments utilize the company’s acquirer agreement with the acquirer, 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.

Return parameters

The return parameters are dependant on the result of the authorisation. If the transaction was accepted then the return parameters are:

Parameter	Type	Description
transact	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.
status	string	ACCEPTED/DECLINED
[acquirer]	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.
[suspect]	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.
[severity]	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.
[checksum]	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.
[orderid]	string	The shop's original order identification number is returned.
[?x=&y=...]	optional	Parameters sent to auth.cgi as part of the accepturl are returned.
All values	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.

If the authorisation was not accepted the return parameters are:

Parameter	Type	Description
status	string	ACCEPTED/DECLINED
reason	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.
[?x=&y=...]	optional	Parameters sent to auth.cgi as part of the accepturl are returned.
All values	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.

Example

auth.cgi

Description

Function call

Input parameters

Parameter

Description

Return parameters

Parameter

Type

Description

Parameter

Type

Description

Example