Biblioteca de Integração (SDK) Android (v3.6.0)
Observação: Levar em consideração a última versão da lib gsurf.aar disponível para o modelo de terminal a ser utilizado com relação à documentação de integração abaixo.
Aplicabilidade do Material:
A integração com a biblioteca SDK GSURF permitirá a Aplicação Android autenticar-se no sistema SC3 GSURF e efetuar pagamentos dentro do ecossistema GSURF.
Linguagens suportadas:
Kotlin ou Java (somente linguagem nativa), por conta do conceito de Activity que é necessária por parâmetro no uso do nosso SDK.
Configuração loja portal SC3 GSURF:
Loja do portal SC3 (onde vai ser criado o terminal ou user/senha para ativação) precisa está configurada com o Tipo de Adquirência como Sub Adquirente.
Fluxo de Autenticação:
O fluxo de autenticação se dá pela verificação se há ou não um certificado instalado, certificado este que é recebido da plataforma SC3 assim que as credenciais são validadas.

Observação: Fica a critério da integração optar em utilizar as funções de requisição de verificação e instalação de certificado para que o fluxo de autenticação seja realizado ou através de OTP e S/N ou através de usuário e senha, conforme explicado a seguir:
Fluxo de Autenticação do Android POS (OTP e Número de Série):
No fluxo de autenticação por OTP e número de série, o APOS previamente cadastrado em Loja no SC3 com os dados
do terminal, deverá ser autenticado através de chave de ativação (OTP) e número serial. Quanto ao número de série do
terminal, tratado pelo parâmetro "device", este pode ser atribuído como padrão utilizando-se o método do Android
"Build.SERIAL" do qual retorna o número serial, informação esta que pode ser verificada na área "Sobre o telefone" ->
"Número de série" presente nas Configurações Android do APOS. Observações: A utilização do método
"Build.SERIAL" pode ser aplicada somente aos modelos GPOS700MINI e GPOS700X da Gertec, A8 da Ingenico,
N910 da Newland, A910 e A920 da Pax e X990 da Verifone. Para os modelos GPOS700, GPOS720, GPOS760 e
GPOS780 da Gertec, e DX8000 da Ingenico, se faz necessária a coleta do número serial com base nos métodos
estabelecidos pelos próprios fabricantes, pois o método "Build.SERIAL" para ambos os modelos não retorna o dado
esperado. Quanto ao modelo Smartphone, recomenda-se a autenticação somente através do fluxo do Android Mobile
(com usuário e senha).
Fluxo de Autenticação do Android Mobile (Usuário e Senha):
No fluxo de autenticação por usuário e senha, existem dois diferentes tipos de usuários Mobile, o Master que é único por Loja no SC3, onde todo e qualquer primeiro usuário cadastrado torna-se deste tipo, e os demais que são considerados como novos usuários/terminais "abaixo" do usuário Master. A autenticação do usuário Master é realizada através de usuário e senha previamente cadastrados em Loja no SC3, já a autenticação do novo usuário/terminal pode ser realizada através de uma String contendo a "key", ou também via leitura de QR Code que neste caso fica a cargo de implementação por parte da integração, onde em ambos os procedimentos a chave é anteriormente gerada pelo usuário Master, este que controla toda e qualquer adição de novos usuários/terminais a partir dele mesmo.
Informações Gerais:
-
Caso seja retornado o código de resposta "400" indicando erro durante o fluxo transacional (exceto quando utilizadas as Funções de Requisição de Venda Acumulativa ou de Venda Digitada via NFC), utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe ("finish()").
-
Caso seja retornado o código de resposta "400" indicando erro durante o fluxo transacional quando utilizadas as Funções de Requisição de Venda Acumulativa ou de Venda Digitada via NFC, utilizar o método "cancelTransaction" para o encerramento da operação, possibilitando assim a finalização da classe ("finish()") ou o cancelamento das vendas anteriormente pendentes, de acordo com a regra de negócio proposta pela integração.
-
Caso a Aplicação seja reinicializada quando o fluxo de autenticação se dá por OTP e número de série do terminal, utilizar obrigatoriamente o método "inicializeGsurfOTP" para a verificação do certificado instalado.
-
Caso a Aplicação seja reinicializada quando o fluxo de autenticação se dá por usuário e senha, utilizar obrigatoriamente o método "inicializeGsurf" para a verificação do certificado instalado.
-
Para o modelo de terminal X990 da Verifone, recomenda-se a implementação, junto ao fabricante, da atribuição dos estados de liberado e ocupado no uso dos serviços do VHQ Client durante o fluxo transacional.
-
Para o modelo de terminal DX8000 da Ingenico, é necessário implementar a inicialização da biblioteca e do serviço "DeviceHelper.me()" antes de prosseguir com o fluxo transacional.
-
Para o modelo de terminal GPOS780 da Gertec, é necessário configurar a aplicação para utilizar a arquitetura "armeabi-v7a", conforme detalhado na seção "build.gradle" da Declaração de Dependências da Lib de Integração (SDK) - Dependências Comuns na documentação.
Funções de Requisição:
Observação: As duas funções abaixo devem ser utilizadas sempre que a Aplicação for inicializada quando o fluxo de autenticação for realizado por OTP e número de série do terminal:
Função de Verificação de Certificado por OTP e S/N (Fluxo do POS)
- Inicializar a classe Gsurf
- Instanciar o método inicializeGsurfOTP
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 200 -> Sucesso.
- Em caso de retorno via "200", pular a etapa de Instalação de Certificado.
- 400 -> Erro decorrente de algum problema ao verificar o certificado. Será informado o código de erro retornado pelas funções da Lib GSurf RSA.
- 422 -> Erro de sem certificado instalado, deve-se utilizar o método "activateOTP".
Função de Instalação de Certificado por OTP e S/N (Fluxo do POS)
- Inicializar a classe Gsurf
- Instanciar o método activateOTP contendo os parâmetros abaixo:
- otp - Chave de Ativação
- device - Número de Série do Terminal
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
-
200 -> Sucesso.
-
400 -> Erro de parâmetros incorretos, ou decorrente de algum problema ao instalar o certificado, sendo necessário realizar a finalização da classe ("finish()"). Será informado o código de erro retornado pelas funções da Lib GSurf RSA.
Observação: As duas funções abaixo devem ser utilizadas sempre que a Aplicação for inicializada quando o fluxo de autenticação for realizado por usuário e senha:
Função de Verificação de Certificado por Usuário e Senha (Fluxo do Mobile)
- Inicializar a classe Gsurf
- Instanciar o método inicializeGsurf
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 200 -> Sucesso.
- Em caso de retorno via "200", pular a etapa de Instalação de Certificado.
- 400 -> Erro decorrente de algum problema ao verificar o certificado. Será informado o código de erro retornado pelas funções da Lib GSurf RSA.
- 422 -> Erro de sem certificado instalado, deve-se utilizar o método "checkLogin".
Função de Instalação de Certificado por Usuário e Senha (Fluxo do Mobile)
- Inicializar a classe Gsurf
-
Instanciar o método checkLogin contendo os parâmetros abaixo:
-
username - Nome do Usuário Master
-
password - Senha do Usuário Master
-
key - Chave do Parceiro no SC3 (Partner Key)
-
Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 200 -> Sucesso.
-
400 -> Erro de parâmetros incorretos, ou decorrente de algum problema ao instalar o certificado. Será informado o código de erro retornado pelas funções da Lib GSurf RSA.
- Em caso de retorno via "400 - 406" -> Erro de parâmetros de certificado inválidos. Será necessária a liberação de reinstalação de certificado do usuário/terminal Master em Loja no SC3.
-
406 -> Erro de permissões não liberadas. Será informado qual ou quais os usos do sistema (uses-permission declarados no AndroidManifest) que deverão ser permitidos no dispositivo para possibilitar a utilização da Aplicação de integração.
- 422 -> Erro de parâmetros inválidos.
Observação: Caso a integração seja direcionada ao modelo Smartphone, o PinPad externo deve estar previamente conectado ao dispositivo para a devida utilização das funções abaixo:
Função de Venda
Observação: O método requestSale (Função de Venda) está depreciado. Use o método initTransaction (Função de Venda Acumulativa) em seu lugar.
- Inicializar a classe GsurfSale
- Instanciar o método requestSale contendo os parâmetros abaixo:
- valor - Valor da Venda
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do cartão quando selecionado o tipo de cartão "Digitado" durante a transação, enviá-lo através do referido método.
-
104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
-
"0" -> Sim, para confirmar.
-
"1" -> Não, para não confirmar.
-
105 -> Requer a quantidade de parcelas conforme o número máximo de parcelas configurado em Loja no SC3, enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer um valor pertencente ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do valor da taxa de embarque e da taxa de serviço, enviá-los respectivamente através do referido método.
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
-
201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
-
0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Estorno
- Inicializar a classe GsurfReverse
- Instanciar o método startReverse contendo os parâmetros abaixo:
- name - Nome do Parceiro
- type - Tipo do Estorno: "credit" para Estorno da Venda de Crédito, ou "debit" para Estorno da Venda de Débito
- year - Ano da Venda a ser Estornada
- month - Mês da Venda a ser Estornada (Janeiro: 0, Fevereiro: 1, ..., Dezembro: 11)
- day - Dia da Venda a ser Estornada
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do documento a ser cancelado durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitada a confirmação para o cancelamento ou não da venda a ser estornada, enviar o dado indicado abaixo através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer o valor da venda a ser estornada, enviar o dado através do método "continueTransaction".
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Reimpressão/Reenvio
- Inicializar a classe GsurfReprint
- Instanciar o método requestReprint contendo o parâmetro abaixo:
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do documento a ser reimpresso durante a reimpressão específica, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitada a confirmação para a reimpressão ou não do comprovante da transação, enviar o dado indicado abaixo através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 106 -> Requer a data da transação no formato "DDMMAAAA" ou "DDMM" (o formato pode variar de acordo com a adquirente utilizada), enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer um valor pertencente ao fluxo, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do valor da transação para que seja dado continuidade à reimpressão/reenvio específica do comprovante desta, enviá-lo respectivamente através do referido método.
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo, deve-se utilizar o método "cancelTransaction" para o cancelamento da reimpressão/reenvio do comprovante, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Envio de Log's/Traces
- Inicializar a classe GsurfLog
- Instanciar o método sendLog
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitada a confirmação para o envio ou não dos arquivos de log's/Traces ao Servidor, enviar o dado indicado abaixo através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na operação, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Cadastro de Novo Usuário
- Inicializar a classe Gsurf
- Instanciar o método createNewUser contendo os parâmetros abaixo:
- nick - Nome do Novo Usuário
- key - Chave do Parceiro no SC3 (Partner Key)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 200 -> Retorna uma chave a ser passada como parâmetro "identity" para a ativação/login do novo usuário/terminal.
- 400 -> Erro de parâmetros incorretos, ou decorrente de algum problema de comunicação ao gerar a chave "identity".
- Em caso de retorno via "400 - 401" -> Erro de parâmetro "key" inválido, revisar a atribuição da Chave do Parceiro.
- 422 -> Erro de parâmetro "nick" incorreto, ou de parâmetro "key" em branco, ou ainda erro de permissão de usuário para geração da chave "identity".
Observação: A funcionalidade de criação do novo usuário/terminal é funcional somente para usuários do tipo Master.
Função de Login de Novo Usuário
- Inicializar a classe Gsurf
- Instanciar o método loginNewUser contendo os parâmetros abaixo:
- identity - Chave de Identificação para a Ativação/Login do Novo Usuário/Terminal
- key - Chave do Parceiro no SC3 (Partner Key)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 200 -> Sucesso.
- 400 -> Erro de parâmetros incorretos, ou decorrente de algum problema ao instalar o certificado.
- Em caso de retorno via "400 - 406" -> Erro de parâmetros de certificado inválidos. Será necessária a liberação de reinstalação de certificado do novo usuário/terminal em Loja no SC3.
- 406 -> Erro de permissões não liberadas. Será informado qual ou quais os usos do sistema (uses-permission declarados no AndroidManifest) que deverão ser permitidos no dispositivo para possibilitar a utilização da Aplicação de integração.
- 422 -> Erro de parâmetros inválidos.
Função de Pré-Autorização
- Inicializar a classe GsurfPreAuthorization
- Instanciar o método startPreAuthorization contendo o parâmetro abaixo:
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do cartão quando selecionado o tipo de cartão "Digitado" durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 105 -> Requer a quantidade de parcelas conforme o número máximo de parcelas configurado em Loja no SC3, enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer o valor da transação, enviar o dado através do método "continueTransaction".
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
-
22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
-
205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Cancelamento de Pré-Autorização
- Inicializar a classe GsurfPreAuthorizationCancel
- Instanciar o método cancelPreAuthorization contendo o parâmetro abaixo:
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do documento a ser cancelado durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 106 -> Requer a data da transação no formato "DDMMAAAA" ou "DDMM" (o formato pode variar de acordo com a adquirente utilizada), enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer o valor da transação a ser cancelada, enviar o dado através do método "continueTransaction".
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Captura de Pré-Autorização
- Inicializar a classe GsurfCaptured
- Instanciar o método preAuthorizationCaptured contendo os parâmetros abaixo:
- valor - Valor da Transação
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do cartão quando selecionado o tipo de cartão "Digitado" durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 105 -> Requer a quantidade de parcelas conforme o número máximo de parcelas configurado em Loja no SC3, enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer um valor pertencente ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do valor da taxa de embarque e da taxa de serviço, enviá-los respectivamente através do referido método.
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Cancelamento de Captura de Pré-Autorização
- Inicializar a classe GsurfCapturedCancel
- Instanciar o método cancelCaptured contendo o parâmetro abaixo:
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do documento a ser cancelado durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 106 -> Requer a data da transação no formato "DDMMAAAA" ou "DDMM" (o formato pode variar de acordo com a adquirente utilizada), enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer o valor da transação a ser cancelada, enviar o dado através do método "continueTransaction".
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Carteira Digital/QR Code
- Inicializar a classe GsurfQrCode
- Instanciar o método createQrCode contendo os parâmetros abaixo:
- valor - Valor da Transação
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 103 -> Retorna uma String da CliSiTef que pode ser utilizada para a geração do QR Code. Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado indicado abaixo através do método "continueTransaction" para prosseguir com a operação ou utilizar o método "cancelTransaction" para cancelar a operação, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- cancelTransaction -> Não, para não confirmar.
- 105 -> Requer a quantidade de parcelas conforme o número máximo de parcelas configurado em Loja no SC3, enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Cancelamento de Carteira Digital/QR Code
- Inicializar a classe GsurfQrCodeCancel
- Instanciar o método qrCodeCancel contendo o parâmetro abaixo:
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 -> Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 -> Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do documento a ser cancelado durante a transação, enviá-lo através do referido método.
- 103 -> Retorna uma String da CliSiTef que pode ser utilizada para a geração do QR Code. Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado indicado abaixo através do método "continueTransaction" para prosseguir com a operação ou utilizar o método "cancelTransaction" para cancelar a operação, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- cancelTransaction -> Não, para não confirmar.
- 106 -> Requer a data da transação no formato "DDMMAAAA" ou "DDMM" (o formato pode variar de acordo com a adquirente utilizada), enviar o dado através do método "continueTransaction".
- 107 -> Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 -> Requer o valor da transação a ser cancelada, enviar o dado através do método "continueTransaction".
- 110 -> Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da transação, e na sequência realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Verificação de Transações Pendentes
Observação: Recomenda-se que a verificação de pendência das transações seja utilizada no contexto de inicialização da Aplicação de integração.
- Inicializar a classe GsurfVerifyTransaction
- Instanciar o método verifyTransaction contendo o parâmetro abaixo:
- name - Nome do Parceiro
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na operação, reinicializar o contexto/sessão da classe.
- 201 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 202 -> Retorno com a mensagem de que não existe transação pendente.
- 203 -> Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação ainda pendente conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- Requer também a confirmação para aprovar ou não a transação pendente existente, utilizar um dos métodos abaixo, de acordo com a respectiva finalidade:
- "aprovarTransacao" -> Sim, para aprovar.
- "cancelarTransacao" -> Não, para não aprovar.
- 400 -> Erro durante o fluxo transacional, deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Observação: Para utilizar as duas funções abaixo, a Aplicação de integração deverá dispor do parâmetro de configuração no formato JSON, que pode ser ajustado com base nos detalhes representados através da seguinte documentação: Parâmetro de Configuração JSON
Função de Venda Acumulativa
- Inicializar a classe GsurfSale
- Instanciar o método initTransaction contendo os parâmetros abaixo:
- valor - Valor da Venda
- json - JSON do Parâmetro de Configuração (necessário incluir o campo “name” referente ao Nome do Parceiro)
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 → Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 → Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do cartão quando selecionado o tipo de cartão "Digitado" durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 105 → Requer a quantidade de parcelas conforme o número máximo de parcelas configurado em Loja no SC3, enviar o dado através do método "continueTransaction".
- 107 → Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 → Requer um valor pertencente ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do valor da taxa de embarque e da taxa de serviço, enviá-los respectivamente através do referido método.
- 110 → Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 111 → Requer a finalização da venda pendente ou o início de uma nova venda, enviar o dado através do método "finishTransaction" ou instanciar o método “initTransaction” com os devidos parâmetros, de acordo com a respectiva finalidade:
- "0" -> Cancelar a venda.
- "1" -> Aprovar a venda.
- Iniciar uma nova venda -> Instanciar o método "initTransaction" contendo o valor da venda e o JSON de configuração.
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Observação: Devido a uma limitação do fluxo, apenas o cupom eletrônico referente à última venda efetuada pode ser enviado. Cupons eletrônicos de vendas anteriores no mesmo fluxo não podem ser enviados.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- 201 → Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 204 → Sucesso no cancelamento das vendas pendentes.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 → Erro durante o fluxo transacional, deve-se utilizar o método "finishTransaction(0)" para o cancelamento das vendas pendentes, ou realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Venda Digitada via NFC
- Inicializar a classe GsurfSale
- Instanciar o método initTransaction contendo os parâmetros abaixo:
- valor - Valor da Venda
- json - JSON do Parâmetro de Configuração (necessário incluir o campo “name” referente ao Nome do Parceiro, e o campo “coletaNfc” = “1” no formato String)
- pinPadMac (Opcional) - Endereço MAC do PinPad Bluetooth no Formato "00:00:00:00:00:00" (Somente Smartphone)
- Implementar a função de callback do método "onResume()" da classe Activity, instanciando a função "resumeNfc()"
- Implementar a função de callback do método "onPause()" da classe Activity, instanciando a função "pauseNfc()"
- Implementar a função de callback do método "onNewIntent()" da classe Activity, instanciando a função "initNfcEvent()" e passando como parâmetro desta o objeto “intent”
- Respostas - LiveData(Código, Texto)
Validação via código de resposta:
- 100 -> Mensagem.
- 101 → Requer o endereço de e-mail, enviar o dado através do método "continueTransaction".
- 102 → Requer algum dado que a CliSiTef necessita para que seja dado continuidade ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do número do cartão quando selecionado o tipo de cartão "Digitado" durante a transação, enviá-lo através do referido método.
- 104 -> Requer a confirmação para que seja dado continuidade ou não ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja utilizado o método "cancelTransaction" durante a leitura do cartão, será solicitada a confirmação para cancelar ou não a operação em andamento, onde o dado indicado abaixo deve ser enviado através do referido método, de acordo com a respectiva finalidade:
- "0" -> Sim, para confirmar.
- "1" -> Não, para não confirmar.
- 105 → Requer a quantidade de parcelas conforme o número máximo de parcelas configurado em Loja no SC3, enviar o dado através do método "continueTransaction".
- 107 → Requer uma das opções informadas, enviar o dado através do método "continueTransaction".
- 109 → Requer um valor pertencente ao fluxo transacional, enviar o dado através do método "continueTransaction". Por exemplo: Caso seja solicitado o fornecimento do valor da taxa de embarque e da taxa de serviço, enviá-los respectivamente através do referido método.
- 110 → Requer o número de telefone, enviar o dado através do método "continueTransaction".
- 111 → Requer a finalização da venda pendente ou o início de uma nova venda, enviar o dado através do método "finishTransaction" ou instanciar o método “initTransaction” com os devidos parâmetros, de acordo com a respectiva finalidade:
- "0" -> Cancelar a venda.
- "1" -> Aprovar a venda.
- Iniciar uma nova venda -> Instanciar o método “initTransaction” contendo o valor da venda e o JSON de configuração.
- 112 -> Mensagem de erro. Requer a confirmação para que seja dado continuidade ao fluxo transacional, utilizar o método "continueOperation".
- 200 -> Sucesso na transação.
- Abrir as opções de envio do comprovante eletrônico caso este seja enviado via:
- e-mail -> Enviar o dado através do método "transactionSendEmail".
- SMS -> Enviar o dado através do método "transactionSendSms".
- Reinicializar o contexto/sessão da classe caso o comprovante eletrônico não seja enviado.
- Observação: Devido a uma limitação do fluxo, apenas o cupom eletrônico referente à última venda efetuada pode ser enviado. Cupons eletrônicos de vendas anteriores no mesmo fluxo não podem ser enviados.
- 201 → Retorno com os dados transacionais em um arrayList, contendo respectivamente os objetos com as informações da transação conforme descritos abaixo:
- 0 -> "merchant.name" - Nome da Loja no SC3.
- 1 -> "merchant.cnpj" - CPF/CNPJ da Loja no SC3.
- 2 -> "merchantVoucher" - Via do Estabelecimento.
- 3 -> "customerVoucher" - Via do Cliente.
- 4 -> "docNumber" - NSU do Host Autorizador.
- 5 -> "docNumberSitef" - NSU do SiTef.
- 6 -> "docNumberFepas" - NSU do FEPAS.
- 7 -> "value" - Valor da Transação.
- 8 -> "date" - Data e Hora da Transação.
- 9 -> "entity" - Nome da Instituição.
- 10 -> "cardNumber" - Bin do Cartão.
- 11 -> "authority" - Código de Autorização.
- 12 -> "cardType" - Modalidade de Pagamento “xxnn” (Grupo), “xx” que corresponde ao Grupo.
- 13 -> "paymentType" - Modalidade de Pagamento “xxnn” (Sub-Grupo), “nn” que corresponde ao Sub-Grupo.
- 14 -> "installments" - Número de Parcelas.
- 15 -> "modality" - Descrição da Modalidade de Pagamento.
- 16 -> "transactionType" - Tipo da Transação.
- 17 -> "confirmationData" - Dados de Confirmação da Transação.
- 18 -> "transactionState" - Estado/Status da Transação.
- 19 -> "cardDue" - Vencimento do Cartão.
- 20 -> "cardPAN" - PAN do Cartão.
- 21 -> "cardOwnerName" - Nome do Portador do Cartão.
- 22 -> "cardOwner" - Embosso (4 últimos dígitos) do Cartão.
- 204 → Sucesso no cancelamento das vendas pendentes.
- 205 -> Sucesso no envio do comprovante eletrônico, reinicializar o contexto/sessão da classe.
- 400 → Erro durante o fluxo transacional, deve-se utilizar o método "finishTransaction(0)" para o cancelamento das vendas pendentes, ou realizar a finalização da classe.
- 401 -> Erro de envio do comprovante eletrônico quando desabilitado em Loja no SC3, deve-se realizar a finalização da classe.
- 402 -> Erro de "Erro Config Email/SMS" no envio do comprovante eletrônico referente à via do cliente, deve-se realizar a finalização da classe.
- 403 -> Erro genérico de "Erros detectados internamente", deve-se utilizar o método "cancelTransaction" para o cancelamento da operação, e na sequência realizar a finalização da classe. A mensagem de erro pode ser exibida ou oculta, conforme desejado.
Função de Coleta de Dados do Terminal em Loja
- Inicializar a classe GsurfSC3Data
- Coletar os dados desejados, conforme descritos abaixo:
- name - Nome da Loja
- email - E-mail
- phone - Telefone
- merchantCode - Código de Loja
- maxInstallments - Número Máximo de Parcelas
- cnpj - CPF/CNPJ
- city - Cidade
- state - Estado
- address - Endereço
- partnerId - ID do Parceiro
- gsurfId - ID do Terminal no Sistema SC3 GSurf
- terminalCode - Código do Terminal
- serialNumber - Número de Série
- creditReverseLimit - Dias para Cancelamento de Crédito
- sendVoucherType - Configuração de Comprovante Eletrônico
Mais detalhes sobre os dados, a seguir na tabela abaixo:

Função de Coleta de Versões
- Inicializar a classe GsurfSDKData
- Coletar os dados desejados, conforme descritos abaixo:
- sdkVersion - Versão da Lib SDK Transaction (String)
- cliSiTefVersion - Versão da Lib CliSiTef (String)
Dados de Resposta da Transação:
Ao finalizar a transação, são retornados os dados transacionais em um arrayList através do código de resposta "201", contendo respectivamente os objetos com as informações da mesma conforme descritos na tabela abaixo:

Tradução de Mensagens da CliSiTef:
É possível alterar parte das mensagens enviadas para a integração, para efeitos de tradução ou, em alguns casos, para redução das mesmas.
Para habilitar esta característica, basta incluir no diretório "assets" de qualquer módulo do Projeto da integração, um arquivo de texto com a extensão .txt denominado "clisitef_traducao.txt" contendo as mensagens a serem alteradas, as quais devem ser mantidas separadas por linha, sob a seção "TabTraducao", seguindo o padrão no formato de arquivo INI.
Um exemplo de conteúdo presente neste arquivo "clisitef_traducao.txt" seria:
[TabTraducao]
MsgNovoValor=Forneca o novo valor do pagamento
MsgEmbosso=Forneca os 4 digitos finais do cartao
MsgCodigoSeguranca=Informe Cod. Seg, ou\n0 = inexistente\n1 = ilegivel
Observação: Como a CliSiTef está em constante inclusão de módulos e mensagens, a lista completa de itens de tradução encontra-se no documento "SiTef - Interface Simplificada com a aplicação - Tabela de Mensagens".
Modelos de Terminais Compatíveis com as Versões da Lib de Integração (SDK):
Modelo de Terminal: | Versão da Lib de Integração (SDK):
---------|----------|
Gertec GPOS700 | gsurf_3.6.0
Gertec GPOS700MINI | gsurf_3.6.0
Gertec GPOS700X | gsurf_3.6.0
Gertec GPOS720 | gsurf_3.6.0
Gertec GPOS760 | gsurf_3.6.0
Gertec GPOS780 | gsurf_3.6.0
Ingenico A8 | gsurf_3.6.0
Ingenico DX8000 | gsurf_3.6.0
Smartphone | gsurf_3.6.0
Pax A910 | gsurf_3.6.0
Pax A920 | gsurf_3.6.0
Newland N910 | gsurf_3.6.0
Verifone X990 | gsurf_3.6.0
Versões de Compilação da Lib SDK Transaction:
Descrição: | Versão:
---------|----------|
minSdkVersion | 21
targetSdkVersion | 35
compileSdkVersion | 35
buildToolsVersion | 30.0.3
Plugin do Gradle | 7.2.2
Plugin do Kotlin | 1.8.0
Declaração de Dependências da Lib de Integração (SDK):
Dependências Comuns:
AndroidManifest.xml
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.BLUETOOTH"/>
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="32"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" android:maxSdkVersion="32"/>
<application android:requestLegacyExternalStorage="true"/>
Observação: Para o uso da Função de Requisição de Venda Digitada via NFC, declarar as permissões abaixo:
<uses-permission android:name="android.permission.NFC" />
<uses-feature android:name="android.hardware.nfc" android:required="true" />
Observação: Para o funcionamento do PinPad conectado via bluetooth em dispositivos que possuem a versão do Android 12 ou superior, declarar as permissões abaixo:
<uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
Observação: Recomenda-se o aceite das permissões abaixo pelo usuário ao abrir a aplicação de integração pela primeira vez, antes mesmo de prosseguir com a ativação do terminal:
"android.permission.READ_PHONE_STATE"
"android.permission.WRITE_EXTERNAL_STORAGE"
Para dispositivos que possuem a versão do Android 12 ou 12.1:
"android.permission.READ_PHONE_STATE"
"android.permission.WRITE_EXTERNAL_STORAGE"
"android.permission.BLUETOOTH_SCAN"
"android.permission.BLUETOOTH_CONNECT"
Para dispositivos que possuem a versão do Android 13 ou superior:
"android.permission.READ_PHONE_STATE"
"android.permission.BLUETOOTH_SCAN"
"android.permission.BLUETOOTH_CONNECT"
build.gradle
Observação: Para o desenvolvimento da integração utilizando a IDE Android Studio, desativar o strip declarando a opção de empacotamento abaixo:
android {
packagingOptions {
doNotStrip "**/libclisitef.so"
}
}
Observação: Para o modelo de terminal GPOS780 da Gertec, é necessário declarar o filtro da arquitetura "armeabi-v7a" na aplicação, garantindo que o sistema utilize a arquitetura correspondente, conforme abaixo:
android {
defaultConfig {
ndk.abiFilters("armeabi-v7a")
}
Observação: Para o uso da Função de Requisição de Venda Digitada via NFC, declarar as dependências abaixo:
dependencies {
implementation "commons-io:commons-io:2.17.0"
implementation "org.apache.commons:commons-collections4:4.5.0"
implementation "org.apache.commons:commons-lang3:3.18.0"
}
gradle.properties
android.useAndroidX=true
android.enableJetifier=true
GSurf Release (Homologação)
- implementation files('libs/gsurf_3.6.0_homolog_release.aar')
GSurf Release (Produção)
- implementation files('libs/gsurf_3.6.0_prod_release.aar')
Dependências Específicas:
GPOS700 (Homologação)
- implementation files('libs/libgsurfsc3-gpos700_simulado-1.4.2.aar')
- implementation files('libs/libppcomp-001.35.230609-gpos700-release.aar')
- implementation files('libs/libgedi-1.16.14.1-gpos700-payment-release.aar')
GPOS700 (Produção)
- implementation files('libs/libgsurfsc3-gpos700_producao-1.4.2.aar')
- implementation files('libs/libppcomp-001.35.230609-gpos700-release.aar')
- implementation files('libs/libgedi-1.16.14.1-gpos700-payment-release.aar')
GPOS700MINI (Homologação)
- implementation files('libs/libgsurfsc3-gpos700mini_simulado-1.4.2.aar')
- implementation files('libs/libppcomp-001.44.231109-gpos700-release.aar')
- implementation files('libs/libgedi-1.16.22-gpos700-payment-release.aar')
GPOS700MINI (Produção)
- implementation files('libs/libgsurfsc3-gpos700mini_producao-1.4.2.aar')
- implementation files('libs/libppcomp-001.44.231109-gpos700-release.aar')
- implementation files('libs/libgedi-1.16.22-gpos700-payment-release.aar')
GPOS700X (Homologação)
- implementation files('libs/libgsurfsc3-gpos700_simulado-1.4.2.aar')
- implementation files('libs/libppcomp-001.35.230609-gpos700-release.aar')
- implementation files('libs/libgedi-1.16.15.2-gpos700-payment-release.aar')
GPOS700X (Produção)
- implementation files('libs/libgsurfsc3-gpos700_producao-1.4.2.aar')
- implementation files('libs/libppcomp-001.35.230609-gpos700-release.aar')
- implementation files('libs/libgedi-1.16.15.2-gpos700-payment-release.aar')
GPOS720 (Homologação)
- implementation files('libs/libgsurfsc3-gpos720_simulado-1.4.2.aar')
- implementation files('libs/libppcomp-1.37.231212-gpos720-release.aar')
- implementation files('libs/libgedi-0.16.20-gpos720-payment-release.aar')
GPOS720 (Produção)
- implementation files('libs/libgsurfsc3-gpos720_producao-1.4.2.aar')
- implementation files('libs/libppcomp-1.37.231212-gpos720-release.aar')
- implementation files('libs/libgedi-0.16.20-gpos720-payment-release.aar')
GPOS760 (Homologação)
- implementation files('libs/libgsurfsc3-gpos760_simulado-1.4.2.aar')
- implementation files('libs/libppcomp-1.14-gpos760-release.aar')
- implementation files('libs/libgedi-0.18.15.d645371-gpos760-payment-release.aar')
GPOS760 (Produção)
- implementation files('libs/libgsurfsc3-gpos760_producao-1.4.2.aar')
- implementation files('libs/libppcomp-1.14-gpos760-release.aar')
- implementation files('libs/libgedi-0.18.15.d645371-gpos760-payment-release.aar')
GPOS780 (Homologação)
- implementation files('libs/libgsurfsc3-gpos780_simulado-1.4.2.aar')
- implementation files('libs/libppcomp-001.32.240506-gpos780-release.aar')
- implementation files('libs/libgedi-1.16.21-gpos700-payment-release.aar')
- implementation files('libs/libhcl-1.0.8-gpos780-release.aar')
GPOS780 (Produção)
- implementation files('libs/libgsurfsc3-gpos780_producao-1.4.2.aar')
- implementation files('libs/libppcomp-001.32.240506-gpos780-release.aar')
- implementation files('libs/libgedi-1.16.21-gpos700-payment-release.aar')
- implementation files('libs/libhcl-1.0.8-gpos780-release.aar')
A8 (Homologação)
- implementation files('libs/libgsurfsc3-a8_simulado-1.4.2.aar')
- implementation files('libs/bcapos-a8-5.16.aar')
- implementation files('libs/dm-apos-1.7.1-a8.aar')
- implementation files('libs/usdk_api_aidl_v13.4.10.20211222.jar')
- implementation "org.slf4j:slf4j-api:1.7.32"
A8 (Produção)
- implementation files('libs/libgsurfsc3-a8_producao-1.4.2.aar')
- implementation files('libs/bcapos-a8-5.16.aar')
- implementation files('libs/dm-apos-1.7.1-a8.aar')
- implementation files('libs/usdk_api_aidl_v13.4.10.20211222.jar')
- implementation "org.slf4j:slf4j-api:1.7.32"
DX8000 (Homologação)
- implementation files('libs/libgsurfsc3-dx8000_simulado-1.4.2.aar')
- implementation files('libs/bcapos-dx-6.18-release.aar')
- implementation files('libs/dm-apos-2.1.0-dx-release.aar')
- implementation files('libs/usdk_api_aidl_v13.5.12TB.20220520.jar')
- implementation "org.slf4j:slf4j-api:1.7.32"
DX8000 (Produção)
- implementation files('libs/libgsurfsc3-dx8000_producao-1.4.2.aar')
- implementation files('libs/bcapos-dx-6.18-release.aar')
- implementation files('libs/dm-apos-2.1.0-dx-release.aar')
- implementation files('libs/usdk_api_aidl_v13.5.12TB.20220520.jar')
- implementation "org.slf4j:slf4j-api:1.7.32"
X990 (Homologação)
- implementation files('libs/libgsurfsc3-x990_simulado-1.4.2.aar')
- implementation files('libs/PPCompX990-v002.25.1.aar')
X990 (Produção)
- implementation files('libs/libgsurfsc3-x990_producao-1.4.2.aar')
- implementation files('libs/PPCompX990-v002.25.1.aar')
Smartphone (Homologação)
- implementation files('libs/libgsurfsc3-smartphone_simulado-1.4.2.aar')
Smartphone (Produção)
- implementation files('libs/libgsurfsc3-smartphone_producao-1.4.2.aar')
A910 ou A920 (Homologação)
- implementation files('libs/libgsurfsc3-a910_a920_simulado-1.4.2.aar')
- implementation files('libs/PPCompAndroid-v1.63.aar')
- implementation files('libs/DEVICE_v101.jar')
- implementation files('libs/NeptuneLiteApi_V4.04.00_20231229.jar')
A910 ou A920 (Produção)
- implementation files('libs/libgsurfsc3-a910_a920_producao-1.4.2.aar')
- implementation files('libs/PPCompAndroid-v1.63.aar')
- implementation files('libs/DEVICE_v101.jar')
- implementation files('libs/NeptuneLiteApi_V4.04.00_20231229.jar')
N910 (Homologação)
- implementation files('libs/libgsurfsc3-n910_simulado-1.4.2.aar')
- implementation files('libs/bcnewland-release-244.aar')
N910 (Produção)
- implementation files('libs/libgsurfsc3-n910_producao-1.4.2.aar')
- implementation files('libs/bcnewland-release-244.aar')
Detalhes de Compatibilidade dos Modelos de Terminais:
Gertec GPOS700:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.93.r4 |
| SDK (Imagem) | 181.28 ou 302.9F |
| Firmware (Build Number) | WPOS-3_V1-01_211124174103 (21112417) ou WPOS3_V1-01_230831164151 (230831164151) |
| Lib PPCOMP | 001.35.230609 |
| Lib Payment (GEDI) | 1.16.14.1 |
| Android | 5.1.1 |
| API (minSdkVersion) | 22 |
Gertec GPOS700MINI:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.93.r4 |
| SDK (Imagem) | 316 |
| Firmware (Build Number) | WPOS-GPOS700-MINI_Android8_P0_V01.00_2309221001 |
| Lib PPCOMP | 001.44.231109 |
| Lib Payment (GEDI) | 1.16.22 |
| Android | 8.1.0 |
| API (minSdkVersion) | 22 |
Gertec GPOS700X:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.93.r4 |
| SDK (Imagem) | 202 ou 220.33I |
| Firmware (Build Number) | WPOS3X_Android8_P0_V01.00_2112092149 (2112092149) ou WPOS3X_Android8_P0_V01.00_2308031105 (2308031105) |
| Lib PPCOMP | 001.35.230609 |
| Lib Payment (GEDI) | 1.16.15.2 |
| Android | 8.1.0 |
| API (minSdkVersion) | 22 |
Gertec GPOS720:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.77.r2 |
| SDK (Imagem) | 156.5 |
| Firmware (Build Number) | F20_OS_1.01.06.00_000_202312041438_GERTEC_156.5 (202312041438) |
| Lib PPCOMP | PPCOMP_1.37.231212 |
| Lib Payment (GEDI) | 0.16.20 |
| Android | 10 |
| API (minSdkVersion) | 22 |
Gertec GPOS760:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.93.r6 |
| SDK (Imagem) | 3.7.3 |
| Firmware (Build Number) | Z3909AB_GERTEC_GPOS760_3.7.3 |
| Lib PPCOMP | 1.14 |
| Lib Payment (GEDI) | 0.18.15 |
| Android | 11 |
| API (minSdkVersion) | 26 |
Gertec GPOS780:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.93.r4 |
| SDK (Imagem) | 935 |
| Firmware (Build Number) | GPOS780_Android11_V01.00_2404301413 (2404301413) |
| Lib PPCOMP | 001.32.240506 |
| Lib Payment (GEDI) | 1.16.21 |
| Lib HCL | 1.0.8 |
| Android | 11 |
| API (minSdkVersion) | 22 |
Ingenico A8:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.60.rc3 (Simulado) e 7.0.117.63.rc2 (Produção) |
| USDK (OTA) | 4.6.66-001 ~ 6.16.101 e 12.2.0 ~ 12.6.0 |
| Lib (bcapos) | 5.16 |
| Lib (dm-apos) | 1.7.1 |
| Lib (usdk_api_aidl) | 13.4.10.20211222 |
| API (org.slf4j:slf4j-api) | 1.7.32 |
| Android | 5.1.1 |
| API (minSdkVersion) | 22 |
Ingenico DX8000:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.88.r1 |
| USDK (OTA) | 1.17.0 |
| Lib (bcapos) | 6.18 |
| Lib (dm-apos) | 2.1.0 |
| Lib (usdk_api_aidl) | 13.5.12TB.20220520 |
| API (org.slf4j:slf4j-api) | 1.7.32 |
| Kernel NGA EP2CLESS | 5.0.0 |
| Kernel NGA EP2EMV | 3.0.0 |
| Android | 10 |
| API (minSdkVersion) | 22 |
Smartphone:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.82.r2 |
| Android | 5.0 ~ 15 |
| API (minSdkVersion ~ maxSdkVersion) | 21 ~ 35 |
Pax A910:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.88.r1 |
| Firmware (OTA) | A910_PayDroid_6.0_Leo_V07.3.12_Brazil_20240314 |
| Lib PPCOMP | 1.63 |
| Lib DEVICE | 101 |
| Lib API | 4.04.00_20231229 |
| Android | 6.0 |
| API (minSdkVersion) | 22 |
Pax A920:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.88.r1 |
| Firmware | PayDroid_5.1.1_Aquarius_V02.3.46_20240410 |
| Lib PPCOMP | 1.63 |
| Lib DEVICE | 101 |
| Lib API | 4.04.00_20231229 |
| Android | 5.1.1 |
| API (minSdkVersion) | 22 |
Newland N910:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.65.r1 |
| Firmware | D2.3.48 (NewLand_N910-bda3a03750) |
| Lib (bcnewland) | 244 |
| Android | 5.1.1 |
| API (minSdkVersion) | 22 |
Verifone X990:
| Descrição: | Versão: |
|---|---|
| CliSiTef | 7.0.117.91.r5 |
| Firmware (ROM) | 3A.1.915 (202401161438 BRA) |
| Security Driver | X990-V1.0.34 (202312070931) |
| VF Service | 3.12.1.3 (240307 135659 BR) |
| VF System Service | 1.12.4.1 (1000500 231115) |
| VHQ Service (TMS Agent) | 4.104.3 (20240307) |
| Lib PPComp | 002.25.1 |
| Android | 10 |
| API (minSdkVersion) | 22 |
Verificação da Versão de Firmware do Modelo de Terminal:
- Para o modelo Smartphone:
- Ir em: Configurações → Sistema → Sobre o dispositivo → Número da versão.
Observação: O caminho pode ser diferente em outras versões do Android.
- Para os demais modelos:
- Ir em: Configurações → Sobre o telefone/dispositivo → Número da versão/compilação ou Informação de configuração.
Histórico de Revisões:
| Modificações: | Gerente autorizador: | Data e Versão: |
|---|---|---|
| Publicação inicial | Rafael Frasson | 01/10/2020 - v1 |
| Inclusão da tabela com os Dados de Resposta da Transação | Rafael Frasson | 08/06/2021 - v2 |
| Inclusão do novo objeto “cardOwner” na tabela com os Dados de Resposta da Transação | Rafael Frasson | 15/06/2021 - v3 |
| Inclusão do novo código de resposta “401” | Rafael Frasson | 13/08/2021 - v3.1 |
| Inclusão do código de resposta “104” faltante em algumas das Funções de Requisição | Rafael Frasson | 03/08/2021 - v4 |
| Reestruturação e atualização de toda a documentação | Rafael Frasson | 10/09/2021 - v5 |
| Inclusão do novo fluxo e funções de requisição relacionadas à autenti- cação por OTP e S/N, ajuste para possibilitar a finalização da classe através do código de resposta “400” nas funções de requisição de transações, reimpressão/reenvio e envio de log’s/traces, inclusão de nova permissão no AndroidManifest, inclusão do código de resposta “406” na função de login do novo usuário/terminal, e atualização de versões de compatibi- lidade do modelo Smartphone | Rafael Frasson | 05/10/2021 - v6 |
| Inclusão da nova Função de Requisição “Função de Coleta de Dados do Terminal em Loja” | Rafael Frasson | 14/10/2021 - v7 |
| Atualização das Dependências Específicas do modelo de terminal A8 da Ingenico, inclusão da tabela com as Versões de Compilação da Lib gsurf.aar, e ajuste do Tipo/Regra de Formatação do objeto “date” na tabela com os Dados de Resposta da Transação | Rafael Frasson | 25/10/2021 - v8 |
| Inclusão de nova configuração para possibilitar a Tradução de Mensagens da CliSiTef via carregamento de arquivo, e atualização de versões de compatibilidade dos modelos GPOS700, A910 e A920 | Rafael Frasson | 16/11/2021 - v9 |
| Inclusão das novas funções de requisição "Venda Acumulativa" e "Venda Digitada via NFC", porte do novo modelo DX8000 da Ingenico, atualização das Dependências Comuns contendo novas permissões no AndroidManifest e declarações de dependências no build.gradle para atender às duas novas funções de requisição, e atualização das Dependências Específicas dos modelos de terminal GPOS700, A8 e N910 | Rafael Frasson | 01/02/2022 - v10 |
| Atualização de versões de compatibilidade dos modelos GPOS700 e A8 | Rafael Frasson | 12/04/2022 - v11 |
| Ajuste na formatação da data da transação a ser enviada ("DDMMAAAA" ou "DDMM") através do código de resposta "106" das transações relacionadas às funções de requisição de Reimpressão/Reenvio, Cancelamento de Pré-Autorização, Cancelamento de Captura de Pré-Autorização e Cancelamento de Carteira Digital/QR Code, porte dos novos modelos GPOS700MINI e GPOS700X da Gertec, e atualização das Dependências Específicas dos modelos de terminal GPOS700, Smartphone e N910 | Rafael Frasson | 26/04/2022 - v12 |
| Atualização das Dependências Específicas do modelo de terminal A8 da Ingenico | Rafael Frasson | 19/05/2022 - v13 |
| Porte dos novos modelos L200 e L300 da Positivo, e atualização das Dependências Específicas dos modelos de terminal A910, A920 e N910 | Rafael Frasson | 06/12/2022 -v14 |
| Atualização das Dependências Comuns contendo novas permissões necessárias no AndroidManifest a partir da API 31 do Android, atualização das Dependências Específicas dos modelos de terminal A8, DX8000, Smartphone e N910, e atualização de versões de compatibilidade do modelo Smartphone. | Rafael Frasson | 15/02/2023 - v15 |
| Atualização das Dependências Específicas dos modelos de terminal L200 e L300 da Positivo | Rafael Frasson | 23/03/2023 - v16 |
| Atualização das Dependências Comuns contendo novas permissões necessárias no AndroidManifest a partir da API 33 do Android, atualização das Dependências Específicas do modelo de terminal N910 e Smartphone, atualização de versões de compatibilidade do modelo Smartphone, alteração no cancelamento da operação através do código de resposta "103", ajuste na validação do retorno através dos códigos de resposta "100" e "200" das transações elacionadas às funções de requisição de Venda, Estorno, Reimpressão/Reenvio, Pré-Autorização, Cancelamento de Pré-Autorização, Captura de Pré-Autorização, Cancelamento de Captura de Pré-Autorização, Carteira Digital/QR Code, Cancelamento de Carteira Digital/QR Code, Venda Acumulativa e Venda Digitada via NFC, e inclusão dos novos códigos de resposta "112" e "205". | Anderson Hoffmann | 11/09/2023 - v17 |
| Alterado o conteúdo presente na seção de Fluxo de Autenticação do Android POS e Informações Gerais. Adicionado o parâmetro opcional de Endereço MAC do PinPad Bluetooth nas funções de requisição de Venda, Estorno, Reimpressão/Reenvio, Pré-Autorização, Cancelamento de Pré-Autorização, Captura de Pré-Autorização, Cancelamento de Captura de Pré-Autorização, Carteira Digital/QR Code, Cancelamento de Carteira Digital/QR Code, Verificação de Transações Pendentes, Venda Acumulativa e Venda Digitada via NFC. | Anderson Hoffmann | 28/09/2023 - v18 |
| Ajuste nas Dependências Comuns do build.gradle e inclusão do gradle.properties. | Anderson Hoffmann | 04/10/2023 - v19 |
| Inclusão do novo código de resposta "402" e do novo modelo GPOS720 da Gertec, atualização das Dependências Específicas do modelo de terminal Smartphone, e atualização dos Detalhes de Compatibilidade dos modelos de terminal GPOS700, GPOS700MINI, GPOS700X, A8 e Smartphone. | Anderson Hoffmann | 15/04/2024 - v20 |
| Alteração de conteúdo na seção de Fluxo de Autenticação do Android POS, Informações Gerais e Verificação da Versão de Firmware do Modelo de Terminal. Adição de observações de depreciação na Função de Requisição de venda e de envio do comprovante eletrônico nas Funções de Requisição de Venda Acumulativa e Venda Digitada via NFC. Inclusão da nova Função de Requisição "Função de Coleta de Versões". Atualização de conteúdo na seção de Versões de Compilação da Lib SDK Transaction, Dependências Comuns, Dependências Específicas e Detalhes de Compatibilidade dos Modelos de Terminais. Porte do novo modelo X990 da Verifone. Inclusão do novo item CupomFiscal" na documentação do Parâmetro de Configuração JSON. | Anderson Hoffmann | 10/10/2024 - v21 |
| Alteração de conteúdo na seção de Fluxo de Autenticação do Android POS. Atualização de conteúdo na seção de Dependências Comuns, Dependências Específicas e Detalhes de Compatibilidade dos Modelos de Terminais. Porte do novo modelo GPOS760 da Gertec. | Anderson Hoffmann | 25/11/2024 - v22 |
| Alteração de conteúdo na seção de Fluxo de Autenticação do Android POS e Informações Gerais. Atualização de conteúdo na seção de Dependências Comuns, Dependências Específicas e Detalhes de Compatibilidade dos Modelos de Terminais. Retomada do porte do modelo DX8000 da Ingenico. | Anderson Hoffmann | 09/12/2024 - v23 |
| Alteração de conteúdo na seção de Fluxo de Autenticação do Android POS, Informações Gerais e Função de Login de Novo Usuário. Atualização de conteúdo na seção de Versões de Compilação da Lib SDK Transaction, Dependências Comuns, Dependências Específicas, Detalhes de Compatibilidade dos Modelos de Terminais, e Parâmetros do Efetua na documentação do Parâmetro de Configuração JSON. Porte do novo modelo GPOS780 da Gertec. Inclusão do novo código de resposta "403". | Claudio Costa | 23/10/2025 - v24 |
