Uma falha no rastreio exige a referência da transação

A verificação do rastreio segue o depósito de ponta a ponta: ligação da fonte ou código promocional, conta do jogador, pagamento concluído, postback e relatório. Se a marca e a agência tiverem totais diferentes, esse caminho mostra onde procurar. Comece pela referência de uma transação na caixa. Depois encontre o passo em que se perdeu ou foi atribuída a outra fonte.

A ligação tem de chegar ao registo

Um código de fonte no URL da página de entrada identifica a visita. Indica de onde veio. O relatório precisa de mais: o código tem de chegar ao registo e continuar associado à conta que paga mais tarde. A primeira página pode funcionar e dar origem a uma conta de jogador sem rastreio.

Siga o caminho pelos redirecionamentos, pelo formulário de registo e pela caixa. Uma nova sessão não deve apagar a fonte guardada. Numa visita posterior, o URL pode já não ter parâmetros e a conta continuar com a atribuição original, segundo a regra acordada. Verificar apenas o URL não mostra essa diferença.

As verificações antes do arranque explicam como organizar um teste de controlo com a marca. O resultado deve ser uma cadeia que se consegue seguir: código da fonte, referência do jogador, referência da transação, estado de sucesso e hora de conclusão.

Use códigos de fonte estáveis por trás das designações legíveis do relatório. Mudar o nome de um tipo de criador ou a designação apresentada não deve quebrar a ligação a uma conta anterior. A marca pode agrupar o resultado por mercado e tipo de criador, enquanto quem verifica um pagamento contestado utiliza as referências originais.

A ligação e o código podem apontar para fontes diferentes

Um jogador pode seguir uma ligação e, mais tarde, usar um código promocional de outra fonte. É preciso uma regra para esse caso. Um código aceite altera a fonte a que se atribui o jogador? A ligação anterior mantém a prioridade? Há alguma razão para deixar o caso em aberto até a marca o verificar?

Acorde essa regra antes do teste. Escolher a regra depois de ver que fonte parece mais forte transforma uma questão técnica numa disputa de atribuição. O valor na caixa pode manter-se e o relatório por fonte mudar. A regra conta mesmo quando ninguém discute que o pagamento aconteceu.

Introduzir um código e a marca aceitá-lo são passos diferentes. O jogador pode escrever um código que a marca rejeita. Verifique se o código aceite foi guardado na conta certa e se pertencia àquela fonte no momento. Uma captura do campo de introdução não responde a isso.

A regra deve também indicar a que pagamentos se aplica e como trata contas existentes. Mantenha a ligação original e o código aceite disponíveis ao lado da fonte final. Assim, uma linha contestada pode ser explicada com ambos os sinais visíveis.

Quando a ligação e o código aceite não coincidirem, a linha do pagamento deve mostrar a fonte escolhida e a regra que decidiu a atribuição.

Um postback atrasado pode mudar o período do pagamento

Um pagamento termina a uma hora; o postback pode chegar mais tarde. O relatório precisa de ambas as horas. Se o sistema de destino agrupar os depósitos pela chegada da mensagem e a marca os agrupar pela conclusão do pagamento, o mesmo pagamento pode aparecer em períodos diferentes.

A hora de corte e o fuso horário têm de coincidir antes de se compararem os totais. Um depósito concluído pouco antes do corte pode chegar ao outro relatório depois dele. A correção pertence ao período definido pela regra de reporte acordada, com uma nota a explicar o atraso.

Há ainda outro prazo: a janela de atribuição. Ela determina durante quanto tempo uma ligação ou um código permite associar um evento posterior à fonte. Indique o evento que abre a janela e o evento a que ela se aplica. Uma janela que termina no registo responde a uma pergunta diferente de uma que termina na conclusão do depósito.

Para analisar o tempo decorrido desde o primeiro depósito (FTD) de um jogador, use os períodos de observação das coortes. Ao seguir um pagamento entre sistemas, verifique se a hora de conclusão e a forma de tratar a fonte se mantêm.

Um reenvio deve encontrar o pagamento original

Um postback é uma mensagem sobre um evento acordado. Pode comunicar um registo, uma tentativa de pagamento ou um depósito concluído. Quem o recebe precisa de saber qual deles. A entrega bem-sucedida de uma mensagem sobre uma tentativa pendente não transforma essa tentativa em dinheiro na caixa.

A referência da transação liga o pagamento concluído às suas mensagens. Se essa referência só for única dentro de uma marca ou de um sistema de pagamentos, inclua esse contexto na correspondência. O valor e a hora de chegada são substitutos fracos: dois pagamentos reais podem ter o mesmo valor, enquanto duas mensagens sobre o mesmo pagamento podem chegar com um intervalo grande.

As atualizações de estado também devem encontrar o mesmo pagamento. Um pagamento pendente que passa a concluído muda de estado na transação original. Se as atualizações chegarem fora de ordem, os dados atuais da caixa determinam o estado válido. Um estorno precisa de uma correção visível associada à referência original.

Estas são verificações de pagamentos. A diferença entre pagamentos e primeiros depósitos está no relatório de depósitos. Fazer corresponder as mensagens é apenas o passo que permite usar os dados dos pagamentos.

Encontre as linhas em falta antes de discutir o total

Um total mais baixo da marca pode resultar de uma associação à fonte em falta, de uma entrega atrasada ou de linhas a mais no sistema de destino. Comece por uma lista curta de referências de transações em falta ou a mais. Depois siga o ponto em que os dados deixam de coincidir.

Algumas diferenças são dinheiro em falta no relatório. Outras são o mesmo dinheiro atribuído a outra fonte. Tratar ambas como um depósito em falta leva a equipa pelo caminho errado. Compare os dados originais antes de mudar o valor ou a atribuição da fonte.

A diferença entre a caixa e o relatório tem de ser explicada

Essa explicação mostra que pagamentos concluídos chegaram ao relatório, quais não têm fonte associada e quais aguardam entrega. Cada valor da diferença deve ter uma razão que se consiga verificar.

Não acrescente os 60 € ao teste só para fazer coincidir o total. Só pertencem ao teste se a regra de fonte acordada sustentar essa atribuição. Da mesma forma, ficarem fora do relatório atribuído não significa que os pagamentos falharam.

Um relatório com várias moedas precisa de uma reconciliação por moeda ou de uma regra de câmbio acordada. A exportação usada na nova verificação precisa também do corte original. Caso contrário, pagamentos atrasados e pagamentos novos podem entrar juntos na correção, e ninguém consegue dizer o que mudou.

Uma célula vazia não é uma conclusão

Uma célula vazia pode significar que a exportação está atrasada, que o campo nunca foi fornecido ou que a associação à fonte falhou. Verifique o que aconteceu antes de a interpretar como zero.

Um zero significa que os dados acordados foram verificados e não se encontrou um pagamento concluído correspondente. Se os dados dos pagamentos não chegaram, escreva «Exportação pendente». Se o pagamento existe mas a atribuição está por resolver, escreva «Fonte em falta». Uma nota clara ao lado da célula evita uma discussão inútil sobre desempenho.

Preferimos deixar uma lacuna explicada a publicar um zero arrumado que ninguém verificou. Se os dados chegarem mais tarde, apresente o valor revisto e a razão da mudança. O relatório anterior continua assim a ser compreensível, em vez de parecer que os jogadores mudaram de comportamento de um dia para o outro.

A correção termina quando a próxima exportação coincide

Devolver uma captura de ecrã é fácil. Resolver a diferença exige as mesmas referências, datas, moeda e regras de estado na próxima exportação comparável. O pagamento deve aparecer uma vez, com a fonte sustentada pela regra acordada. Se o atraso continuar, indique que linhas ainda estão à espera.

O acesso às estatísticas de depósitos ou uma exportação regular faz parte do que a marca fornece para o teste. Use a exportação correspondente nesta nova verificação, mantendo o mesmo período para não confundir pagamentos novos com os que foram recuperados.

Faça esta verificação com tempo para corrigir o caminho enquanto o teste ainda é útil. Mantenha as referências das transações nas notas de trabalho. Credenciais dos jogadores e dados dos pagamentos não pertencem a uma captura de ecrã que circula entre equipas.

Guarde a referência confirmada da transação com a regra de atribuição usada no relatório. Quando alguém voltar à diferença anterior, deve conseguir encontrar esse pagamento na nova exportação.

«Corrigido» exige uma linha que alguém consiga encontrar.