Getnet DocsGetnet Docs

Segurança e Licenciamento

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

A leitura do cartão e a digitação do PIN acontecem no PIN pad certificado, não no seu aplicativo. Esta página cobre o que é responsabilidade do seu app: vincular o terminal pelo modelo de licenciamento, escolher o ambiente de execução, capturar a assinatura quando o cartão exige e tratar logs e credenciais com cuidado.

Vinculação de Terminal e Licenciamento

Um recurso de segurança exclusivo do Get Mini SDK é a Vinculação de Bundle ID, que impede que aplicativos não autorizados processem transações usando as credenciais do seu estabelecimento.

Processo de Registro de Licença

Para usar o SDK, você deve registrar o Bundle Identifier do seu aplicativo no Get Mini:

Passo 1: Fornecer o Bundle ID

Entre em contato com o suporte do Get Mini e forneça o Bundle Identifier do seu aplicativo iOS (encontrado no Xcode em General > Identity > Bundle Identifier).

Passo 2: Receber a License Key

O Get Mini emite uma chave de licença vinculada de forma exclusiva ao seu Bundle ID específico. Esta chave vincula as credenciais do seu estabelecimento ao seu aplicativo.

Passo 3: Validação do SDK

O SDK valida a licença durante a inicialização:

CommonUtils.setAppLicense("YOUR_LICENSE_KEY")

Se o Bundle ID do aplicativo em execução não corresponder àquele associado à licença, o SDK falha ao inicializar e retorna um erro.

Controle de Ambiente

É estritamente proibido definir o ambiente como "real" (Produção) até que sua implementação tenha sido certificada pelo Get Mini:

// Development/Testing only
CommonUtils.setEntorno("des")  // Allowed during development

// Production - ONLY after certification
CommonUtils.setEntorno("real")  // Requires Get Mini approval

Esse controle impede transações de produção não autorizadas e garante que todas as implementações passem por uma revisão de segurança adequada antes de processar pagamentos reais.

Assinatura como Alternativa de Segurança

Nem todas as transações são autorizadas via PIN. Em cenários específicos, o SDK exige a captura de uma assinatura digital para finalizar a validade legal da venda.

Quando a Assinatura É Necessária

Se o portador do cartão não se autenticou via PIN, a resposta da transação indica isso através do campo AutenticadoPorPin:

func onPaymentFinished(_ result: RespuestaTransaccionDTO!, orError error: Error!) {
    if let transaction = result, transaction.AutenticadoPorPin == false {
        // Signature capture required
        captureCustomerSignature()
    }
}

Isso ocorre comumente com:

  • Transações offline onde a verificação do PIN não foi possível
  • Tipos de cartão específicos que não suportam autenticação por PIN
  • Cartões internacionais com diferentes requisitos de autenticação

Enviando a Assinatura

Seu aplicativo deve capturar a assinatura digital do cliente como uma imagem e enviá-la usando o método envioFirmaDigitalizada:

let signatureDTO = EnvioFirmaDTO(
    withTerminal: terminalDataDTO,
    withFirma: signatureImage,      // UIImage of signature
    Format: 2,                      // 2 = JPEG format
    andOperacion: operationDTO
)

RedsysConfigurationManager.envioFirmaDigitalizada(signatureDTO) { result, error in
    if error == nil {
        // Signature submitted successfully
    }
}

O envio da assinatura é um requisito de segurança obrigatório para concluir transações em que AutenticadoPorPin == false. Sem a assinatura, a transação pode não atender aos requisitos de validade legal.

Responsabilidades de Segurança do Desenvolvedor

Embora o SDK gerencie a criptografia de dados, os desenvolvedores devem aderir às melhores práticas de segurança, conforme descrito na seção “PRECAUCIÓN” (Seção 3) do manual técnico.

Proteções de Ambiente

Nunca use credenciais de produção em ambientes de teste:

  • Use "des" (Desenvolvimento), "int" (Integração) ou "ccal" (Pré-produção) durante o desenvolvimento e testes
  • Mude para "real" (Produção) apenas após a aprovação da certificação do Get Mini
  • Mantenha credenciais de estabelecimento separadas para cada ambiente

Gerenciamento de Logs

Não registre (log) dados sensíveis de transação:

// ❌ BAD: Logs entire response object
print("Transaction result: \(result)")

// ✅ GOOD: Logs only non-sensitive fields
print("Transaction completed with status: \(result.status)")

Objetos de resposta de onPaymentFinished contêm metadados de transação e códigos de autorização que não devem ser armazenados em:

  • Logs de console
  • Logs de sistema
  • Serviços de analytics externos
  • Ferramentas de relatórios de falhas (crash reporting)
  • Arquivos locais

Proteção de Credenciais

Proteja os identificadores do estabelecimento:

FUC (Merchant ID) e Terminal IDs devem ser:

  • Injetados no momento do build via configurações de build
  • Recuperados de uma configuração remota segura em tempo de execução
  • Nunca codificados diretamente (hardcoded) em texto claro no código-fonte ou no controle de versão
// ❌ BAD: Hardcoded credentials
let fuc = "999008881"

// ✅ GOOD: Retrieved from secure configuration
let fuc = Configuration.shared.merchantFUC

Próximos Passos