Como testar pagamento e liberação de ciclo

Defina o resultado antes de testar

O teste não termina quando o terminal mostra “aprovado”. Confirme a cadeia entre a intenção do cliente e o efeito no equipamento: qual máquina foi selecionada, qual ciclo foi pedido, qual cobrança corresponde à sessão, qual evento confirmou o pagamento e o que o controlador liberou. Sem essa ligação, a equipe pode ver um recebimento no extrato sem saber se ele corresponde ao ciclo iniciado.

Escreva uma regra de aceite para a configuração entregue: uma cobrança confirmada para uma sessão identificada resulta em uma única liberação da máquina e do ciclo selecionados. Uma cobrança recusada ou ainda pendente não libera. A repetição técnica da mesma confirmação não gera outra liberação. A devolução altera o estado financeiro conforme o meio e a política definida, mas não cria novo ciclo nem deve interromper automaticamente uma lavagem em andamento.

Registre identificador de teste, máquina, ciclo, valor, horários, estado observado no meio de pagamento, resultado do controlador, quantidade de liberações e evidência consultável. Use referências de transação; não armazene número completo de cartão, código de segurança ou credenciais. Combine quem pode operar o painel e interromper o ensaio.

Este texto cobre os casos funcionais do vínculo pagamento–ciclo. A avaliação completa de componentes, instalação, requisitos e entrega é outro escopo; consulte também o guia Como testar a integração completa antes de aceitar a entrega.

Prepare um ensaio controlado e rastreável

Confirme se há ambiente de homologação ou modo de teste que simule cobrança e resposta sem movimentar dinheiro nem iniciar equipamento real. Nem todo conjunto de terminal, controlador e software oferece esse recurso. Registre o que está sendo testado: uma simulação de evento pode validar a lógica do software, mas não comprova sozinha o funcionamento elétrico e mecânico da máquina.

Se não houver ambiente isolado, planeje uma janela autorizada. Use uma máquina disponível, avise quem estiver no local, evite roupas de clientes e combine como evitar ou encerrar um ciclo real. Na operação real, execute apenas transações previstas na janela e no procedimento aprovados. Reenvios artificiais de eventos e falhas de comunicação ficam restritos à homologação ou a procedimento técnico expressamente autorizado; não os improvise em loja aberta. Não abra painéis ou contorne intertravamentos. Ensaios com intervenção técnica devem seguir procedimentos do fabricante e ser feitos por profissional habilitado.

Monte uma ficha por cenário: condição inicial, ação, resposta esperada, resposta observada, identificador financeiro, máquina/ciclo, horário e conclusão. Encerre a sessão anterior sem apagar seu histórico e inicie uma nova sessão identificada antes de cada repetição para que um pagamento anterior não mascare uma liberação indevida. Guarde evidências separadas do terminal, sistema de pagamento e controlador, sem dados pessoais desnecessários.

A confirmação deve vir da fonte de estado acordada na integração — por exemplo, consulta ou notificação autenticada — e não apenas da tela do cliente ou da página de retorno no navegador. O Banco Central explica que a API Pix pode apoiar criação e gestão de cobranças, verificação de liquidação, conciliação e devolução, enquanto recursos adicionais dependem da instituição. Confira a descrição oficial do Pix Cobrança.

Teste aprovação e recusa

Aprovação: selecione uma máquina livre e um ciclo identificável, gere cobrança nova e conclua o pagamento de teste pelo fluxo combinado. Espere a confirmação reconhecida pelo sistema e observe a máquina: apenas a escolhida deve aceitar o comando, com o ciclo selecionado. Se o equipamento exigir que o usuário pressione iniciar depois do pagamento, verifique primeiro a habilitação e depois uma única partida, seguindo o fluxo previsto. Pagamento confirmado não deve contornar porta fechada, intertravamentos ou indisponibilidade da máquina. Confira se o registro financeiro e o do controlador apontam para a mesma sessão. Se o ciclo aparece como código, anote a configuração e peça ao integrador a legenda.

Recusa: provoque-a pelo recurso de teste do provedor ou outro método oficial de homologação. O resultado esperado é cobrança recusada e nenhuma liberação. Verifique se a interface comunica a falha sem manter a sessão como paga. Se o cliente puder tentar novamente, a nova tentativa precisa ter referência própria ou vínculo rastreável à sessão; uma recusa antiga não deve ser convertida em aprovação por mensagem tardia.

Não use cartão de terceiro nem números inventados em produção para provocar recusa. Cada provedor publica seus próprios dados de teste e regras de homologação; use-os somente no ambiente e nos termos correspondentes. “Aprovado” precisa significar pagamento confirmado segundo aquela integração: autorização, processamento e retorno pendente podem ter significados distintos.

Repita a aprovação em outra máquina e com outro ciclo, mantendo o restante igual. Isso ajuda a verificar se a sessão está associada à máquina certa e se o mapeamento dos ciclos não foi trocado. Um ensaio não comprova compatibilidade de outros modelos ou versões.

Teste atraso e confirmação duplicada

Atraso: simule uma cobrança pendente ou atrase a entrega do evento em homologação. Antes de uma confirmação válida, a máquina não deve iniciar. Quando chegar o estado aprovado, a liberação só cabe se a sessão ainda estiver válida, vinculada à escolha original e apta ao início. Se a sessão expirou, foi cancelada ou a máquina foi ocupada por outro atendimento, registre o pagamento para conciliação e aplique o tratamento documentado, sem iniciar um ciclo antigo automaticamente. Se a confirmação nunca chegar, a sessão fica sem liberação ou expira por regra documentada; ausência de resposta não é pagamento concluído.

Duplicidade: faça o sistema receber duas vezes a mesma notificação ou repetir a solicitação no ambiente de teste. O esperado é um pagamento contabilizado e no máximo uma liberação. Compare o identificador do evento/transação com o da sessão e confira que a segunda entrega foi reconhecida como já processada. Peça ao integrador evidência de que tanto a confirmação financeira quanto o comando ao controlador resistem a repetição: impedir duplicidade no pagamento não prova, sozinho, que a máquina não receberá nova partida.

Se possível, teste mensagens fora de ordem, como uma notificação de pendência recebida depois da confirmação final. O sistema não deve regredir a estado incompatível nem liberar novamente. Peça ao fornecedor a tabela de estados reconhecidos e o comportamento em reenvios, tempo limite e consulta de reconciliação; não deduza a regra a partir de eventos de outro serviço.

O atraso pode revelar cobrança confirmada sem ciclo iniciado ou confirmação recebida depois de a sessão expirar. Documente como localizar o caso, quem atende e que evidência será necessária. O tratamento pode exigir suporte ou devolução manual; não prometa prazo sem base contratual.

Diferencie evento duplicado de pagamento duplicado. No primeiro, a mesma transação foi comunicada novamente; no segundo, existem dois recebimentos distintos. Teste o segundo caso apenas pelo fluxo autorizado: preserve ambos os identificadores, confira que não houve novo ciclo indevido e encaminhe a cobrança excedente para análise e devolução conforme a política definida.

Confira o vínculo entre cobrança, máquina e ciclo

O caso principal precisa provar a associação, não apenas o sucesso financeiro. Faça duas sessões com máquinas e ciclos diferentes. Confirme que cada uma tem identificador rastreável e que a confirmação de uma não libera a outra. Se a seleção do ciclo ocorre antes do pagamento, verifique que ela não muda durante a espera. Se o cliente pode voltar e escolher outra opção, confirme que valor e configuração enviados na cobrança continuam coerentes com a escolha final.

Inclua uma sessão cancelada antes de pagar, tentativa de pagamento depois do cancelamento e cobrança confirmada para sessão expirada. O tratamento pode variar: bloquear pagamento, abrir nova sessão ou encaminhar para atendimento. O ponto de aceite é que não se libere máquina/ciclo diferente do associado à cobrança. Se o fluxo não identifica a sessão ligada ao pagamento, registre falha de rastreabilidade mesmo que alguém consiga iniciar a máquina manualmente.

Compare quatro lados: referência apresentada ao cliente; transação no provedor; evento ou consulta recebida pelo software; comando e resposta do controlador. Anote horários e identificadores sem supor que a ordem em que as telas atualizam seja a ordem real dos eventos. O Banco Central descreve o txid como identificador da cobrança na perspectiva do recebedor e apoio à conciliação em cobranças via API; isso não significa que todo QR estático gere vínculo individual da mesma forma. Consulte o Manual de Padrões para Iniciação do Pix.

Registre marca/modelo de máquina, controlador, terminal, versão de software e configuração efetivamente ensaiados. A evidência cobre esse conjunto identificado naquela data; mudança de versão, conta ou parametrização pode alterar o fluxo.

Teste devolução e conciliação

Faça a devolução em ambiente de teste quando houver essa opção. Confirme o estado financeiro da transação original, o valor devolvido e o vínculo entre ambos. Uma solicitação de devolução não prova, por si só, que o valor já voltou; estados e prazos dependem do meio e do provedor. Registre a solicitação e o resultado final separadamente; se a devolução falhar ou continuar pendente, atribua responsável pelo acompanhamento até a conciliação.

Para Pix, o Banco Central orienta que a devolução de valor recebido seja feita pela função vinculada à transação original, total ou parcialmente, em vez de uma nova transferência. Leia a orientação oficial sobre devolução de Pix. A execução deve respeitar a política do estabelecimento e as funções do PSP contratado.

Teste separadamente a devolução antes da partida e depois do início do ciclo. Antes da liberação, confirme se a regra impede o início, cancela a sessão ou encaminha para tratamento manual. Depois do início, não presuma que a operação financeira interrompa ou desfaça o ciclo; confirme a segurança do equipamento e registre à parte pagamento, devolução e máquina. O estorno não deve mandar uma segunda ordem de partida.

Na conciliação, procure transação original, tentativas, devolução e sessão. Defina quem analisa divergências como pagamento aprovado sem liberação ou duas cobranças para uma sessão. O PCI SSC ressalta que terceirizar processamento de cartão não elimina todas as responsabilidades do estabelecimento: cabe verificar conformidade do prestador e entender responsabilidades compartilhadas. FAQ 1092 do PCI SSC.

Registre o aceite e trate as falhas

Feche o ensaio com uma tabela e marque aprovado somente quando a condição esperada foi observada e há evidência correlacionável. “Pagamento aprovado” sozinho não é aceite de ciclo; “máquina começou” não prova que a cobrança certa foi usada.

Inclua versões e configuração usada, data, participantes, falhas, evidências e pendências. Guarde só os registros necessários para auditoria e suporte, controle acesso e evite anexar telas com dados pessoais ou de pagamento. A ficha deve permitir que outra pessoa repita o cenário.

Se um teste falhar, suspenda o aceite daquele fluxo, preserve identificadores e peça ao responsável técnico causa e novo ensaio reproduzível. Depois da correção, repita o caso e os relacionados: uma mudança no reenvio pode afetar aprovação e devolução. Critérios contratuais, prazos de suporte e garantia precisam ser acordados com os fornecedores; este protocolo não os determina.

O checklist não substitui avaliação integral de segurança, instalação, compatibilidade e operação assistida. Para estruturar implantação e rotina com apoio, conheça a Mentoria da Sua Própria Lavanderia.

Perguntas frequentes