suppl_auth.cgi
(supplementary authorisation of a card transaction)
Note! suppl_auth.cgi is only valid for Dankort and Visa-Dankort transactions (Danish cards).
Description
suppl_auth.cgi is used to perform a supplementary authorisation of a null-authorised card transaction (see auth.cgi), as a first step of completion of a transaction capture (see capture.cgi). Essentially, the use of this function is equivalent to using the "confirm" link, which you will find for null-authorised transactions under "Payments | New / pending" in the DIBS Administration.
For compatibility reasons null-authorised transactions can be processed with capture.cgi without calling suppl_auth.cgi first, since capture.cgi will attempt an implicit supplementary authorisation first. However, it is recommended to use suppl_auth.cgi for explicit supplementary authorisation.
This function can only be successfully applied once to any transaction, and only on null-authorised transactions (i.e. payments which adhere to the three-stage model).
Function call
https://login:password@payment.architrade.com/cgi-adm/suppl_auth.cgi
Input parameters
suppl_auth.cgi accepts the following 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 |
| transact | The unique DIBS identification number for the transaction you want to capture. The transact is returned from a successful authorisation, and is a as minimum 6-digit integer , e.g. transact=123456. |
| 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. |
| [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). |
| [orderid] | The shops (unique) order identification number as given in the authorisation process. |
| [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> &transact=<transact>&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.
|
| [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. |
| [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 value
Parameter | Description |
| status | Denotes the result of the cancel request. It will hold on of two values: ACCEPTED/DECLINED |
Accepted supplementary authorisations furthermore return:
Parameter | Description |
| transact | The unique DIBS identification number for the transaction you want to capture. The transact is returned from a successful authorisation, and is a as minimum 6-digit integer , e.g. transact=123456. |
| cardtype | The cardtype used (see this list of possible cardtypes) |
Declined supplementary authorisations furthermore return:
Parameter | Description |
| reason | When declined a reason is returned in this parameter. See this list of possible reasons. |
Example
<form action="https://login:password @ payment.architrade.com/cgi-adm/suppl_auth.cgi" method="post">
<input type="hidden" name="merchant" value="1234567" />
<input type="hidden" name="amount" value="2000" />
<input type="hidden" name="transact" value="12345678" />
<input type="hidden" name="textreply" value="yes" />
<input type="hidden" name="md5key" value="cfcd208495d565ef66e7dff9f98764da" />
<input type="hidden" name="orderid" value="11223344" />
</form>
Security
In order to keep others from altering null-authorised transactions (such as changing the amount), suppl_auth.cgi requires a user name and password. See the above example. The user name and password are identical to the ones used for accessing DIBS Administration, or the ones pertaining to the special API user type, which can created in the administration.