• O kernelInitialize() é o primeiro método obrigatório que deve ser chamado antes de usar qualquer funcionalidade do SDK.

<li>
  <strong>Onde chamar:</strong> chame na classe <code>Application</code> do app, dentro do método <code>onCreate()</code>.
</li>

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        if (!TapOnPhone.kernelInitialize(this)) return
    }
}

• Essa condição evita a execução duplicada do código, garantindo que o kernel seja inicializado apenas uma vez.

Para mais informações, consulte a seção Inicialização do Kernel.

• O setConfig() é um método obrigatório usado para configurar as credenciais e as configurações do SDK em uma única chamada.

<li>
  <strong>Quando chamar:</strong> deve ser chamado <strong>após</strong> <code>kernelInitialize()</code> e <strong>antes</strong> de usar qualquer outro método do SDK.
</li>

<li>
  O método recebe um objeto <code>ConfigParameters</code> contendo contexto, credenciais e configurações opcionais.
</li>

Para mais informações, consulte a seção Definir configurações do SDK.

• Não. A inicialização é opcional e pode ser feita de duas formas:

    <ol>
      <li>
        <strong>Manualmente:</strong> chamando <code>TapOnPhone.initialize()</code> antes do pagamento.
      </li>
  
      <li>
        <strong>Automaticamente:</strong> se não for feita manualmente, o SDK realizará a inicialização automaticamente quando você chamar <code>TapOnPhone.pay()</code>.
      </li>
    </ol>
  </li>
  
  <li>
    A inicialização manual é recomendada para evitar tempo de espera no primeiro pagamento.
  </li>

Para mais informações sobre o método de inicialização, consulte a seção Inicialização.

• Sim. É possível e recomendado criar a sessão antes do pagamento usando o método TapOnPhone.activateSession().

<li>
  Isso reduz o tempo de espera e melhora a experiência do usuário.
</li>

Para mais informações sobre ativação de sessão, consulte a seção Ativação da Sessão.

• Para otimizar o tempo de pagamento e melhorar a experiência do usuário, recomenda-se:

    <ol>
      <li>
        <strong>Inicializar o SDK durante o carregamento do app:</strong> chamar <code>TapOnPhone.initialize()</code> logo após o <code>setConfig()</code>.
      </li>
  
      <li>
        <strong>Ativar a sessão após a inicialização:</strong> chamar <code>TapOnPhone.activateSession()</code> logo após a inicialização bem-sucedida.
      </li>
  
      <li>
        <strong>Pagar:</strong> chamar <code>TapOnPhone.pay()</code> para iniciar o processo de pagamento.
      </li>
    </ol>
  </li>
  
  <li>
    Com essas práticas, o pagamento será mais rápido, pois tanto a inicialização quanto a criação da sessão já terão sido concluídas previamente.
  </li>

Para mais detalhes, consulte as seções Inicialização e Ativação da Sessão.

• O SDK é inicializado apenas uma vez, não necessariamente antes de toda venda.

• Não existe um tempo limite. A sessão deve ser inicializada sempre que o app é encerrado ou antes de qualquer pagamento.

• Credenciais incorretas no processo de onboarding. Verifique novamente as credenciais abaixo:

    <ul>
      <li><code>clientId</code></li>
      <li><code>clientSecret</code></li>
    </ul>
  </li>
  
  <li>
    Erro nas informações do seu aplicativo. Verifique se os dados abaixo estão corretos:
  
    <ul>
      <li><code>packageName</code></li>
      <li><code>versionCode</code></li>
      <li><code>SHA-256 Fingerprint</code></li>
    </ul>
  </li>
  
  <li>
    Verifique se o manifesto do seu aplicativo (<code>AndroidManifest.xml</code>) não está com a configuração abaixo, pois isso pode impossibilitar a inicialização do SDK:
  </li>

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    tools:node="remove">
</provider>

Para mais informações sobre credenciais, consulte as seções Onboarding e Inicialização.

• Sim. Nesses casos, adicione as seguintes configurações no arquivo proguard-rules.pro:

-keep class com.zoop.sdk.** { *; }
-keep class com.mypinpad.tsdk.** { *; }
-keep class javax.naming.** { *; }
-keep class javax.naming.directory.** { *; }
-dontwarn javax.naming.**
-dontwarn javax.naming.directory.**

• Erros de attestation estão associados à não aprovação do aparelho pela Play Store e a outras métricas de segurança.

<li>
  Credenciais incorretas também podem ocasionar esse erro.
</li>

<li>
  O <code>versionCode</code> do aplicativo na Play Store pode não estar liberado na Zoop. Verifique o range de versões liberado para uso.
</li>

<li>
  Celular em modo Debug ou com root impedirá o uso do aplicativo com o SDK.
</li>

Ver também: Attestation e instanceId quando o attestationStatus aparece nas respostas de erro.

• Não. O app com o SDK nesses dois modos não passará nas etapas de segurança e provavelmente retornará um dos erros de Attestation.

• O SLA é de até 7 dias após o pedido de liberação.

• Não. As credenciais são únicas para cada aplicativo liberado na loja.

• As transações do SDK aceitam metadata e referenceId, que podem conter informações para esse controle.

<li>
  A implementação e o gerenciamento dessa identificação ficam a cargo do desenvolvimento do parceiro.
</li>

• Sim. A partir do SDK 2.3.1, use a dependência com.zoop.sdk:taponphone-sandbox-debug no Gradle no lugar de staging/production.
• Para fluxos que dependem de produção e das políticas das lojas, siga as orientações do onboarding e do suporte.

Consulte também a seção Ambiente Sandbox.

• Sim. O modo Sandbox está disponível no SDK a partir da versão 2.3.1 para integração e testes sem publicar o aplicativo na loja.

Consulte a seção Ambiente Sandbox.

• Não. A Zoop não oferece suporte para essas tecnologias.

<li>
  Garantir o funcionamento da integração em React Native ou Flutter é responsabilidade da equipe de desenvolvimento.
</li>

• Não.

<li>
  É necessário apenas enviar um vídeo do fluxo de pagamento completo do aplicativo desenvolvido até a tela de sucesso, com a animação da bandeira Visa e Elo.
</li>

• O suporte técnico na integração do app cobre apenas problemas associados diretamente ao SDK.

<li>
  A Zoop não oferece suporte ao desenvolvimento do aplicativo.
</li>

<li>
  É responsabilidade do parceiro garantir uma equipe técnica qualificada para realizar a integração.
</li>

• Não.

• Não. Isso deve ser apresentado na animação de aproximação pelo próprio parceiro que realiza o desenvolvimento.

<li>
  O SDK oferece a funcionalidade de verificar a antena NFC do dispositivo por meio da classe <code>CardProximityReader</code>.
</li>

Para mais detalhes, consulte a seção Leitor de Proximidade.

• Sim. No menu Configurações do Tema, é possível visualizar essa opção.

• Não. Não há um limite determinado.

<li>
  Como referência, essa animação está com largura de <code>343px</code> e altura de <code>250px</code>.
</li>

• As páginas de memória de 16KB são uma nova exigência do Google Play para aplicativos que visam o Android 15 ou versões mais recentes.

<li>
  Essa mudança é necessária para garantir compatibilidade futura, otimização de memória e conformidade com as políticas do Google Play.
</li>

<li>
  <strong>Prazo:</strong> 31 de outubro de 2025, com possibilidade de extensão até 30 de maio de 2026.
</li>

<li>
  <strong>Consequência:</strong> se as atualizações do seu app não forem compatíveis com páginas de <code>16KB</code>, não será possível lançá-las após o prazo.
</li>

<li>
  A partir da versão <strong>1.7.2</strong>, o SDK Zoop já inclui suporte para páginas de <code>16KB</code>.
</li>