Professional Documents
Culture Documents
Integration Manual With CTFClient v7.4
Integration Manual With CTFClient v7.4
CTFClient / AC
VERSION 7.4
This document contains confidential commercial and strategic aspects of Auttar company , its solutions and services , which were delivered
in restricted basis and may not be distributed , copied or disclosed to third parties without prior permission of the company
History
Review.
Emerson Polesi Creation of overview document.
Inclusion of the annex on device configuration.
Inclusion of new transactions.
Corrections in the second row of the bitmap POSENTRA.
Inclusion of new fields in POSENTRA.
Inclusion of return/new error codes.
00.00.10 18/08/2006 Emerson Polesi Last revision and preparation for disclosure.
00.00.11 22/08/2006 Emerson Polesi Change the references to "Java CTFClient" to "CTFClient".
00.00.12 04/04/2007 Tânia Alves Magro Inclusion of command 225 - Start Day, 226 - Card query and
227 - By pass.
Inclusion of new fields POSENTRA: 6 – Info, 7 – Timestamp, 8
– Password e 37 – AC name.
Changing field description 1 – POSENTRA operation code.
Inclusion of new fields POSSAIDA: transaction code of the
CTF, Password, NSU CTF original, input value, type of
warranty, the service Value, date of the first installments,
Installment value, date of the Original transaction, logo and
customer Balance. These fields are optional in POSSAIDA,
depending on the version of CTFClient.
Including return codes 25 - CTFClient error, 26 - Pinpad error
and 32 - Integration error
Description of the operation 225-Start Day.
00.00.13 17/04/2007 Tânia Alves Magro Review of the document:
-Index creation.
-Review of implemented operations.
-Integration's change notes via file in relation to ClientCTF for
Windows.
00.00.14 11/05/2007 Tânia Alves Magro Receipts reprint's commands review.
00.00.23 30/10/2007 Tânia Alves Magro Definition of new features for Paggo:
232 – Purchase credit in cash with cell phone;
233 – Purchase installment credit Shopkeeper with cell
phone;
34 – Purchase installment credit Administrator with cell
phone;
Review of maps of bytes of cancellation operations.
Definition of fields 70 – DDD and 71 – Phone.
00.00.24 14/11/2007 Marcos Luiz Gregório Changing the transaction code "cancellation Insurance
Company/PBM" to 31.
Inclusion of the error codes 5014, 5015, 5366.
Change in subfield 70 size to 3 positions
Change in the bitmap 232, 233 and 234
Change in format of the bits 2 and 5 of POSENTRA
Changing types of subfields in POSSAIDA 1 –Operation, 6 –
Return code.
Tânia Alves Magro
14/12/2007 Review of examples of POSENTRA transactions query that
must inform the field 33 – Transaction number equal to " 00"
(except the CDC Consultation).
Creating section 4.5 Transaction Number, detailing the
control sequencing of transactions conducted by AC.
00.00.25 17/12/2007 Tânia Alves Magro Description of when Card is present operation via Bypass.
00.00.26 20/12/2007 Tânia Alves Magro Detailed description of when Card is present operation via
Bypass.
00.00.27 03/01/2008 Tânia Alves Magro Review of Bit 62 field layout of when card is present load
operation via Bypass.
00.00.28 10/01/2008 Tânia Alves Magro Review of 62 Bit field layout of POSSAIDA's third row of the
Card is present query operation via Bypass.
00.00.29 06/02/2008 Tânia Alves Magro, Definition of the third line of POSSAIDA for the 1F operation,
Cláudio Montenegro returned to some authorizers (replacing operation 009 -
consulting the card number. Today implemented only for the
authorizer Salfer).
Review of maps of bytes to include the 7-byte as optional in
the operations with card and bypass.
Tânia Alves Magro MAC field definition in the first line of the POSSAIDA.
29/09/2008 Definition of fields 76 – Table code and 77 – Payment with
POSENTRA voucher balance
Tânia Alves Magro Definition of commands 240 – Title payment by credit card,
08/10/2008 241 - Collection payment with credit card and 242 - DETRAN
payment.
Definition of the map of bytes of command 240 - DETRAN
payment.
Definition of field 79 – DETRAN's payment data of POSENTRA.
Definition of the third line of POSSAIDA – DETRAN payment.
Example of DETRAN payment.
Standardization of names " Title " in place of " Compensation
Schedule" and " Collection " in place of " Agreement " and "
Carrier ".
Name change "Third line POSSAIDA - Electronic Payment
Private Label " to " Third line POSSAIDA - Electronic Payment
extended" .
00.00.38 20/01/2009 Tânia Alves Magro Definition of field 80 – Number of registration of the third line
of POSENTRA.
Changing the map of bytes of operation 128 - Generic
Cancellation to optionally treating the byte 80.
Review of byte maps of Title payment and card fundraiser
28/01/2009 Tânia Alves Magro operations: 230, 231, 240 and 241.
00.00.39 24/06/2009 Eduardo Santos Definition of commands – 118 Consultation Credit Financing,
126 – Typed Credit Finance query
00.00.40 30/10/2009 Eduardo Santos Correction of the starting position of the field "Interest rate"
in the third line of the file POSENTRA.
00.00.41 22/12/2009 Marcos Gregório Definition of the error codes 5377 and 5378
efinition of the transaction code of POSSAIDA at position 177
00.00.42 11/01/2010 Eduardo Santos Definition of the operations of integration with TEF Dialed:
900, 901 and 902
00.00.43 14/01/2010 Eduardo Santos Change in the definition of the bit 75 and inclusion of 81 and
82 bits. Definition of commands: 243 – CDC Electronic and
Eduardo Santos
Definition of operation 267 Cielo Credit ( this operation
Substitutes CDC operations 108 and 109, when acquiring
Cielo ).
56 06/09/2013 Tânia Alves Magro Changing the default document version numbering.
The operation 260 becomes identified as:
• 260 - Prepaid Card Activation
Auttar
Definition of operation 908 – Data capture on the pinpad.
Definition of the third line of POSSAIDA of the operation.
Review of Annex A – Return Codes
Exclusion of sessions 4.2.2 CLCTFDOS Component, and 4.2.3
CLCTFDOS Component of the Modularized Solution.
Exclusion of Annex E.
71 10/04/2017 Marcos Luiz Gregório Review of the POSENTRA bit:
• 77 – Allows partial approval of transaction value
Inclusion of error code 5404
Inclusion of operation 412 – Pre-authorization amendment
72 21/06/2017 Marcos Luiz Gregório Definition of operations and their bitmaps
• 335 – Credit 4All
• 336 – Debit 4All
73 27/09/2017 Marcos luiz Gregório Definition of the POSENTRA bit:
• 105 – Perform Authorizing Agent Financing Inquiry
• 106 – Software Descriptor
• 107 – Dymanic MCC
• 108 – Used Wallet
• 109 – Wallet Identifier
• 110 – Cell phone recharge type
Addition of optional bit 105 in operations:
• 112 - Credit
• 113 – Interest-free installment credit
• 114 – Installment credit with interest
• 120 – Digitized Credit
• 121 – Digitized credit in installment without interest
• 122 – Digitized credit in installment with interest
74 05/03/2018 Marcos Luiz Gregório Definition of operations and their bitmaps:
• 337 – Digital prepaid card inquiry
• 338 – Digital prepaid card
Definition of the POSENTRA bit:
• 111 – Digital prepaid card code
Definition of the third line of POSSAIDA for operation 338 –
Digital prepaid card
Resetting bit 88 – Authorizing Agent type for an alphanumeric
Inclusion of the new field in the first line of POSSAIDA: Carrier
verification method
1 INTRODUCTION ......................................................................................................................... 15
2 OVERVIEW ................................................................................................................................. 16
3 SOLUTION ARCHITECTURE...................................................................................................... 17
3.1 FLOW DIAGRAM FOR AC / CTFCLIENT INTEGRATION ............................................................. 18
3.1.1 FLOW DIAGRAM FOR AC / CTFCLIENT INTEGRATION WITH VOUCHER PRINTING... 20
3.1.2 FLOW DIAGRAM FOR AC / CTFCLIENT INTEGRATION WITHOUT PRINTING OF
RECEIPS 21
3.2 BY SOCKET TCP/IP INTEGRATION ............................................................................................... 22
3.3 INTEGRATION VIA FILE EXCHANGE ........................................................................................... 23
4 INTEGRATION PROCEDURES................................................................................................... 25
4.1 OPERATIONS ................................................................................................................................... 25
4.1.1 OPERATIONS WHEN CARD IN NOT PRESENT ................................................................... 31
4.2 INTEGRATION FOR EXCHANGE FILES ........................................................................................ 31
4.2.1 CLIENTCTF.EXE PROGRAM ................................................................................................. 31
4.2.2 LAYOUT OF THE INPUT FILE ............................................................................................... 32
First Line of POSENTRA ......................................................................................................... 32
Second Line of POSENTRA .................................................................................................... 33
Second Line of POSENTRA – Operationd Card of Present ..................................................... 37
Second Line of POSENTRA – Operations Performed through the Bypass ............................... 38
Third Line of POSENTRA........................................................................................................ 39
4.2.3 LAYOUT OF THE OUTPUT FILE ........................................................................................... 47
First Line of POSSAIDA .......................................................................................................... 47
Second Line of POSSAIDA ..................................................................................................... 51
Third Line of POSSAIDA ......................................................................................................... 51
Third Line of POSSAIDA – Pharmacy and PBM Agreement Query .......................................... 51
Third Line of POSSAIDA – AVS Query .................................................................................... 52
Third Line of POSSAIDA – Electronic Payment ....................................................................... 53
Third Line of POSSAIDA – SPC Analytical Query .................................................................... 53
Third Line of POSSAIDA – Digital Credit values query layout version = 1 ................................ 54
Third Line of POSSAIDA – To Credit values query layout version = 2 ...................................... 54
Third Line of POSSAIDA – For Digital Credit values query layoutversion = 3 ........................... 55
Third Line of POSSAIDA – For Digital Credit purchase layoutversion <= 2............................... 55
Third Line of POSSAIDA – For Digital Credit purchase layoutversion = 3................................. 56
Third Line of POSSAIDA – Configuration Query ...................................................................... 56
Third Line of POSSAIDA – Card Query ................................................................................... 57
Third Line of POSSAIDA – Invoice Payment............................................................................ 58
Third Line of POSSAIDA – Prepaid card query ........................................................................ 59
Third Line of POSSAIDA – Gas card purchase ........................................................................ 59
Third Line of POSSAIDA – For Credit Financing Consultation ................................................. 59
Third Line of POSSAIDA – For Electronic CDC and Guaranteed Purchase.............................. 60
Third line of POSSAIDA – Consultation of Multi-EC Establishments ........................................ 61
Third line of POSSAIDA – Activation of Prepaid Card .............................................................. 61
Third line of POSSAIDA – Digital Prepaid Card Consultation ................................................... 61
Third line of POSSAIDA – For Data Capture on Pinpad ........................................................... 62
4.3 BY SOCKET TCP/IP INTEGRATION ............................................................................................... 62
4.4 POSENTRA FILE ENCRYPTION...................................................................................................... 62
4.5 TRANSACTION NUMBER ............................................................................................................... 65
An application of business automation needs to integrate with the CTFClient when you want to
perform operations of EFT (electronic funds transfer) through the CTF. The CTF is responsible for the
implementation of electronic payments, i.e. for authorising and carrying out financial transactions
online, enabling the application of business automation make TEF transactions online with credit and
debit cards of all the "flags" (authorizers) on the market.
The CTFClient offers a simple, robust and comprehensive interface for conducting financial
transactions. Both products, CTFClient and CTF, meet the technical and functional specifications of
authorizers Cielo, Redecard, Amex, Mastercard, among others.
The CTFClient, in addition to operate seamlessly with a business automation, can also be used as a
stand alone application, i.e., independently, through interface (GUI) product itself, however, this
form of usage is not part of the scope of this document.
The creation of this document was based on the "user integration with ClientCTF for Windows –
version 01.03.28". The ClientCTF for Windows is an older version of the client for CTF, destined
exclusively to the Windows operating system.
All the differences between the ClientCTF integration for Windows and CTFClient will be highlighted
with Blue italic letters, with the objective of facilitating the work of adaptation of the integrators old
version for the new version.
For simplicity, this document will be used the abbreviation "AC" to refer to the Commercial
automation application. The ACs solutions include:
• PDV with Fiscal Printers.
• integrated with no fiscal printers.
• Telemarketing.
• E-Commerce (Internet).
• Of batch processing.
"With no card present operations", those held in AC of e-Commerce, Telemarketing and batch
processing. The flowchart and the operations of the integrations of these ACs are described in
specific sections for differentiate of integrations with gift card: PDV with or without fiscal printer.
2 Overview
Este documento está dividido nas seguintes seções:
Solution architecture
Contains the description of the EMV CTFClient; the description of the components of the solution;
flowcharts suggested integration as the solution of AC: PDV, e-Commerce, Telemarketing and batch;
and CTFClient communication mechanisms with the AC: socket connection TCP/IP and via file
exchange.
Integration procedures
It lists the operations implemented by CTFClient EMV ; the list of specific operations for with no card
present solutions (e- Commerce , Telemarketing and batch ) ; the description of integration for file
exchanges ; the description of integration across a TCP / IP socket connection ; the POSENTRA
encryption procedures for solutions without present card; the description of vouchers files; the
sequencing control of transactions by transaction number.
Contains the list of file POSSAIDA returns codes and their descriptions. The return code is the first
information verified by the AC to determine whether the transaction was approved.
Contains the list of file POSSAIDA returns codes, and their respective descriptions and suggested
actions for the commit operation.
Contains the list of the error codes from POSSAIDA file, and their respective descriptions and
suggested actions. The error code can be consulted by AC, when the transaction was rejected and if
Description of the peripheral drivers supported by Java CTFClient; description of the parameters
associated with each driver, that can be reported via POSENTRA.
3 Solution Architecture
For each transaction of TEF that the AC wishes to perform, it should send a request to the CTF
through the CTFClient containing the information relevant to the transaction in question. On the
other hand, the CTFClient returns to AC the outcome of the transaction and additional information.
If any information necessary for the completion of the transaction has not been provided by the AC,
it is requested by the CTFClient to the operator. This will capture through the communication with
the user interface (display and keyboard).
For debit and credit transactions, customer card referring to capture data : typing the number or
reading the magnetic stripe / chip , validity (if entered ) , last 4 digits ( when magnetic / chip) , CVV2 /
CVC2 , password. They can also be captured other information related to the transaction , such as
type of funding for installment transactions, the reference date for pre- dated debt, etc.
The CTFClient is solely responsible for accessing the PIN-Pad to perform card readings and passwords
captures of customers for transactions of TEF.
For certain operations of TEF, upon request, is required to send a confirmation. In these cases, the
application of the AC, after receiving approval and print the voucher, should send a confirmation of
the operation. The sending of the confirmation takes place similarly to the request.
All communications between AC, CTFClient and CTF Server are synchronous, i.e. the control is only
returned to the AC upon arrival of the response to the request of the transaction.
The integration of AC with the CTFClient can be made, as well as via TCP/IP socket, also through file
sharing.
Integration for Exchange of files is indicated for automations that already carry out integration with
the ClientCTF for Windows and who wish to migrate to the new CTFClient. This type of integration can
also be indicated for the automations that have difficulty in implementing communication via TCP/IP
socket.
The table below shows a brief description of each component (an integral system) integration
solution of CTFClient:
Component Function
AC or commercial automation Commercial automation application demand carrying out financial transactions by
the CTF Server: PDV, Telemarketing, e-Commerce and batch.
CTFClient Component responsible for controlling the capture of information related to
financial transactions (password, credit card, etc.) and make the communication
with the CTF Server.
CLIENTCTF Component responsible for providing the AC with CTFClient integration via file
sharing. Increases the degree of compatibility between the new CTFClient and
ClientCTF for Windows from the point of view of ACs already integrated with the
CTF..
CLCTFDOS Component responsible for providing integration, in the DOS operating system,
between the AC and the CTFClient, through file sharing mechanism. AC
applications of integration is available in 2: standard and modularized solutions.
For the DOS Modulizada Solution, see Appendix E.
CTF Server Financial transactions concentrator which controls the progress of the various
transactions of the various customers and interacts directly with the authorizers
for execution of those transactions.
Authorizer Company that administers the financial transaction information.
In most cases, the integration of AC with the CTF, focuses on the receive phase of a sales transaction
or bill payment. The sales transaction or bill payment can be completed with more than a transaction
of TEF (multiple transactions).
In multiple transactions, each transaction has a unique sequence number being the number of the
first transaction initiated on 1 (one). For example, if an operation is terminated with 3 TEF
transactions, the first will be the number 1, the second number 2, and the third the number 3. The
exception is given only to query transactions, where the number of the transaction must be 0 (zero).
After all requests for TEF receiving a related operation, the AC should print the vouchers for each
transaction of TEF adopted. If the AC can't print some of the vouchers, it should display the message
"PRINT PROBLEM. WANT TO REPRINT? Y/N "and wait for the operator to indicate if you want to try
the reprinting of the coupon or not.
After printing the vouchers, the AC must send a confirmation for each transaction approved. The
confirmation is made by sending the confirmation request to the CTF.
Other undoing treatments must be analyzed , such as difficulty in clearing the coupon tax , etc..
The flowchart below illustrates the expected behavior of the AC in the receiving phase as regards
transactions of TEF and integration with CTF through CTFClient.
Inicio da fase de
recebimento da AC
1
AC inicializa número da
transação TEF com 01 (*1)
AC imprime comprovante de
2 cada transação de TEF
realizada com sucesso na
N fase de recebimento atual a
A receber > 0? partir dos arquivos
CUPOMCTF.1nn ou
REDUZIDO.1nn
S e
CUPOMCTF.2nn
Operador seleciona
forma de pagamento
Fim da fase de
2 2
recebimento da AC
(*1) Operações de consulta não devem fazer parte do controle de número de transação.
Todas as solicitações de consulta devem possuir o número de transação "00".
This flowchart applies to AC that require no print proof of TEF, such as e-Commerce and batch
processing, and optionally to telemarketers. All these AC authorise their transactions with no card
present.
The flowchart below illustrates the expected behavior of AC integrated with the CTF through
CTFClient.
Inicio da fase de
recebimento da AC
1
AC inicializa número da
transação TEF com 01 (*1)
2
N Sucesso na N
A receber > 0? finalização do
pedido?
S S
AC criptografa a mensagem de
solicitação para o CTFClient
AC exibe mensagens
N
AC envia solicitação ao CTF através de aviso/erro
Sucesso?
do CTFClient e recebe resposta retornadas pelo
CTFClient
S
AC desconsidera o
AC incrementa número da
recebimento em
transação de TEF (*1)
questão
2 2
(*1) Operações de consulta não devem fazer parte do controle de número de transação.
Todas as solicitações de consulta devem possuir o número de transação "00".
On integration via socket TCP/IP messages are sent and received via a TCP/IP connection.
The diagram below illustrates the transactional flow in integration by TCP/IP socket:
Automação Comercial
2 5
CTF Server
3
4
Autorizadora
1. The AC determines which operation of TEF will be held, capture the data needed to carry out such
transaction, such as value, reference date, etc; open connection to the CTFClient, sends the
request and waits for the reply;
2. The CTFClient validates the transaction information, capture the information that have not been
passed by AC (if necessary), requests the transaction to the CTF and awaits the return of a
response;
3. The CTF requests the transaction to the authorizer and waits for the reply;
4. The authorizer processes the transaction and responds to the CTF.;
5. The CTF responds to the request of the CTFClient with the information received from the
authorizer and other relevant to the transaction control;
6. The CTFClient receives the CTF's response and sends it to the AC. The AC, in turn, verifies that the
transaction was successful and makes the appropriate treatments. The AC should only consider
that the transaction was successful and approved if the return code is "00".
In the integration for Exchange of files, request messages are sent in the file POSENTRA and the reply
messages are received in the POSSAIDA file. To control sending the request and receiving the
response, the AC makes use of the CLCTFDOS component (DOS operating system) or CLIENTCTF.EXE
program (other operating systems).
The diagram below illustrates the transactional flow in integration for Exchange files:
Automação Comercial
12
1
POSENTRA 2 11 POSSAIDA
3 CLIENTCTF.EXE 10
1 - AC gera POSENTRA
2 - AC executa CLIENTCTF.EXE
3 - CLIENTCTF.EXE carrega POSENTRA 4 9
4 - CLIENTCTF.EXE chama CTFClient
5 - CTFClient envia transação p/ CTF CTFClient
6 - CTF envia transação para Autorizadora
7 - Autorizadora responde p/ CTF
8 - CTF responde p/ CTFClient
9 - CTFClient responde p/ CLIENTCTF.EXE
10 - CLIENTCTF.EXE gera POSSAIDA 5 8
11 - CLIENTCTF.EXE retorna controle p/ AC
12 - AC carrega POSSAIDA
CTF Server
6
7
Autorizadora
1. The AC determines which operation of TEF will be held, capture the data needed to carry out such
transaction, such as value, reference date, etc; and generates the input file for the CTFClient
(POSENTRA) with this information;
2. The AC runs the CLIENTCTF.EXE program and waits for the completion of its implementation.
Although not recommended, if the AC use any executable call feature that does not wait for the
end of the execution to call CLIENTCTF.EXE, you will need to perform a loop to wait for generation
of the output file (POSSAIDA). In this case, the AC shall ensure the suspension of the execution of
the process (sleep), for a few milliseconds, each iteration of the loop, to avoid high CPU
consumption;
3. The CLIENTCTF.EXE performs the reading of the information from the POSENTRA file;
4. THE CLIENTCTF.EXE open connection with the CTFClient, calls the transaction and awaits the
receipt of the reply;
5. The CTFClient validates the transaction information, capture the information that have not been
passed by AC (if necessary), requests the transaction to the CTF and waits for the reply;
6. The CTF requests the transaction to the authorizer and waits for the reply;
7. The authorizer processes the transaction and responds to the CTF.;
8. The CTF responds to the request of the CTFClient with the information received from the
authorizer and other relevant to the transaction control;
9. The CTFClient receives the CTF's response and sends it to the CLIENTCTF.EXE;
10. THE CLIENTCTF.EXE writes the content of the response received from the CTFClient in the output
file (POSSAIDA);
11. THE CLIENTCTF.EXE terminates its execution, returning control to the AC;
12. The AC makes reading the POSSAIDA file with the result of the processing of the transaction,
checks whether the transaction was successful and makes the appropriate treatments. The AC
should only consider that the transaction was successful and approved if the return code is "00".
The set of ClientCTF for Windows operations was maintained, and new operations have been included
to meet the new EMV functionality of CTFClient.
Communication between the AC and the CTFClient can be done through the exchange of files, as was
already done by ClientCTF for Windows, or through a TCP/IP socket connection. The connection via
socket also follows the same layout of the files POSENTRA and POSSAIDA integration via file to format
the messages exchanged between the AC and the CTFClient.
4.1 Operations
An operation implements a EMV CTFClient-specific functionality. Each operation has a code and a
specific set of data, which must be informed by the AC in requests.
The table below contains the list of the operations supported by CTFClient.
006 Confirmation
007 Unmaking
008 (Home coupon) This operation was deleted
009 Card number query Not supported by the current version
010 Printing all the vouchers Not supported by the current version
011 Undoing all non-consolidated transactions Not supported by the current version
This operation was deleted. To reprint the
012 Reprint the last voucher last voucher, see section 4.5 Voucher
Files.
014 Reprint of the first voucher Not supported by the current version
015 Reprint of the next voucher Not supported by the current version
084 Check Confirmation Not supported by the current version
101 Debt
102 (Forced Magnetic Debt) This operation was deleted
103 Pre-dated debt
112 Credit
The CTFClient has POSENTRA and POSSAIDA layouts slightly different from those used by the ClientCTF
for Windows. All the differences with the previous version are marked in blue italics.
The CLIENTCTF component is described in section CLIENTCTF.EXE program, the CLCTFDOS component
is described in sections CLCTFDOS component and CLCTFDOS Modularized Solution component, the
POSENTRA file is described in the section: Input file layout and the POSSAIDA file is described in the
section: Output file layout. The section: Number of the Transaction should also be read to greater
understanding of the sequencing of transactions, which is made by AC. The section: Voucher Files
describes the types, the location and the nomenclature of files of receipts.
After installing, check CTFClient on the command line the value of the variable CTFCLIENT_HOME:
C:\>SET CTFCLIENT_HOME
CTFCLIENT_HOME=C:\Program files\Auttar\CTFClient
Where:
<dir_dados> is the directory of the files POSENTRA and POSSAIDA. When omitted, the POSENTRA and
POSSAIDA files will be read and written to the executing directory for the CLIENTCTF.EXE.
<dir_config> is the directory where are the configuration files of the CLIENTCTF.EXE. When omitted,
the CLIENTCTF.EXE looks for its configuration files in the directory where it is executed. Should be
used when the CLIENTCTF.Exe is run from another directory.
The two parameters of the CLIENTCTF. EXE are optional. If the directory path has blank spaces, use
quotation marks ("") in the names of the directories. Example:
If the POSENTRA contains the data of the card: card number, expiration of the card and security
code), this file will be encrypted by the AC after their formatting, as described in section POSENTRA
file encryption. Otherwise, the POSENTRA file must not be encrypted.
The table below shows the operations of CTFClient and their respective maps of bytes.
• The value ' 1 ' in the Nth position indicates the presence of the field N in the third row.
• The value ' 0 ' in the Nth position indicates that the field N is not present in this third line.
• The value ' X ' in the Nth position indicates that the field is optional, and may be passed to the
CTFClient. If passed, the value ' X ' of heading should be changed to ' 1 ', otherwise, should be
changed to ' 0 '.
Example: field "2-document number" can be passed or not, depending on if the AC wants to
inform the tax voucher number within the proof of TEF.
Map of bytes
Code Operation 12345678901234567890123456789012 34567890123456789012345678901234
56789012345678901234567890123456 78901234567890123456789012345678
00000000000000000000000000000000 10010000000000000000000000000000
004 CTFClient Version
00000000000000000000000000000000 00000000000000000000000000000000
00000000000000000000000000000000 1001000000000000XXXXXXXXXXXXXXXX
005 CTFClient parameters configuration
X0000000000XXX000000000000000000 00000000000000000000000000000000
0000000000000X000000000000000000 10010000000000000000000000000000
006 Confirmation
00000000000000000000000000000000 00000000000000000000000000000000
0000000000000X000000000000000000 10010000000000000000000000000000
007 Unmaking
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X0000X0000000000000XX00000 10010000000000000000000000000000
101 Debt
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X0001X00000000000000XX0000 10010000000000000000000000000000
103 Pre-dated debt
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X0101XX0000000000000X00000 10010000000000000000000000000000
104 Installment Debt
00000000000000000000000000000000 00000000000000000000000000000000
Installment debt with installment in XX0100X0101XX0000000000000X00000 10010000000000000000000000000000
105
cash 00000000000000000000000000000000 00000000000000000000000000000000
XX0100X0000000000000000000000000 10010000000000000000000000000000
106 Voucher Debt
000000000000X0000000000000000000 00000000000000000000000000000000
XX0100X0000000000000000000000000 10010000000000000000000000000000
107 Voucher / Card is present queries
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X010XXX0X00000000000X00000 10010000000000000000000000000000
108 CDC debt with installment in cash
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X0101XX0X00000000000X00000 10010000000000000000000000000000
109 CDC debt without installment in cash
00000000000000000000000000000000 00000000000000000000000000000000
XX01000010XXX0000000000000X00000 10010000000000000000000000000000
110 CDC with installment in cash query
00000000000000000000000000000000 00000000000000000000000000000000
XX010000101XX0000000000000X00000 10010000000000000000000000000000
111 CDC without installment in cash query
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X0000X00000000000000X00000 10010000000000000000000000000000
112 Credit
0000000000000000000X000000000000 00000000000000000000000000000000
113 Installment Credit Without Interest XX0100X0100X00000000000000X00000 10010000000000000000000000000000
XX0X0000000000000000000000000000 1001X000000000XX0000000000000000
260 Prepaid card activation
00000000000000000000000000000000 00000000000000000000000000000000
XX000000000000000000000000000000 1001X000000000XX0000000000000000
263 Present card query
00000000000000000000000000000000 00000000000000000000000000000000
XX0100X010XXX0X00000000000X00000 10010000000000000000000000000000
267 Cielo installment sales
00000000000000000000000000000000 00000000000000000000000000000000
Installment sales simulation with debit
268
card
Optionally, the field 2-number of the document may be sent by AC in POSENTRA. As this information
is echoed in the POSSAIDA, this information may be used to control and consistency of messages.
The Operations 006 - Confirmation and 007 - Unmaking should inform on POSENTRA the field 14 -
NSU CTF, echoed POSSAIDA's response message of the transaction approved.
Label:
Color Description
Red Indicates the necessary changes on a map of bytes
so that the operations may be performed with no
card present
Map of bytes
Code Operation 12345678901234567890123456789012 34567890123456789012345678901234
56789012345678901234567890123456 78901234567890123456789012345678
0X000000000001000000000000000000 10010000000000000000000000000000
006 Confirmation
00000000000000000000000000000000 00000000000000000000000000000000
0X000000000001000000000000000000 10010000000000000000000000000000
007 Unmaking
00000000000000000000000000000000 00000000000000000000000000000000
0X011000010000000000000010000000 10010000000000000000000000000000
120 Typed Credit
00000000000000000000000000000000 00000000000000000000000000000000
Typed Credit In Installments Without 0X011000110000000000000010000000 10010000000000000000000000000000
121
Interest 00000000000000000000000000000000 00000000000000000000000000000000
Typed Credit In Installments With 0X011000110000000000000010000000 10010000000000000000000000000000
122
Interest 00000000000000000000000000000000 00000000000000000000000000000000
0X0110000110010000000X0010000000 10010000000000000000000000000000
128 Generic Cancellation
00000000000000000000000000000000 00000000000000000000000000000000
The command "227" must be informed only in the first line of the POSENTRA. The map of bytes from
the second row of the POSENTRA must necessarily inform the first byte with value '1'. And the third
line of POSENTRA shall inform the field 1 – operation Code, the transaction code of the CTF that must
be executed (2 alphanumeric positions adjusted to the left with a white to the right).
Label:
Color Description
Blue italic Indicates only the operations that were performed
through specific commands for ClientCTF for
Windows, and began to be performed through the
command 227-Bypass.
Red Indicates the necessary changes on a map of bytes
so that the operations can be performed through the
command 227-Bypass
Black Indicates the new operations that have been
implemented in the CTFClient through the command
227-Bypass.
Map of bytes
Code Operation 12345678901234567890123456789012 34567890123456789012345678901234
56789012345678901234567890123456 78901234567890123456789012345678
1X000000000000000000010000000000 10010000000000000000000000000000
D7 E-Pharma Company Agreement query
00000000000000000000000000000000 00000000000000000000000000000000
1X010000000000000000010000000000 10010000000000000000000000000000
D8 E-Pharma Company Agreement sale
00000000000000000000000000000000 00000000000000000000000000000000
1X010000000001000000010000000000 10010000000000000000000000000000
31 Company/PBM Agreement Cancellation
00000000000000000000000000000000 00000000000000000000000000000000
1X0000X0000000000000010000000X00 10010000000000000000000000000000
E0 PBM Query
00000000000000000000000000000000 00000000000000000000000000000000
1X0100X0000000000000010000000X00 10010000000000000000000000000000
E1 PBM Sale
00000000000000000000000000000000 00000000000000000000000000000000
1X010XX00X0000000000010000000000 10010000000000000000000000000000
E8 Prepaid Card load
00X00000000000000000000000000000 00000000000000000000000000000000
1X010XX00X0000000000010000000000 10010000000000000000000000000000
EA Purchase with prepaid card
00X00000000000000000000000000000 00000000000000000000000000000000
1X010XX00X0000000000000000000000 10010000000000000000000000000000
EC Operation 00X00000000000000000000000000000 00000000000000000000000000000000
All fields larger than 32 are new and are implemented only in CTFClient. The fields not listed in this
document are reserved for future use.
For operation "243-CDC electronic" the field has the form 8N.
Present if the payment plan is equal to 03. Absent in other
cases (not captured).
The field has the format "nnnnn ', where:
- nnnnn is the code table with 5 positions.
47 Barcode 80 A • Barcode for paying bills
• Prepaid card barcode with 32 digits set to the left, and
filled with white on the right.
Where:
LLVAR IP/hostname
NNNNN Door (right justified with leading zeros)
PPPP Protocol (left-justified with space to right)
The last entry in the list must contain only the 00 of the name
/ IP size.
Example : assuming that the host list : Port : Protocol of CTF
servers have the following entries:
ctf1.auttar.com.br:1996:TCP
ctf2.auttar.com.br:1998:UDP
This parameter in the POSENTRA have the content:
“06018ctf1.auttar.com.br01996TCP
18ctf2.auttar.com.br01998UDP 00”.
51 Keyboard type 40 A Keyboard type identifier that should be used by CTFClient for
data entry (see annex D)
52 Keyboard parameters LLLVAR A .. 999 Parameters specific to the chosen type of keyboard. The
value of each parameter must be separated by ', ' (comma)
62 Parameters of the LLLVAR A .. 999 Parameters specific to the chosen type of barcode reader.
barcode reader The value of each parameter must be separated by ', '
(comma) (see annex D)
63 Type of document 40 A Identifier of the type of reader that will be used by CTFClient
reader for reading documents (see annex D)
64 Parameters of the LLLVAR A .. 999 Parameters specific to the chosen type of document reader.
document reader The value of each parameter must be separated by ', '
(comma) (see annex D)
65 Encrypted integration 1 N Indicates the POSENTRA encryption
0 – Not encrypted
1 – Encrypted
66 Form of payment of 2 N 01 - Payment with money
Corban 02 - Check
03 - Bank check
04 - Debt
05 - Credit
06 - Own card
67 Input mode 2 N Card input mode (Bypass)
68 Reading the CMC-7 1 N Indicates reading the CMC-7 check
0 – Not read
1 – Make reading
69 Date of issue 8 N Card issue date (DDMMYYYY)
(this information must be encrypted)
Inform the second terminal code that runs at the PDV with
delivery.
76 Reserved
77 Payment voucher 1 N
balance
78 Credit with mobile 1 N Indicates whether the credit flow can be directed to be paid
enabled with cell phone
0 – Not enabled
1 - Enabled
79 Reserved
80 Registration 20 A Registration number of the user who authorized the
cancellation.
81 Flag the transaction 1 N Indicates the environment in which the transaction was
origin originated:
Value Description
0 Default
1 Delivery, delivery terminal code should be
informed at bit 75
2 E-Commerce
82 Service values LLVAR..99 A Service data included on the sale transaction:
Code Field
01 Barcode
02 CPF
98 Identifier of the LLVAR A Identifier of the invoice to be informed when the field 97-
Invoice-Other type of the invoice Payment identification is filled
99 Form of invoice 2 N Form of payment of invoice ID:
payment ID 01 – Card
02 – Barcode
100 Date of shipment 8 N Date of shipment in format: DDMMAAAA
101 Identification of 2 N Identifies which data will be captured on Pinpad:
capture type on • 07 – Capture CPF
Pinpad
102 Multi-EC terminal 14 A Identifier used to assign the Multi-EC terminal. Usually, CNPJ
identifier or CPF is used to identify only one terminal.
103 Reserved -- -- --
104 Correct Solution 16 N Identifier of the “Boleto Mais” of the Correct Solution
Identifier
105 Perform Authorizing 1 N Flag that indicates whether in a credit transaction it will be
Agent Financing possible to implicitly make a financing consultation directly
Inquiry with the authorizing agent
106 Software Descriptor 22 A Software Descriptor to be sent to the sender.
XXX*YYYYYYYYYYYYYYYYYY
or
XXXXXXX*YYYYYYYYYYYYYY
or
XXXXXXXXXXXX*YYYYYYYYY
Where:
XXX... – Represents the name of the agency
YYY... – Represents the airline
Value Description
1 Visa Checkout
2 MasterPass
109 Wallet Identifier LLVAR A Digital Wallet Identifier
110 Cell phone recharge 1 A Cell phone recharge type:
type
Value Description
R Recharge
O Offer
• The first row has the fixed size of 460 bytes and contains fixed information (the format of the
first position until the 63rd and 67th position position until the 244ª position matches the
format of the 243 bytes from the first line of the POSSAIDA of the ClientCTF for Windows. The
exception is the response Code field has changed from 2 to 3 positions).
• The second row is of variable length and contains messages to display (this line does not exist
in the POSSAIDA of the ClientCTF for Windows. The ClientCTF for Windows reports the
message display in a field of the first row – position 176 (position 177 of the new layout),
which is not used by CTFClient).
• The third line is of variable size and is defined only for some operations (The third line of the
CTFClient settings match the settings of the second lines of the ClientCTF for Windows).
(The ClientCTF version for Windows had 1 or 2 lines: the first line with fixed size 243 bytes; the second
line with variable size and set only for some operations.)
Changing the layout of the first line of the POSSAIDA, as well as the definition of new bytes
(information) in the POSENTRA may occur in future versions of CTFClient, as "new features" are added
to the product. Despite this, the information already set (legacy) will be preserved as layouts and
definitions currently documented.
The first line of the POSSAIDA has fixed size, and on the basis of the information contained, the AC
will be able to:
• Identify the file as response to the requested transaction through the transaction code, the
terminal and the document;
• Identify the return code of CTFClient for the transaction requested (must be reviewed by the
AC). In cases of return codes other than "00"-Approved, there may be associated error codes.
• Identify the response code sent by the authorizer or by the CTF. For approved transactions
(return = "00") response code = "00". For transactions rejected by the authorizer (return =
"05") or rejected by the CTF (return = "11"), the response code is other than "00" and
indicates the reason for the rejection.
• Identify the transaction data passed through the approval code and NSU Authorized, sent by
the administrator, the NSU CTF, the value, the date and time of the transaction, etc..
The field "Return Code" POSSAIDA file must be parsed before any other field, because through it the
AC will define the next steps in carrying out the transaction. If the return code is different from 00, it
means that the transaction was not approved by authorizer or there is some other specific problem.
This line contains approval, error and warning messages that must be displayed by AC, regardless of
whether the transaction was approved or rejected.
The line can contain an indefinite number of concatenated messages in the format.
TTTMSGTTTMSG...TTTMSG000
Where each group TTTMSG corresponds to a message, and TTT three numeric digits representing the
following message size and MSG the message itself. The string is terminated with the value 000 to
TTT.
Each message "MSG" contains one or more rows, and in the case of more than one line, they are
separated by the character ASCII 10 (' \n ' or new line or line feed) or by the character ' # '.
The second line of the POSENTRA may contain only a 000, indicating that no messages to display.
The AC must display each message "MSG" separately, with display time of 15 seconds for each
message.
The third line of the POSSAIDA may or may not contain additional information specific to certain
operations. If the operation does not contain additional information, will go on POSSAIDA only the
finalizer for line feed (ASCII 10).
Below are listed the descriptions of third line of POSSAIDA for every operation that requires
additional information:
POS DESCRIPTION
1 Zip code does not match
2 CPF does not match
3 Address does not match
4 Issuing bank does not support AVS query
5 Connection problems with the issuing bank
6 [reserved]
7 [reserved]
8 [reserved]
9 [reserved]
10 [reserved]
11 [reserved]
12 [reserved]
13 [reserved]
14 [reserved]
15 [reserved]
16 [reserved]
0000000000000000
|||||[reserved]
|||||
||||Connection problems with the issuing bank
|||Issuing bank does not support AVS
||Address does not match
|CPF does not match
Zip code does not match
Examples:
Bitmap Meaning
0100000000000000 CPF does not match
1010000000000000 Zip code and address do not
match
0001000000000000 Issuing bank does not
support AVS
Barcode reader LLLVAR A..999 Parameters specific to the chosen type of barcode reader. The
parameters value of each parameter must be separated by ', ' (comma)
(see annex D)
Type of document 40 A Identifier of the type of reader that will be used by CTFClient
reader for reading documents (see annex D)
Parameters document LLLVAR A..999 Parameters specific to the chosen type of document reader.
reader The value of each parameter must be separated by ', '
(comma) (see annex D)
Encrypted integration 1 N Indicates the POSENTRA encryption
0 – Not encrypted
1 – Encrypted
Reading the CMC-7 1 N Indicates reading the CMC-7 check
0 – Not read
1 – Make reading
Credit with mobile 1 N Indicates whether the credit flow can be directed to be paid
enabled with cell phone
0 – Not enabled
1 – Enabled
Or
The third row contains data (N) financing plans when the number of parcels consulted is equal to
"00". The data size is 64 x N (number of plans).
Returned in the third row of the POSSAIDA of the operation:
• 118 – Financing Credit Consultation.
Integration with CTFClient for TCP/IP socket is accomplished through the establishment of a
connection between the AC and the CTFClient, the CTFClient as server for communication. The
default CTFClient connection port is 2500, but this can be modified by changes in configuration
parameter.
The connection is kept open until a response is sent by the CTFClient or until time-out. The
application of AC must configure the time-out of the socket to a value above that is configured for
the CTFClient in relation to the CTF. Typically, the time-out of the CTFClient is 30 seconds, but can be
modified through the configuration parameter. It is recommended that the time-out of the AC in
relation to the CTFClient is at least 3 seconds longer than the CTFClient in relation to the CTF.
Messages that travel in the socket, both in the AC-CTFClient and CTFClient-AC directions have exactly
the same layout of the files POSENTRA and POSSAIDA, described in sections: Input file layout and
Output file layout of this manual.
Some information, such as card number, security code and expiration date of the card are important
and sensitive information and may not be available in files, not liable to capture the network traffic.
Only in these cases, the AC, after proper formatting of the POSENTRA file, you should encrypt it to
ensure the privacy of information.
All POSENTRA formatted lines must be encrypted at once, and the resulting encrypted line must be
written to the final POSENTRA file, followed by a null character (' \0').
The encryption of the file POSENTRA should be done by the set_printable_msg function, available in
the dlls: CSISECURITY.DLL and CSICRYPTO.DLL, provided by Auttar.
• Set_printable_msg
Int set_printable_msg( char *origin, int size_origin, char *destiny, int size_destiny );
Libraries
Values returned
If the buffer is encrypted, set_printable_msg returns the size of the encrypted buffer. Otherwise,
returns 0 (zero).
Parameters
Origin
Address for the buffer to be encrypted.
Size_origin
Size of the message to be encrypted.
Destination
Address to the buffer that receives the encrypted data.
Size_destination
Maximum size of the target parameter.
The size_destiny value must be ((size_origin * 2) +32) * 4) +1. The application must allocate a
destination buffer of at least size size_destination to receive the encrypted data.
Example in C
#Include “csisecurity.h”
void get_ofusc_msg(char *msg)
{
int tam_str, tam_result;
char *result;
tam_str = strlen(msg);
tam_result = (((tam_str*2)+32)*4)+1;
result = (char*)malloc(tam_result);
if(result != NULL)
{
tam_result = set_printable_msg(msg, tam_str, result, tam_result-1);
result[tam_result] = 0;
if(tam_result > 0)
{
printf(“Arquivo POSENTRA formatado pela AC:\n\n%.*s\n\n”, tam_str, msg);
printf(“Arquivo POSENTRA encriptado pela função set_printable_msg:\n\n%.*s\n”, tam_result, result);
}
free(result);
}
}
Output
1184FFF9987A4FE65C968ECF4091BC0B080898416E86CA22456C8ABD847F6C79DCBD616717C36EF3F0FF4D0227B8BF0AF00C3967BD0200AC4D718378
4639B6EBB8B8F449113E9C1CCE8316DF81A253F08AF89A96D3F798AE5B715C3AEE9D543D33087B0E39201F4AA0691AD7AAED2817BF4FEA1277905A9
722DF9B6385E2221A4F20C1572AE31208BCDAB5BDD55522165570F923FA725F538E2D3CB4C6AC14551D7DFBC2299DE1EC9A78EDC2CEFE1C9B06238C
91D6B17F68BD091CCB053EC80C228C24ADF9D904CF93FC5615459EBCBD3B31ACD8F2F374B0529B1EC304F65472C852D76BC3CFC345610DA3F8EB68D
2D5F4AAB0757D7200926A35E341F355A486CE991FD3DF405BBC35D582BB2709DDD7F3A9EE4B2CB000E7F735CE0F31016169277C91A0099D062F0FF7
D6BF49AE8FB58B25A6C839F524255F1BACC364B45A421F5A37D9CB5F9A43E111A008C269C2FE9502F8E685F9AA1ABBD22157247E8034918446BC8C4F
E744A9486E812DB93D622A4267FC6CD83351F76E8B36C9AE630CEA7F5ABEE3650E31EA433C0F2EF3B9B85BA4A102A27E95AE7FB7DC3C0B14DA462C0
17BDB2A82AEC8125DC325B29F0E497028699F8000059B575B992EF2CBBF9862B59A7E8702BD3C1C16487CF3065408820592DC9F202E80882CFA9426F
CC8AC93D7175FD928F39BFD78163B3C9A53DC942535EC8628E3031B184677250D6E2BC72E32A7376A176EC36A748B12C3D36EAD6F99F6BD7EEACF17
09C7FE756879BA06A4337E2A2FF35C76D3A994FFE99B65D5CB082103010050
Option Explicit
Public Declare Function setPrintableMsg Lib "csisecurity.dll" Alias "set_printable_msg_VB" (ByVal strEntrada As String, ByVal iTamEnt As Integer, ByVal
strSaida As String, ByVal iTamSaida As Integer) As Integer
'Texto criptografado
Debug.Print strSaida
End Sub
The transaction number is the number that indicates the sequencing of the transaction within a
receiving phase and is entirely controlled by the AC, for both the mono transaction and the multiple
transactions.
The number of transaction is informed by the AC to the CTFClient through the field 33-Number of the
transaction. This field is compulsory use.
The transaction number must be controlled by the AC and restarted in "01" with each new phase.
The maximum number of transactions accepted by the CTF is "99".
In multiple transactions, each transaction has a unique sequence number being the number of the
first transaction started in "01". For example, if an operation is terminated with 3 TEF transactions,
the first will be the number "01", the second number "02" and the third the number "03".
The number refers to the transaction voucher number of TEF generated for print, and is displayed in
the extension NN of the CUPOMCTF.TNN file.
Transaction numbers equal to "00" indicate that this is a non-financial transaction that does not need
to be confirmed (example: query transactions, except the query CDC). Non-financial transactions
(with Number of Transaction = "00") can be interspersed in a string of financial transactions in the
same phase (with the transaction Numbers larger than "00").
Confirmation transactions should also be numbered and the undo transaction must have the number
= "01".
The vouchers are generated files in a subdirectory named EEEELLLL.TTT, created from the directory in
which the CTFClient was executed. In the directory name, EEEE represents the last 4 digits of Number
of the establishment, LLLL the store number and TTT Terminal number.
The run directory of CTFClient is the "bin" directory within the directory CTFClient installation. The
CTFClient installation directory can be obtained through the CTFCLIENT_HOME environment variable
(except for the DOS operating system).
For example: assuming the CTFClient installation directory is "C:\Program Files\Auttar\CTFClient", the
number of the establishment is 138, the store number is 10 and the Terminal number 23, the
coupons would be written to the directory "C:\Program Files\Auttar\CTFClient\bin\01380010.023".
Shortly after the request of an approved transaction, the CTFClient offers the following files
pertaining to the transaction of TEF recently held:
These coupons , the " nn " indicates the transaction number which the coupons relate.
Before the confirmation, these must be the coupon files used by the AC for printing of proofs.
The reduced proof (REDUCED. 1nn) can override via proof of client TEF (COUPONCTF. 1nn). In this
case, the proof is printed within the reduced tax sale coupon. Still, the reduced coupon may only be
used for the first transaction. Some transactions do not provide proof, such as buying and CDC
Consultation, cancellation, etc.
Only the proof of reprint of last approved transaction are available for reprint.
Note:
The CTFClient controls the replacement of files of receipts with each new transaction requested.
If the application of AC have practice remove the CUPOMCTF.*nn file immediately after the printing
of the proof, can only be removed from the files CUPOMCTF.1nn and CUPOMCTF.2nn. The files
The transactions will be processed according to their capture form: Typed, Magnetic or Chip.
The TEF Automation will obtain the list with all the stores registered for a certain establishment from
the query operation 329 – Consultation of Establishments Multi-EC, will be returned the store codes
and their descriptions. Commercial Automation can perform this query once a day and store or run it
whenever it deems it necessary.
The group code (PDV code that identifies the transaction) should be unique for the establishment
used, it will serve to identify only each Multi-EC terminal. The group code is previously registered in
the Auttar Portal.
To perform the transaction of a Multi-EC terminal, the Commercial Automation must select one of
the stores returned in 329 – Business Establishment Query and field 102 – Multi-EC terminal
identifier.
The file with the transaction request (POSENTRA) should be formatted with the following
information:
The detailing of the return on the third line of the POSSAIDA containing the stores when executing
the transaction “329” – Multi-EC Establishment Query will be detailed in the Third line of the
POSSAIDA section in chapter 4.2.5 – Output File Layout.
This section briefly describes the main operations. Indicates the input data that must be reported in
POSENTRA and details the step by step CTFClient integration with AC.
The term CTFClient is used in the "step by step integration" generically to refer to the CLCTFDOS
component (for the operating system) or the CLIENTCTF.Exe program(for other operating systems),
when using the integration via file. The integrations via TCPIP socket, the CTFClient is not executed.
The CA sends the POSENTRA the connection socket and waits for the response from POSSAIDA for
the same connection.
For clarity, follows the description of the characters used in the examples of POSENTRA:
character Description
Represents a blank space.
Represents line (line feed or ' \n ').
Will be omitted from the section "input data" the fields "33 – transaction number" and "36 - AC
Version", which are required in all operations.
CTFClient Version
Example
004000009999001 20060801
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00B19V004
Input data
The AC must perform the following steps to integrate with the CTFClient:
Example
005000009999001 20060801
0000000000000000000000000000000010010000000000001111111111111100000000000000000000000000000000000
0000000000000000000000000000000
00B19V004 09127.0.0.10250004615ctf1.auttar.com.br0166915ctf2.auttar.com.br0166900TECLADO_PC
000DISPLAY_Auttar 035LIBRARY:DisplayCSIWindows,1,251,252
DISPLAY_CTFCLIENT 000LEITOR_CARTAO_BIB_COMPARTILHADA 033COM1,”PASSE
O CARTAO”,” CSI”PINPAD_BIB_COMPARTILHADA 051COM1,” CSI”,”DIGITE A SENHA”,
” PROCESSANDO...”SCANNER_SERIAL 015COM1,9600,8,N,1
Confirmation
Example
006000009999001 20060801
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
01B19V004
Undoing
Undo operation of uncommitted or financial transactions that presented a misprint of their vouchers.
For tax operations completed with multiple financial transactions by simply sending an undoing
operation to undo all pending transactions.
Example
007000009999001 20060801
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
01B19V004
Debt in Cash
Input data
Optional fields may also be informed. If the field 26 – Withdraw is reported, this value should be
treated as a CHANGE in the fiscal printers: the value of the CARD should be added with the value of
the withdraw, and the AC will generate a CHANGE in the value of the withdraw.
The AC must perform the following steps to integrate with the CTFClient:
Example
POSENTRA file of debt in cash in the amount of $162,50 and service tax of $0,00:
101000009999001 20060801
Pre-dated Debt
Financial transaction performed with debit cards and charged in future date.
Input data
Example
103000009999001 20060801
0001000000100000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162501508200601B19V004
Debt In Installments
Financial transaction performed with debit cards splitted by the retailer, with the possibility of
scheduling the first installment. This transaction is not available for the Cielo authorizer.
Input data
Example
104000009999001 20060801
0001000010100000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
000000016250033108200601B19V004
Voucher
Financial transaction performed with Covenant cards (food, meal, etc.) in the in cash mode.
Input data
Example
105000009999001 20060801
0001000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00000001625001B19V004
Financial transaction performed with debit cards splitted as financing rules established by the card
issuer (interest rates, TAC, number of parcels, etc.), with the possibility of scheduling the first
installment.
Input data
Example
POSENTRA file of the CDC debit in 6 installments with scheduling of the first installment to 8/15/2006
in the amount of $162,50:
109000009999001 20060801
0001000010100000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
000000016250063108200601B19V004
Operation performed with debit cards to see the financing plans established by the card issuer. This
operation is not linked to the CDC sales transaction and does not compromise the balance of the
client.
The financing plans shall be informed through a TEF voucher to be printed (in a non-tax coupon) or
displayed on the screen of the terminal of the AC (for queries during the purchase, before the closing
of the controller coupon).
The proof of CDC Query may contain information such as: date of the first installment, TAC, plans
available and each plan: number of installments, interest rate, amount of parcels and total value.
Input data
The AC must perform the following steps to integrate with the CTFClient:
Example
POSENTRA file of CDC Consultation in 6 installments without scheduling the first installment in the
amount of $162,50:
110000009999001 20060801
0001000010100000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
000000016250060108200601B19V004
Financial transaction performed with credit cards in 3 modes available: in cash, shopkeeper and
administrator installments.
The shopkeeper financing, the merchant will receive the installment sale value, month to month
depending on the number of parcels set out in the Act for the transaction, and the cardholder will be
levied on your invoice.
In the administrator financing, the shopkeeper will receive the total amount of the sale within
contract, and the cardholder will be charged every month on your Bill, depending on the number of
installments stipulated at the time of the sale, including interest in force at the time the transaction
took place.
Input data
Examples
112000009999001 20060801
0001000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00000001625001B19V004
113000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500301B19V004
POSENTRA file of installment credit by the shopkeeper in 6 installments in the amount of $162,50:
114000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500601B19V004
Financial transaction performed with credit cards in 3 modes available: in cash, shopkeeper and
administrator installments. This operation is used by air companies. This transaction is available only
for the Redecard authorizer.
Input data
Examples
115000009999001 20060801
0001000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00000001625001B19V004
POSENTRA file of IATA credit in installment by the shopkeeper in 3 installments in the amount
of$162,50:
116000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500301B19V004
POSENTRA file of IATA credit in installment by the shopkeeper in 6 installments in the amount of
$162,50:
Credit Pre-Authorization
Financial transaction performed with credit cards. The administrator moves the credit limit of the
card, as a way of booking and guarantee the shopkeeper in available balance at the time of effecting
payment of the expense. This operation is used by the air companies, hotels and car rentals.
Input data
Examples
119000009999001 20060801
0001000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00000001625001B19V004
POSENTRA file of credit pre-authorization in the amount of $162,50 and shipment fee of $17,00:
119000009999001 20060801
0001000000000000000000000010000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00000001625000000000170001B19V004
Generic Cancellation
Operation of reversing financial transactions conducted with credit cards, debit cards and Covenant
(food, meal, etc).
Input data
Example
POSENTRA file for cancellation of the transaction of the day 8/1/2006 in the amount of $162,50 and
NSU CTF 123456:
128000009999001 20060801
0001000000100100000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500108200612345601B19V004
Pre-Authorization Confirmation
Financial transaction performed with credit cards in 3 modes available: in cash, shopkeeper and
administrator installments. This operation is used by the air companies, hotels and video store.
This transaction is available only for the Redecard and Amex. For the other authorizers, the sale
confirms the respective credit pre-authorization.
Input data
Examples
POSENTRA file of confirmation of credit in cash pre-authorization worth $ 100,00, whose pre-
authorization was held on 7/10/2006 with authorization code 999999:
Cancellation of Pre-authorization
Operation of reversing pre-authorization performed with credit cards. This transaction is available
only for Redecard. Optionally, you can use the operation 128 - Generic Cancellation to cancel pre-
clearance operations.
Input data
Examples
POSENTRA file pre-authorization cancellation of credit in cash for the amount of $162,50, whose pre-
authorization was held on 7/10/2006 with NSU CTF 123456 and authorization code 999999:
134000009999001 20060801
0001000000100100000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162501007200612345600699999901B19V004
AVS Query
Query operation AVS-address verification service is a service offered by the credit card authorizer to
the retailer and cardholder, to prevent fraud in transactions without the presence of the card.
This transaction is available for Redecard and Cielo. The Redecard AVS Query is available only to
typed cards. Is not returned TEF for printing voucher for this operation.
The POSENTRA of this operation was changed to the CTFClient.
Input data
The AC must perform the following steps to integrate with the CTFClient:
Examples
139000009999001 20060801
0000000000000000001100000000000010010111011000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
20000000762201983600B19V004 Rua Luigi Galvani 00004210º aBrooklin
04575-020
Service operation carried out with private label Redecard cards (Fininvest, Taií, etc). This transaction
is available to the private label Redecard.
Input data
Examples
POSENTRA file of Cash Private Label in cash with possibility of interest, in the amount of $162,50:
140000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500101B19V004
The query operation of the financing plans available for the operation of Cash Private Label. This
transaction is available to private label Redecard (Fininvest, Taií, etc).
Input data
Examples
POSENTRA file of the Private Label query in 3 installments in the amount of $162,50:
Purchase operation carried out with private label Redecard cards (Fininvest, Taií, etc). This
transaction is available to the private label Redecard. Optionally, this operation may be replaced by
credit operation as parameterization of the CTF.
Input data
Examples
POSENTRA file of the pre-date Private Label purchase (1 cycle), with plan defined by the authorized,
in the amount of $162,50:
142000009999001 20060801
0001000010000000000000000000000010010000000110000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500001B19V004 0100
The query operation of the financing plans available for Private Label Purchase. This transaction is
available to the Private Label Redecard (Fininvest, Taií, etc).
Input data
Examples
POSENTRA file of the Private Label Purchase Query in installments (3 parcels) pre-dated (1 cycle) with
interest (plan 2) in the amount of $162,50:
144000009999001 20060801
0001000010000000000000000000000010010000000110000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500300B19V004 0102
Financial transaction performed with credit cards in cash and shopkeeper installment. This operation
has been set for the Varig company use, and is available only to the Redecard credit.
Optionally, the AC can integrate with the pre-authorization transaction, replacing this operation, and
set up the CTF to convert the pre-authorizations Redecard in IATA Authorization.
Input data
Examples
146000009999001 20060801
0001000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00000001625001B19V004
The billing, schedule and ticket terms are synonymous. This operation is available for the
correspondent banking authorizer.
For integration with ClientCTF, just tell the transaction code 152 – payment of Title with query, the
CTFClient takes care to capture the barcode, the maturity, the values of the document, discounts and
surcharges, the input mode, the mode of payment (cash or check) and the CMC7 codeline (for check
mode). At the end of the operation, the ClientCTF returns in the third row of the POSSAIDA the
effective value of the operation and all other information that identifies the payment (see definition
of third line of POSSAIDA).
Payment with consultation is optional, however for some Authorizers of correspondent banking,
payment should not be preceded by a query, such as CB Bradesco currently integrated with the CTF.
Input data
Examples
POSENTRA file of the Title payment read 47990.0199 69180.00000 00103.73849 9 31530000020000,
in the amount of R$ 200,00, with R$0,20 discount and R$0,40 accruals, 5/26/2006 maturity, paid for
with money.
Payment of Title
The billing, schedule and ticket terms are synonymous. This operation is available for the
correspondent banking authorizers.
For integration with ClientCTF, just tell the transaction code 153 – payment of Title with query, the
CTFClient takes care to capture the barcode, the maturity, the values of the document, discounts and
surcharges, the input mode, the mode of payment (cash or check) and the CMC7 codeline (for check
mode). At the end of the operation, the ClientCTF returns in the third row of the POSSAIDA the
effective value of the operation and all other information that identifies the payment (see definition
of third line of POSSAIDA).
Input data
Examples
POSENTRA file of the Title payment read 47990.0199 69180.00000 00103.73849 9 31530000020000,
in the amount of R$200,00, with R$0,20 discount and R$0,40 accruals, 5/26/2006 maturity, paid for
with money.
153000000130130 20071001
1001000000100000000000000000000011110000000000110000000000000000010000000000000000000000000000000
0000000000000000000000000000000
The concessionary, agreement and collection terms have the same meaning. This operation is
available for the correspondent banking authorizers.
For integration with ClientCTF, just tell the transaction code 154-Payment of collection with query,
the CTFClient takes care to capture the bar code, the maturity, the values of the document, discounts
and surcharges, the input mode, the mode of payment (cash or check) and the CMC7 codeline (for
check mode). At the end of the operation, the ClientCTF returns in the third row of the POSSAIDA the
effective value of the operation and all other information that identifies the payment (see definition
of third line of POSSAIDA).
Payment with consultation is optional, however for some Authorizers of correspondent banking,
payment should not be preceded by a query, such as CB Bradesco currently integrated with the CTF.
Input data
Examples
Payment Collection
The concessionary, agreement and collection terms have the same meaning. This operation is
available for the correspondent banking authorizers.
For integration with ClientCTF, just tell the transaction code 155 – Payment of collection, the
CTFClient takes care to capture the barcode, the maturity, the values of the document, discounts and
surcharges, the input mode, the mode of payment (cash or check) and the CMC7 codeline (for check
mode). At the end of the operation, the ClientCTF returns in the third row of the POSSAIDA the
effective value of the operation and all other information that identifies the payment (see definition
of third line of POSSAIDA).
Input data
Examples
155000000130130 20071001
Title Query
The query is optional, and depends on the rules of the authorizer of correspondent banking, such as
CB Bradesco currently integrated with the CTF, the payment of revenues should not be preceded by a
query.
Input data
Example
Title query read whose code is 47990.0199 69180.00000 00103.73849 9 31530000020000, in the
amount of R$200,00, with R$0,20 discount and R$0,40 accruals, 5/26/2006 maturity.
180000000130130 20071001
1001000000100000000000000000000011110000000000110000000000000000000000000000000000000000000000000
0000000000000000000000000000000
1800000000200000110200700000000000020000000000040010109 47999315300000200000019969180000000010
373849 3
Collection Query
The query is optional, and depends on the rules of the authorizer of correspondent banking, such as
CB Bradesco currently integrated with the CTF, the payment of revenues should not be preceded by a
query.
Input data
Example
181000000130130 20071001
1001000000100000000000000000000011110000000000110000000000000000000000000000000000000000000000000
0000000000000000000000000000000
1810000000001000110200700000000000010000000000020010109 83600000000000000732920045084466910040
200336 3
Cancellation of Payment
Reversing operation of the Title and Collection payment operations. The generic cancellation
operation should be used in place of this one.
Input data
No input data.
Example
220000009999001 20060801
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00B19V004
Input data
No input data.
Example
221000009999001 20060801
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00B19V004
Start Day
Operation carried out at the beginning of the day after opening the fiscal printer. For non-tax
systems, this transaction should be sent once a day, before the start of operations or in the face of
day.
Input data
No input data.
Example
225000009999001 20060801
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
00B19V004
Operation performed to reprint vouchers formatted by CTF or the authorizer. You can reprint
vouchers of other dates.
Input data
Example
POSENTRA file of the reprinting of the transaction of NSU "123456" 7/31/2006 date ":
229000009999001 20060801
0000000000100100000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
3107200612345600B19V004
Check Query
Check query through data from the check and CPF/CNPJ.
Input data
For integration with ClientCTF, just tell the transaction code 129 - Check Query, that the CTFClient
takes care of capturing the necessary information and optionally the AC can inform the incoming data
in the file POSENTRA.
Examples
Example of an input file typed check query. R$10,00 check value, 10/9/2007 date, 81 area code,
phone 3455-0000, CPF type document (2) of number 123.456.789-09, check number 134, bank 237,
agency 3208, current account 93700 and countervailing square 123
129000000113130 20071009
1001000000100001111111000000000110010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
1290000000010000910200700000000013402373208200000012345678909000009370002400000000081003455000012
312300010109
Example of an input file of a check query reading the CMC-7. R$10,00 check value, 10/9/2007 date,
81 area code, phone 3455-0000, CPF document type (2) number 123.456.789-09 and CMC7:
<23732081<0070001345>477509370100:
129000000113130 20071009
1001000000100000001101000000001010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
12900000000100009102007200000012345678909024000000000810034550000000<23732081<0070001345>47750937
0100:00010109
Check Guarantee
Input data
For integration with ClientCTF, just tell the transaction code 137-Check guarantee, that the CTFClient
takes care of capturing the necessary information and optionally the AC can inform the incoming data
in the file POSENTRA.
Optionally the check data (check number, Bank, agency, current account and square), the AC may
provide CMC7:
• 31 – CMC7.
View layout field 22 - Bit 62 in the stream of operation 129 - Check Query:
Examples
Example of input file of a typed check guarantee. R$10,00, 10/9/2007 date, 81 area code, phone
3455-0000, CPF document type (2) number 123.456.789-09, check number 134, bank 237, agency
3208, current account 93700 and countervailing square 123
137000000113130 20071009
1001000000100001111111000000000110010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
1370000000010000910200700000000013402373208200000012345678909000009370002400000000081003455000012
312300010109
137000000113130 20071009
1001000000100000001101000000001010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
13700000000100009102007200000012345678909024000000000810034550000000<23732081<0070001345>47750937
0100:01010109
Operation sent to the mobile network operators to obtain the allowable values for the purchase.
Input data
Layout field 22 - Bit 62 for digital credit values and purchase query, set for layoutversion <= 2:
Layout field 22 - Bit 62 for digital credit values and purchase query, set to the layoutversion > 2:
The AC must perform the following steps to integrate with the CTFClient:
173000000005130 20070821
1000000000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
173027700818800123400 0100010108
POSENTRA file of digital credit values query with CLARO-NE (70), area code 81 and telephone
88001234:
173000000005130 20070821
1000000000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
1730317002810998800123400 0100010108
Currently the NTC (telephone number) informed has eleven positions, three for the area code and
eight for the phone number.
The size of the NTC will be expanded, by determination of ANATEL, from July 2012 for some regions
of Brazil, and the establishments and TEF solutions will have time to adapt.
The CTFClient will support up to three positions for the area code and up to thirteen positions for the
phone number.
The POSENTRA will be formatted by AC as the layout version of the Digital credit data configured in
the CTFClient: layoutversion parameter in the confClientCTF.xml file.
The CTFClient must be configured with the layoutversion = 3, to indicate that the NTC has variable
size.
The POSSAIDA will be formatted by CTFClient as the layout version of the Digital credit data
configured in the CTFClient: layoutversion parameter in the confClientCTF.xml file.
The digital credit vouchers will be formatted by the CTF with the NTC size as reported by CTFClient.
The AC must request the Digital credit purchase operation and provide the code of the operator
responsible for the purchase, the area code + phone number (returned in the query operation), the
value of the purchase and the indication of the type of credit (digital or PIN). All this information will
be captured through the query operation of Digital Credit values which should precede the purchase
operation, so the ClientCTF don't capture again this information and send it directly to the CTF.
The return of the CTF will be the approval or rejection of the purchase, with the coupon available
formatted for AC, in event of approval.
Input data
The AC must perform the following steps to integrate with the CTFClient:
• Captures the information necessary for the transaction.
• Generates the file POSENTRA for this operation, with the information captured in the previous
step;
• Running CTFClient, you will be able to capture some information pertaining to the transaction
such as: carrier, cellphone number, etc, in addition to request the authorization of the transaction
through the CTF;
• Waits for the return of the CTFClient;
• Handles the Return field of the POSSAIDA file as shown in the annex A:
• If equal to 00, still in the next step;
• If different from 00, handles the error and returns to the method of payment.
• Prints the 2 routes of TEF vouchers returned by CTFClient;
• Generates the POSENTRA file to the commit operation;
• Performs the CTFClient.
• Handles the Return field of the POSSAIDA file as shown in Annex B.
POSENTRA file of digital credit purchase with CLARO-NE operator (70), 81 area code, phone
88001234 in the amount of R$25,00:
174000000005130 20070821
1001000000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
174000000002500027700818800123400 0101010108
POSENTRA file of digital credit purchase with CLARO-NE operator (70), 81 area code, phone
88001234 in the amount of R$25,00:
174000000005130 20070821
1001000000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
1740000000025000317002810998800123400 0101010108
The AC must request the digital credit purchase operation without providing value, the operator
responsible for the purchase, phone number and the type of credit. The ClientCTF shall request all
information necessary for the transaction.
The return of the CTF will be the approval or rejection of the purchase, with the coupon available
formatted for AC, in event of approval.
Input data
The AC must not inform any specific field to Purchase Digital credit in POSENTRA
The AC must perform the following steps to integrate with the CTFClient:
Example
POSENTRA file of the digital credit purchase with query doesn't need the operator code, area code,
telephone nor the purchase value:
PBM Query
The PBM query operation was made through the command 204 - PBM Query in ClientCTF for
Windows, but at CTFClient this operation shall be performed through the command 227-Bypass.
The AC may request a PBM query through the authorization code or card number (typing or reading
the card number is enabled only for Novartis authorizer of network TrnCentre).
If the AC is integrated with more than one PBM authorizer, should be informed of the authorizer
code in POSENTRA. Not shipping the Authorizer code indicates to the CTF that the transaction will be
processed by the authorizer of choice for that transaction. Integrated authorizer codes by the CTF
are:
• 062 – E-Pharma
• 035 – Novartis
• 011 - VidaLink
In response the transaction authorised, is returned in the third row of the POSSAIDA, the Bit 62 field
with the list of authorised products.
Input data
The field 22 - bit 62 must be formed by the AC with the following layout:
Examples
PBM consultation with authorization code "000001977973" and authorizer code 35-Novartis:
227000000005130 20070821
1000000000000000000001000000010010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E0 028000000000001200000197797300035000000000000
PBM consultation without authorization code for authorizer 35-Novartis (the card is read through the
command 226 - card query):
226000000005130 20070821
1000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E0 000000000000
227000000005130 20070821
1000000000000000000001000000010010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E0 016000000000000000035000000000000
227000000005130 20070821
1000000000000000000001000000010010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E0 028012609172801200002403841500062000000000000
PBM Sale
The sale was made through the command 205 - PBM Sale in ClientCTF for Windows, but in CTFClient
this operation shall be performed through the command 227-Bypass.
• 062 – E-Pharma
• 035 – Novartis
• 011 - VidaLink
In response of the authorized transaction, is returned a coupon which must be printed on a coupon
tax not linked. This transaction needs to be confirmed.
Input data
The field 22 - bit 62 must be formed by the AC with the following layout:
• AC capture the authorization code, the Tax Document and the list of medications;
• AC generates an input file with the information captured, making the specified directory;
• AC runs the program ClientCTF;
• AC receives the return of operation, sent by ClientCTF;
• AC should check the return value of POSSAIDA:
Example
PBM Sale Novartis valued at $ 1.00 at the PDV 2 with fiscal number 123456, 3496 authorization code
and an item identified with the code 1111111111111:
227000000005130 20070821
1001000000000000000001000000010010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E1 0000000001000810002123456012000000003496053111111111111101000010000001000000100000009000001000
0035010000000000
PBM Sale E-Pharma in $123,20 value at the 126 PDV with fiscal number 091728, 24038415e
authorization code with 10 items of products identified with the code 7896016801501:
227000000005130 20070821
1001000000000000000001000000010010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E1 000000012320043012609172801200002403841501578960168015011062010000000000
PBM Cancellation
The PBM cancellation operation was made through the command 203 - PBM Cancellation in
ClientCTF for Windows, but in CTFClient this operation shall be performed through the command
227-Bypass.
There is no need to inform the authorizer code in POSENTRA. The AC shall inform the NSU CTF
original transaction, the number of PDV and the coupon number. For some authorizers it is necessary
to inform the Detail of the Products Cancelled.
In response of the authorized transaction, is returned a coupon which must be printed on a coupon
tax not linked. This transaction needs to be confirmed.
Input data
The field 22 - Bit 62 must be formed by the AC with the following layout:
Example
PBM Cancellation in the amount of $ 1.00 in PDV 2 with fiscal number 123456 and NSU CTF 890123:
227000000005130 20070821
1001000000000100000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
31 0000000001008901230160002123456000000010000000000
To finalize the sale with this receive mode, the AC requests one of these transactions to CTFClient.
The customer enters their mobile number on the pinpad. The authorizer sends an SMS message to
your phone. The client enter your password and confirm the operation. The authorizer returns the
transaction approved with a preformatted voucher. The AC prints the receipt and commits the
transaction.
Examples
232000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500101B19V004
POSENTRA file of credit in installment by the shopkeeper in 3 parcels in the amount of $162,50:
233000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500301B19V004
POSENTRA file of credit in installment by the shopkeeper in 6 parcels in the amount of $162,50:
114000009999001 20060801
0001000010000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
0000000162500601B19V004
The AC will request the prepaid card charge via the card number entered. Prepaid card number must
be entered in CTFClient itself, through operation 226- Card query. Alternatively, the card number can
be entered in POSENTRA file of the operation 227 - Bypass, however the POSENTRA file should be
encrypted.
Input data
The field 22 - Bit 62 must be formed by the AC with the following layout:
• AC generates an input file, with operation 226- card query (fill the field 1-Code of the operation
with "E8" and 33 - Number of the transaction with "00").
• AC runs the program ClientCTF;
• CTFClient will capture the entered card number and the expiration date.
• AC receives the return of operation, sent by ClientCTF;
• AC generates an input file, with operation 227-Bypass (fill the field 1 - Code of the operation with
"E8" and 33 - Number of the transaction with "01", in addition to the fields: 4- Value and 7-
Timestamp of the transaction).
Examples
Prepaid Card load of $ 50,00 with tax document number 123456 (card is read through the command
226 - card query):
226000000005130 20070821
1000000000000000000000000000000010010000000000000000000000000000000000001000000000000000000000000
0000000000000000000000000000000
E8 00000000000000
227000000005130 20070821
1001001000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E8 000000005000210820072057451060000000000000000000000000000000000000000000000000000000000123456F1
400000000000000000000000000000000000000N010000000000
Charge of $ 50,00 prepaid card 9999999999999999999 due 02/2009, with tax document number
123456 (card is passed in POSENTRA encrypted):
227000000005130 20070821
1001010001000000000001000000000010010000000000000000000000000000001000000000000000000000000000000
0000000000000000000000000000000
E8 0000000050001999999999999999999990902210820072057451060000000000000000000000000000000000000000
000000000000000000123456F1499999999999999999999999999999999999999N010000000000
The AC shall request the transfer of Prepaid Card, after reading the source and destination cards.
Card readings, typed or magnetic, will be made through operation 226- Card query.
Input data
Examples
226000000005130 20070821
1000000000000000000000000000000010010000000000000000000000000000000000001000000000000000000000000
0000000000000000000000000000000
E8 0000000000000
226000000005130 20070821
1000000000000000000000000000000010010000000000000000000000000000000000001000000000000000000000000
0000000000000000000000000000000
E8 0000000000000
227000000005130 20070821
1001001000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
The AC will request the purchase with the Prepaid Card via the card number entered. Prepaid card
number must be entered in CTFClient itself, through operation 226 - Card Query. Alternatively, the
card number can be entered in POSENTRA file of the operation 227-Bypass, however the POSENTRA
file should be encrypted.
Input data
The field 22 - Bit 62 must be formed by the AC with the following layout:
Examples
Purchase charge with Prepaid Card of $ 50,00 with tax document number 123456 (card is read
through the command 226- Card query):
226000000005130 20070821
1000000000000000000000000000000010010000000000000000000000000000000000001000000000000000000000000
0000000000000000000000000000000
EA 00000000000000
227000000005130 20070821
1001001000000000000001000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
EA 0000000050002108200720574505701234560000000000000000000000000000000000000000000000000001000000
0000
Purchase prepaid card 9999999999999999999 due 02/2009 in the amount of $ 50,00, with the tax
document number 123456 (card is passed in POSENTRA encrypted):
227000000005130 20070821
1001010001000000000001000000000010010000000000000000000000000000001000000000000000000000000000000
0000000000000000000000000000000
EA 0000000050001999999999999999999990902057012345600000000000000000000000000000000000000000000000
000010000000000
The AC will request the purchase with the Prepaid Card via the card number entered. Prepaid card
number must be entered in CTFClient itself, through operation 226- Card query. Alternatively, the
Input data
• AC generates an input file, with operation 226- Card query (fill the field 1-Code of the operation
with "EC" and the 33-Number of the transaction with "00").
• AC runs the program ClientCTF;
• CTFClient will capture the entered card number and the expiration date.
• AC receives the return of operation, sent by ClientCTF;
• AC generates an input file, with operation 227-Bypass (fill the field 1-Code of the operation with
"EC" and the 33-Number of the transaction with "00", in addition to the fields: 4-Value and 7-
Timestamp of the transaction).
• AC runs the program ClientCTF;
• AC receives the return of operation, sent by ClientCTF;
Examples
Prepaid Card query (the card is read through the command 226- Card query):
226000000005130 20070821
1000000000000000000000000000000010010000000000000000000000000000000000001000000000000000000000000
0000000000000000000000000000000
EC 00000000000000
227000000005130 20070821
1001001000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
EC 00000000000121082007205745000000000000
227000000005130 20070821
1001010001000000000000000000000010010000000000000000000000000000001000000000000000000000000000000
0000000000000000000000000000000
EC 0000000000011999999999999999999990902000000000000
The operation 226- card query also replaces the mechanism of integration of operation 009 – card
number query, used in the ClientCTF for Windows (legacy).
Input data
And the CA shall inform the POSENTRA of the next operation, in addition to the own fields of this
operation, the field 7-Timestamp of the transaction (the map of bytes of the aforementioned
operations has the byte 7 marked X-sending optional, and must be sent only to meet this integration
mechanism):
• 7 – Timestamp of the card query transaction (returned in the first line of the POSSAIDA
operation 226, transaction Date and time of the transaction).
• AC generates an input file, with operation 226- card Query (fill the field 1-code of the desired flow
Operation and the 33-Number of the transaction with "00").
• AC runs the program ClientCTF;
• CTFClient will capture the card number.
• AC receives the return of operation, sent by ClientCTF;
• AC generates an input file, with the following flow operation, informing the field 7-Timestamp
card query transaction.
• AC runs the program ClientCTF;
• AC receives the return of operation, sent by ClientCTF;
• (...)
Examples
226000000005130 20070821
1001000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
E8 000000005000000000000000
Purchase $ 50,00 credit and Timestamp "21082007205745" ("21082007" Transaction date and time
of the transaction "205745"):
112000000005130 20070821
1001001000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000
12 00000000500021082007205745010000000000
For integration with CTFClient, just tell the transaction code 182-query for Private Label card
payment, the CTFClient takes care to capture input data: the card number or the number of the
agreement or the barcode, the maturity of the document, the value of the payment.
This operation generates the third line of POSSAIDA-payment of Invoice, with the information that
identifies the payment, in addition to the data returned by the authorizer relating to payment:
amount due, minimum payment, discounts and values of additions, the forms of payments enabled,
etc.
Input data
• AC generates an input file, with operation 182- Query invoice payment (fill the field 33-
transaction number with "00").
• AC running CTFClient, you can capture some information pertaining to the transaction, such as
the card number, as well as to request the authorization of the transaction through the CTF;
Examples
182000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
000000000000
Payment of Invoice
The invoice Payment can be done by reading the card, typing the card, the number of the agreement
or of the barcode. This transaction is available for some authorizers, such as, IBI, Fininvest
Interchange, E-Capture and Orbitall.
For integration with CTFClient, just tell the transaction code 183-Invoice Payment, the CTFClient takes
care to capture input data: the card number or the number of the agreement or the barcode, the due
date of the document, the value of the payment, the input mode, the mode of payment (cash or
check), etc.
This operation generates the third line of POSSAIDA-payment of Invoice, with the information that
identifies the payment, in addition to the data returned by the authorizer relating to payment:
amount due, minimum payment, discounts and values of additions, the forms of payments enabled,
etc.
Input data
• AC generates an input file, with operation 183– Payment invoice (fill the field 33-Number of the
transaction with value > = "01").
Examples
183000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
010000000000
The CTF maintains in its database a directory of prepaid products for the establishment can manage
the product codes, values and rates applied in prepaid cards. The CTFClient tells the prepaid card
value, informed by the CTF, to be confirmed by the operator.
For integration with CTFClient, just tell the transaction code 260-Prepaid Card activation, the
CTFClient takes care to capture input data: the card number or barcode, and the actual amount of
money.
This operation generates a proof of TEF and can be committed or undone, but cannot be cancelled
(see Disabling operation of Prepaid Card to reverse the activation of the card).
Input data
• AC generates an input file, with operation 260-Prepaid Card activation (fill the field 33-Number of
the transaction with value > = "01").
• AC running CTFClient, you can capture some information pertaining to the transaction, such as
the card number or bar code, in addition to request the authorization of the transaction through
the CTF;
• Waits for the return of the CTFClient;
• Handles the Return field of the POSSAIDA file as shown in the annex A:
• If equal to 00, still in the next step;
• If different from 00, handles the error and returns ends.
• Prints the 2 routes of TEF vouchers returned by CTFClient;
• Generates the POSENTRA file to the confirmation operation;
• Performs the CTFClient.
• Treats the Return field of the POSSAIDA file as Annex B.
Examples
260000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
010000000000
260000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
01000000000050516440039100009877890000000000 3
This operation is not and does not need to be confirmed. See the section Prepaid Card activation for
more information.
Input data
Examples
Pre-authorization of prepaid card activation without telling the value and barcode:
272000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
000000000000
272000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
00000000000050516440039100009877890000000000 3
Input data
• AC generates an input file, with operation 272-Prepaid Card activation with pre-authorization (fill
the field 33-Number of the transaction with value > = "01").
• AC running CTFClient, you can capture some information pertaining to the transaction, such as
the card number or bar code, in addition to request the authorization of the transaction through
the CTF;
Examples
Prepaid card activation with pre-authorization, without telling the value and barcode:
273000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
010000000000
273000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
01000000000050516440039100009877890000000000 3
The deactivation is used to return a product or to invalidate a product after the initial sales
transaction. A rejection response is generated by the authorizer if the return of the product is not
possible.
This operation generates a proof of TEF and can be committed or undone, but cannot be canceled.
Input data
Examples
274000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
010000000000
274000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
01000000000050516440039100009877890000000000 3
Input data
Examples
263000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
000000000000
263000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
00000000000050516440039100009877890000000000 3
FastPIN Sale
The activation request FastPIN will ask the InComm system to return a response message containing
a PIN. The PIN and the terms and conditions are printed on the coupon of TEF generated by the CTF,
which should be used by the client to access.
This operation generates a proof of TEF and can be committed or undone, but cannot be cancelled
(see the operation Return FastPIN to return the product).
Input data
Examples
275000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
010000000000
275000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
01000000000050516440039100009877890000000000 3
Return FastPIN
This transaction allows the return of a PIN request authorized previously. If the product go through
all the verification steps, the InComm returns a response of success AC. A rejection response is
generated by the InComm if the return of the product is not possible. This operation generates a
proof of TEF and can be committed or undone, but it cannot be canceled.
Input data
Examples
276000000005130 20070821
0000000000000000000000000000000010010000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000
010000000000
276000000005130 20070821
0000000000000000000000000000000010010000000000110000000000000000000000000000000000000000000000000
000000000000000000000000000000
01000000000050516440039100009877890000000000 3
1004 Error in initialization of the communication layer. Check permissions of access to operating system
resources (INTERNET.TEF file access error).
1005 Network layer not initialized. Uninitialized network layer, to send the message to
the CTF:
• check if the transaction is being executed from
the same directory;
• If was executed the command "02-TEF-start";
• Check permissions of access to operating system
resources (INTERNET.TEF file access error).
1006 Network layer not initialized. Uninitialized network layer, when dealing with the
reply message from the CTF:
• Verify that has run the command "02-TEF-start";
• Check permissions of access to operating system
resources (INTERNET.TEF file access error).
1007 Network layer not initialized. Uninitialized network layer, when dealing with the
reply message from the CTF:
• Verify that has run the command "02-TEF-start";
• Check permissions of access to operating system
resources (INTERNET.TEF file access error).
1002 INTERNET.TEF file access error. • Verify that the transaction is being executed
1003 INTERNET.TEF file access error. from the same directory;
• If was executed the command "02-TEF-start";
Check permissions of access to operating system
resources (INTERNET.TEF file access error).
0200 Invalid parameters.
0201 Failed to open the channel of communication.
0202 Failed to resolve the address of the CTF. Verify the configuration of the Hosts file or DNS.
0203 Error in sending the message.
0204 Message sent from different size than expected.
0205 IP address is already in use.
0206 Error receiving message.
0001 Timeout.
0208 Error receiving message.
0209 Error receiving message.
The CTFClient uses input and output devices (peripherals) to capture and display information.
It is common that the capture passwords and card reading is performed from a single physical device,
commonly calling PIN-Pad, which has both functions.
If the AC does not specify a keyboard or a display to the CTFClient, this will use the devices that are
defined in its default configuration.
The CTFClient supports device-specific templates for each of the types cited. Each device has a
unique ID and requires a set of specific configuration parameters.
The following are the configuration parameters that each device requires for its proper operation:
Example: defaultDisplay
DISPLAY_CSI Format: name,type,charBegin,charEnd
name is the name of the driver or device ID of the DLL to be used. If the name
represents a DLL, it must be preceded by the string "LIBRARY:" and the file
extension of the DLL should not appear in the parameter.
Example 1) Linux with device driver: /dev/disp_csi
Example 2) Windows with DLL: LIBRARY:DisplayCSIWindows
charBegin e charEnd are control codes that enable the display of data in
displays and vary according to the type of the display as shown below:
For display type 0, charBegin = 0 and charEnd = 1
For display type 1, charBegin = 251 and charEnd =
252
Example: LIBRARY:DisplayCSIWindows,1,251,252
DISPLAY_CTFCLIENT This device requires no parameters.
KEYBOARD_JAVAPOS Format: name
Example: defaultKeyboard
KEYBOARD_PC This device requires no parameters.
DOCUMENT_READER_CHRONOS Format: door, speed, bitsData, parity, bitsStop
door is the name of the serial port to which the reader is connected.
speed is the serial communication speed in BAUD. The most commonly used
door is the name of the serial port to which the reader is connected.
speed is the serial communication speed in BAUD. The most commonly used
value for this parameter is 9600.
door is the name of the serial port to which the reader is connected.
speed is the serial communication speed in BAUD. The most commonly used
value for this parameter is 115200.
door is the name of the serial port to which the scanner is connected.
Example: defaultScanner
CARD_READER_BIB_SHARED Format: door,”message1”,”message2”
door is the name of the serial port to which the reader is connected.
message1 is the message that should be displayed in the display of the player
when the card is requested.
message2 is the message that should be displayed in the display of the player
when it is in use.
Message1 is the message that should be displayed in the display of the player
when it is in use.
Message2 is the message that should be displayed in the display of the player
when prompted for a password.
Message3 is the message that should be displayed in the display of the player
to warn that the client must wait for processing.
Example Windows:
COM1,” Auttar”,” ENTER THE PASSWORD”,” PROCESSING...”
Example Linux:
/dev/ttyS0,” Auttar”,” ENTER THE PASSWORD”,” PROCESSING...”