FTP reports

The purpose of the FTP payment report is to provide you with detailed information about the purchases your customers have made. 
The reports can be used for reconciliation purposes.
The reports data can be compared to the payment information provided from the bank.

Overview

A report contains information of the bunch and detailed information about each
transaction in it. You can make an agreement with DIBS so that you will be able to get the
request parameters which you provide to DIBS, printed out in the reports as well.
 
Downloading payment reports
 
The ftp payment reports are stored on DIBS’s FTP server, paymentreport.debitech.com,
at an account for each customer. We support all standard d FTP remote commands for
send/receive and delete.
 
To download the files you use an ftp client and connect to paymentreport.debitech.com and supply
your username and password given by DIBS. Be sure the encryption is set to
"Require explicit FTP over TLS" and use port 21443. DIBS uses passive port range 50000 to 51000.
 
After the files are downloaded you decrypt the files using a GPG program installed on
your computer.
 
Using payment reports
 
The bunchreport.dtd file specifies what a payment report file, in XML format, looks like.
The dtd file is also stored at the ftp site in the publicfiles folder.
 
The file names for the payment reports are on Bxxxxxxxxyyyyyyyy.xml form where xxxxxxxx is
the shop id that you obtain from DIBS and yyyyyyyy is a serial number specific to each customer.
 
In the xml-file the dates are on yyyy-mm-dd form. Floating point number are on x.y form.
 
To verify that your system has not already read a report file you are advised to check that
there are no reports with the same id (the id field in the header) already in your system.
You should also check that the file is complete before you process it.
 
The number of transactions and the total amount in the header should be verified against the transactions.

File Format Specification

The file is in a straight-forward XML format. There are just a few node-levels in it.

The file format is described in detail below.
 
A file is built in the following structural way:
  • 1 bunchreport root node
    • 1 header node
    • 1 or several transaction nodes
      • 0, 1 or several parameter nodes
- The header node contains information common to all the transactions.
- A transaction node contains information about the transaction.
- A parameter node can provide extra information about the transaction.
 
An example of a file with only one transaction in it can be found below.
 
If there are no transactions to report about, then no file will be created and the
sequence number in the file name will remain just as it was.

 

Element name MaxLength Type Description Comments
id 20 Integer The id of the bunch. Mandatory
filecreationdate 10 Date
The day the file was
created (YYYYMM-
DD).
Mandatory
totalamount None Integer
The total sum of all
transaction
amounts.
Mandatory
batchcurrency 20 String
The currency of all
transaction in this
file.
Mandatory
acquirer 20 String
The name of the
acquirer used. In
the case of the
acquirer-node
Cekab is used, the
text “CEKAB”.
Mandatory
acquirercommission None Integer
The acquirer's
commission for the
entire payment.
Currently only used
for the acquirer
AmEx.
Dependant
acquirerextrainformation 20 String
Currently only used
for the acquirernode
Cekab. The
data in this field
gives information
about what kind of
cards was used for
the transactions. If
all the transactions
are made with
Diners cards, then
the text will be
“DINERS”. Same
way with Resurs
cards transactions –
“RESURS”. For all
other Cekab
transactions the
field will not be
used.
Dependant
numberoftransactions None Integer
The number of
transactions in this
file.
Mandatory

 

Element Name MaxLength Type Description Comments
type 20 String
The type of the
transaction. I.e.
settlement, refund.
Mandatory
referencenumber 20 Integer
DIBS's reference
number of the
purchase.
Mandatory
merchantreferencenumber 50 String
Your reference
number of the
purchase.
Optional
processdate 10 Date
The bankdate, i.e.
the date that the
bank made the
payment (YYYYMM-
DD).
Mandatory
creationdate 12 Date
The date when
DIBS received the
request from you to
make the
transaction.
Mandatory
amount None Integer
The amount of the
transaction. Given
in minour units.
E.g. 1 SEK should
be given as 100.
Mandatory
currency 20 String
The transaction's
currency.
Mandatory
firstname None String
The end-user's first
name.
Optional
surname None String
The end-user's last
name.
Optional
country None String
Where the endusers
lives.
Mandatory

 

Element Name MaxLength Type Description Comments
N/A None String
There are no fixed element
names to use. It is
completely optional to use
any parameters. The
merchant makes an
agreement with DIBS if they
want any parameters to show
up in this file and in that case
which. All the request
parameters that DIBS has
received from the merchant
can be used and some
systems parameters to.
Example could be invoiceNo.
Optional

 

<!--?xml version="1.0" encoding="ISO-8859-1" ?-->
<bunchreport><header>
<id>
1234
</id>
<filecreationdate>
2016-01-02
</filecreationdate>
<paymentdate>
2016-01-01
</paymentdate>
<totalamount>
25900
</totalamount>
<batchcurrency>
SEK
</batchcurrency>
<acquirer>
CEKAB
</acquirer>
<numberoftransactions>
1
</numberoftransactions></header>
<transaction>
<type>
settlement
</type>
<referencenumber>
9992866
</referencenumber>
<merchantreferencenumber>
ButikensReferensnummer
</merchantreferencenumber>
</transaction>
</bunchreport>
Do you have question or need help?
Follow us
DIBS Payment Services
Stockholm +46 (0)8-527 525 00
Göteborg +46 031-600 800
København +45 7020 3077
Oslo +47 21 55 44 00