Show more > Triniz format > File structure

File structure

The file is structured and could have different purposes according to the compilation of the detail records.

The file is codified with ASCII characters, each record ends with CRLF (CR = ASCII code 13 decimal ; LF = ASCII code 10 decimal).

The Accounting for Entry acknowledgement records are 126 characters long and end with two CRLF characters (total record length: 128).

The Recurring Payments and Authorisations for posting via file records are 190 characters long and end with two CRLF characters (total record length: 192).

Alphanumerical fields (Type = A) are aligned on the left and filled in on the right with whitespace, whereas numerical fields (Type = N) are aligned to the left and filled in with zeros.

Each accounting block (COINIZ-COFINE) can contain up to 9999 transactions, as the transaction progressive number is 4 characters long. Upon exceeding the threshold of 9999 transactions, you must create a new accounting block.

The file structure requires: opening of the TRINIZ record, opening of the COINIZ record, writing of detail records, writing of the COFINE record, closing of the flow with TRFINE record.

Structure detail

Record	Record Prefix	Descrizione
Start of transmission	TRINIZ	File opening record
Start of entry	COINIZ	Accounting block opening record
Detail	-	Detail record
End of entry	COFINE	Accounting block closing record
End of transmission	TRFINE	File closing record

MSG TRINIZ – start of transmission

Nr.	Position	Length	Type	Description
1	01	6	A	“TRINIZ”
2	07	5	N	Customer Code (generated and notified by Nexi)
3	12	6	N	File creation date (ddmmyy, i.e. 16 for the year 2016)
4	18	6	N	File creation time (hhmmss)
5	24	1	A	“T”
6	25	3	A	“E45”
7	28	3	N	Progressive number of batch file transmission (starting from 001, up to 999 and then again from 001, it must always be different from 000 and incremented by one, in order to observe any transmission failure)
8	31	1	A	“A”
9	32	1	A	Whitespace
10	33	1	A	“D” (for Clients who supports MultiCurrency payments only) else whitespace
11	34	1	A	“R” (for Clients who supports Recurring payments only) else whitespace
12	35	92 for Accounting for Entry acknowledgement record 156 for Recurring Payments and Authorisations for posting via file records	A	Whitespace

MSG COINIZ – start of entry

Nr.	Position	Length	Type	Description
1	01	6	A	“COINIZ”
2	07	5	N	Customer Code (generated and notified by Nexi)
3	12	6	N	File creation date (ddmmyy, i.e. 16 for the year 2016)
4	18	6	N	File creation time (hhmmss)
5	24	1	N	Set with the last digit of the year (e.g. 2 for 2012)
6	25	3	N	Progressive number of the entry within the file (starting from 001 and it must be incremented by one, creating a new accounting block COINIZCOFINE, only when it reaches 9999 transactions in detail records)
7	28	2	N	“50” (euro)
8	30	97 for Accounting for Entry acknowledgement record 161 for Recurring Payments and Authorisations for posting via file records	A	Whitespace

MSG DETAIL – Detail record

Build the detail record depending on the aim of the file, then describe some types of MSG DETAIL (for posting via file, recurring payments).

MSG COFINE – end of entry

Nr.	Position	Length	Type	Description
1	01	6	A	“COFINE”
2	07	5	N	Customer Code (generated and notified by Nexi)
3	12	1	N	“0”
4	13	3	N	Progressive number of the corresponding entry (equal to field 6 of COINIZ)
5	16	5	N	Total records from COINIZ to COFINE (included)
6	21	12	N	Total posting amounts (the last 2 digits correspond to decimal numbers)
7	33	12	N	Zeros
8	45	12	N	Total reversal amounts (the last 2 digits correspond to decimal numbers)
9	57	6	N	File creation date (ddmmyy, i.e. 16 for the year 2016)
10	63	6	N	Entry date (ddmmyy, i.e. 16 for the year 2016) [same as file creation date]
11	69	58 for Accounting for Entry acknowledgement record 122 for Recurring Payments and Authorisations for posting via file records	A	Whitespace

MSG TRFINE – end of transmission

Nr.	Position	Length	Type	Description
1	01	6	A	“TRFINE”
2	07	5	N	Customer Code (generated and notified by Nexi)
3	12	5	N	N Total records from TRINIZ to TRFINE (included)
4	17	110 for Accounting for Entry acknowledgement record 174 for Recurring Payments and Authorisations for posting via file records	A	Whitespace

MSG DETAIL – Detail record for Accounting for Entry acknowledgement for posting via file

Merchants using this method request posting by sending an archive containing any approved operations to be posted. Each authorised detail account entry contained in the archive is posted (debit/credit).

Nr.	Position	Length	Type	Description
1	01	1	N	“0”
2	02	9	N	Merchant Code (generated and notified by Nexi)
3	11	8	N	Terminal Code (generated and notified by Nexi)
4	19	3	N	Progressive number of the corresponding entry (equal to field 6 of COINIZ)
5	22	4	N	Progressive number of the transaction (starting from 0001 up to 9999 and then one must create another accounting block COINIZ-COFINE with the progressive number by 1)
6	26	6	N	Transaction date (ddmmyy, i.e. 16 for the year 2016)
7	32	4	N	Transaction time (hhmm)
8	36	23	A	Whitespace
9	59	9	N	Amount (the last 2 digits correspond to decimal numbers)
10	68	6	A	Authorisation Code = in the "Auth" field available in the response message from Nexi
11	74	3	A	Whitespace
12	77	1	A	“1”
13	78	1	A	“0” (posting) “7” (reversal)
14	79	12	A	Retrieval Reference Number = in the “rrn” field available in the response message from Nexi
15	91	18	A	Transaction Reference sent from the Merchant in Initialisation phase (can contain only letters and numbers and must be absolutely unique)
16	109	18	A	Whitespace

MSG DETAIL – Detail record for Recurring Payments

Merchants may request to perform debits subsequent to the activation by sending an electronic archive. The debit request will then be made for each detail record.

Nr.	Position	Length	Type	Description
1	01	1	N	“0”
2	02	9	N	Merchant Code (generated and notified by Nexi)
3	11	8	N	Terminal Code (generated and notified by Nexi)
4	19	3	N	Progressive number of the corresponding entry (equal to field 6 of COINIZ)
5	22	4	N	Progressive number of the transaction (starting from 0001 up to 9999 and then one must create another accounting block COINIZ-COFINE with the progressive number by 1)
6	26	6	N	File Creation date (ddmmyy, i.e. 16 for the year 2016)
7	32	4	N	File Creation time (hhmm)
8	36	23	A	Whitespace
9	59	9	N	Amount (the last 2 digits correspond to decimal numbers)
10	68	6	A	Authorisation Code Upon request by the Customer: filled with whitespace Upon response by Nexi: filled in if the transaction was authorised whitespace if the authorisation was denied
11	74	3	A	Whitespace
12	77	1	A	“1”
13	78	1	A	Transaction Type 0 = purchase 7 = reversal
14	79	12	A	RRN (Retrieval Reference Number) Upon request by the Customer: filled with whitespace upon response by Nexi: filled in
15	91	18	A	Transaction Operation (can contain only letters and numbers and must be absolutely unique - this was the contract code for the old management of recurring payments)
16	109	18	A	Whitespace
17	127	30	A	Available to the customer
18	157	3	A	Response Code Upon request by the Customer:: filled with whitespace upon response by Nexi: filled in with the Response Code (see table ISO Response Code)
19	160	8	A	Authorisation date (yyyymmdd) Upon request by the Customer: filled with whitespace upon response by Nexi: filled in
20	168	18	A	Walletid created by the Merchants and used instead of the PAN
21	186	5	A	Whitespace

MSG DETAIL – Detail record for Authorisations for posting via file

Merchants may request to perform authorisations to the activation by sending an electronic archive. The authorisation request will then be made for each detail record. PCI-DSS validation is mandatory to request this service.

Nr.	Position	Length	Type	Description
1	01	1	N	“0”
2	02	9	N	Merchant Code (generated and notified by Nexi)
3	11	8	N	Terminal Code (generated and notified by Nexi)
4	19	3	N	Progressive number of the corresponding entry (equal to field 6 of COINIZ)
5	22	4	N	Progressive number of the transaction (starting from 0001 up to 9999 and then one must create another accounting block COINIZ-COFINE with the progressive number by 1)
6	26	6	N	Transaction date (ddmmyy, i.e. 16 for the year 2016)
7	32	4	N	Transaction time (hhmm)
8	36	19	A	Card number (for customers who maintain the store card) else whitespaces
9	55	4	N	Expiry date (for customers who maintain the store card) else whitespaces
10	59	9	N	Amount (the last 2 digits correspond to decimal numbers)
11	68	6	A	Authorisation Code Upon request by the Customer: filled with whitespace Upon response by Nexi: filled in if the transaction was authorised whitespace if the authorisation was denied
12	74	3	A	Whitespace
13	77	1	A	“1”
14	78	1	A	Transaction Type 0 = purchase 7 = reversal
15	79	12	A	RRN (Retrieval Reference Number) Upon request by the Customer: filled with whitespace Upon response by Nexi: filled in
16	91	18	A	Transaction Operation (can contain only letters and numbers and must be absolutely unique)
17	109	3	A	Response Code Upon request by the Customer: filled with whitespace Upon response by Nexi: filled in with the Rsponse Code (see table “ISO Response Code”)
18	112	2	A	Whitespace
19	114	3	A	Currency code (for customers who run the multicurrency) else whitespaces
20	117	9	N	Amount in currency - the last 2 digits correspond to decimal numbers (for customers who run the multicurrency) else whitespaces
21	126	65	A	Whitespace