Quanto tempo leva do clique ao QR Code, e por que isso decide a venda

O cliente aperta comprar. A tela mostra um carregando. Em algum momento aparece o QR Code.

Esse intervalo é o pedaço mais frágil do checkout, e o único que você não enxerga em relatório: quem desiste ali não vira venda perdida no painel, vira uma cobrança gerada que nunca foi paga, ou nem isso.

O que acontece nesses segundos

Gerar um PIX não é gerar uma imagem. É uma conversa com uma instituição de pagamento, que tem que criar a cobrança do lado dela e devolver o código.

Dependendo de como a integração é feita, isso pode ser uma chamada ou várias em sequência. Algumas exigem cadastrar o cliente antes de criar a cobrança, e buscar o código num terceiro passo. Cada passo é uma ida e volta pela internet, e o cliente espera a soma de todos.

Em medição real de uma integração de três chamadas encadeadas, o total fica na casa de um segundo e meio quando tudo vai bem. Quando uma delas engasga, vai pra cinco, oito, ou estoura.

Por que a média engana

Média de tempo de resposta é a métrica mais enganosa que existe em checkout. Se noventa e cinco por cento das cobranças saem em um segundo e cinco por cento levam dez, a média fica em pouco mais de um segundo e parece ótima.

Só que os cinco por cento não são um detalhe: são cinco em cada cem clientes esperando dez segundos numa tela de carregando. Uma parte deles vai embora.

Olhe o pior caso, não a média. É lá que a receita está sumindo.

A resposta certa não é esperar mais

A reação intuitiva a lentidão é aumentar o tempo limite. É quase sempre errado: você trocou um erro rápido por uma espera longa que termina no mesmo lugar.

A resposta certa é ter pra onde ir. Se a plataforma trabalha com mais de uma adquirente, dá pra disparar a tentativa em paralelo e usar a primeira que responder. A que estiver lenta naquele minuto simplesmente perde a corrida, e o cliente nem fica sabendo que existiu.

Isso muda a natureza do problema: em vez de depender de todo mundo estar rápido, você depende de alguém estar rápido.

Falha que não pode virar erro na tela

Existe uma diferença grande entre uma cobrança que demorou e uma cobrança que falhou. A segunda, pro cliente, é a mesma coisa: uma tela dizendo que não deu.

Uma integração bem feita não mostra erro na primeira falha. Ela tenta a próxima adquirente. E se todas falharem, ela ainda não descarta a venda: guarda a intenção e tenta de novo em segundo plano, porque a pessoa que clicou em comprar quer comprar.

Como medir na sua operação

1. Marque o tempo entre o clique e o código aparecer, no navegador do cliente, não no seu servidor.
2. Olhe o pior caso entre cem gerações, não a média.
3. Conte quantas cobranças são geradas e nunca pagas. Um número alto pode ser preço, mas também pode ser espera.
4. Teste no 4G, não no wi-fi do escritório.

Como o Trilho trata

A cobrança é disparada pra várias adquirentes ao mesmo tempo, e vale a primeira que devolver o código. Quem estiver lenta naquele momento perde a corrida sem afetar o cliente.

A plataforma também aprende em tempo real quais estão engasgando e reordena a fila, sem tirar ninguém do jogo: uma adquirente que recusou uma cobrança específica continua disponível pra próxima.

Quando tudo falha, a venda não é descartada. Ela fica registrada e uma rotina retoma a geração em segundos.

Resumo

Meça o pior caso, não a média. Não resolva lentidão com tempo limite maior. E garanta que existe pra onde ir quando uma adquirente engasga, porque uma hora ela engasga.