suppl_auth.cgi is for performing 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).
Note that suppl_auth.cgi is only valid for Dankort and Visa-Dankort transactions.
This function requires an api user login for identification.
Below is an example of a authorization done using suppl_auth.cgi
<form method="post" action="https://login:firstname.lastname@example.org/cgi-adm/suppl_auth.cgi"> <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>
Essential input parameters
The smallest unit of an amount in the selected currency, following ISO4217 (see the currency list here).
Smallest unit for EUR is "cent" thus setting 'amount="150"' leads to the amount being 1,50 EUR
Smallest unit for JPY is "yen" thus setting 'amount="150"' leads to the amount being 150 JPY
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. See how MD5 is calculated here
Note: When using MD5, the order id must be unique.
Shop identification. The merchant ID appears in the e-mail received from DIBS during registration with DIBS or on your contract.
Should be declared to receive the returned message in simple text format.
The unique DIBS identification number for the transaction.
*: Mandatory parameters
Optional input parameters
If multiple departments utilize the same DIBS account, it may be practical to keep the transactions separate at DIBS. An account name may be inserted in this field, to separate transactions at DIBS.
To get an account, please contact the DIBS sales department.
|fullreply||If this variable is set, all variables will be returned (as defined in the DIBS admin).|
The shop’s order number for this particular purchase. It can be seen later when a payment is captured, and will in some instances appear on the customer’s bank statement (both numerals and letters may be used).
When this field is declared, the transaction is not dispatched to the card issuer, but is instead handled by the DIBS test environment. When the shop goes live, the test system is normally disabled, and should the shop want to use the test mode at a later date the DIBS support can be contacted for reactivation.
The below parameters are returned by suppl_auth.cgi if the authorisation is accepted.
|cardtype||Returns the type of payment the customer has used for a particular payment.|
The unique DIBS identification number for the transaction. The transact is a as minimum 6-digit integer, e.g. transact=123456.
If the authorization is declined, the parameters below are returned.
|reason||Returns a reason for the rejection.|