Once the facility is set up, the request files can be uploaded to the DIBS server at any time. However, before a request file is processed, a “run” file must also be uploaded to the DIBS server (i.e. to avoid the DIBS server to start processing request files that are not fully uploaded). The “run” file must have the same name as the request file, but with the extension .run instead of .txt. The actual time of processing the request files is decided by the DIBS server (to minimize the server load), usually processing happens several times a day. The response files are available for download once their equivalent .run file is also available in your ftp directory.
When using “Ticket capture” DIBS will create a new transaction on the amount specified in the file and at the same time make a capture on the new transaction. This means that the “Ticket response” file contains transactions that are already captured.
If a transaction in the batch is not immediately capturable (e.g. due to communication problems with the acquirer), the transaction is automatically saved for capture at a later time.
If the authorized transaction is too old (according to your acquirer authorization lifetime), it is automatically re-authorized before capture. If the re-authorization fails, the transaction is entirely rejected.
The file contains an optional DIBS CSV file header followed by the mandatory CSV part containing the comma-seperated values. The CSV_part has the format which is specified in the RFC-4180 standard (chapter 2). Apart from this format, the DIBS file format contains some extensions to the allowed characters, as specified in the section "Extension to RFC-4180".
DIBS CSV file format:
[DIBS_CSV_file_header] CSV_part CRLF
|DIBS_CSV_file_header||See section "DIBS CSV File Header syntax"|
|CSV_part||See the RFC-4180 standard|
|CRLF||CR + LF|
Please note that if you would like to use the optional CSV header in the CSV_part, it has to be declared in the DIBS_CSV_file_header. How to do this is explained in the DIBS CSV File Header content section below.
The DIBS CSV file header starts with a blank line, then the content of the header follows and the header is terminated by a blank line. Each (non-blank) line of the header must include a key and a value. The following specifies the format
DIBS CSV file header syntax:
CRLF header_line *(CRLF header_line) CRLF CRLF
|header_line||key COLON SPACE value|
|KEYDATA||%x30-39 / %x41-5a / %x61-7a|
|CRLF||CR + LF|
The value of the header_line ends at the CRLF character. The header format does not restrict the format of each value. The format of the value could depend on the key. The header format also doesn't restrict the usage of duplicate keys.
ShortKey: short value longKey: Long value containing special characters "'|~\$ longKey: another long value
Each service which uses the DIBS CSV file format may specify which headers are legal and whether duplicate keys are allowed. Generally assume that duplicate keys are not allowed.
In order to be able to use the optional header of the CSV_part, it is required to specify this by a header in the DIBS CSV file header. The DIBS CSV file header must include the following header:
Number of records
To ensure that the file hasn't been truncated, it is possible to specify a header, which denotes the number of records in the CSV_part. The number of records doesn't include the optional CSV header. To specify the number of records the reader must include a header called "NumberOfCsvRecords". As an example:
In RFC-4180, the allowed range of characters for the variable called TEXTDATA is:
TEXTDATA = %x20-21 / %x23-2B / %x2D-7E
In the DIBS CSV file format, the range of allowed characters is extended and is specified as:
TEXTDATA = %x20-21 / %x23-2B / %x2D-7E / %xA0-FF
The extended range includes the extra printable characters in the ISO-8859-1 character set.
Generally each service which uses the DIBS CSV format should specify which character encoding is used. By default assume that ASCII is used.