Oásis e pagamento integrado: o que confirmar por escrito

Aceitar pagamento não é o mesmo que integrar

Uma lavanderia pode aceitar dinheiro, cartão ou Pix manualmente, usar controlador externo para liberar ciclos ou integrar painel, pagamento e gestão. Esses arranjos não são equivalentes. A compatibilidade deve identificar controlador, firmware, versão da máquina e módulo envolvidos. A página pública da Oásis não informa modelo de controlador ou lista de meios por capacidade.

Peça diagrama da sequência: cliente inicia compra; pagamento é autorizado; sistema confirma recebimento; controlador libera ciclo; ocorrência é registrada. Pergunte quem fornece cada parte, instala e atende quando há falha de interface. Um terminal visível no gabinete não prova conexão de ponta a ponta. A proposta deve dizer quais versões foram testadas e quando.

Descreva a experiência antes de contratar

Defina como a pessoa escolhe máquina e ciclo, recebe instruções, confirma pagamento e o que faz se o ciclo não iniciar. Identifique se cada escolha ocorre no painel, terminal, QR Code ou aplicativo. Este guia não recomenda meio de pagamento; a configuração deve ser comparada pela jornada, custo e suporte confirmados.

Considere falha de conexão, transação pendente, duplicidade e cliente que pagou sem receber o ciclo. Registre quem pode liberar manualmente, como confirmar liquidação e evitar nova cobrança. A unidade precisa de política de atendimento e registro. Se depender de internet, documente um plano de contingência antes de abrir.

Peça uma matriz de compatibilidade

Solicite declaração escrita com modelos e versões testadas, firmware mínimo, periféricos aceitos, comunicação, rede, modalidade de transação e limites. Peça data da validação e responsável por atualizações. A lista precisa usar o código Oásis da proposta, não só o nome da linha.

Peça orçamento de equipamentos, instalação, licenças, suporte e taxas. Confirme se atualização pode interromper serviço ou alterar compatibilidade. Se não houver matriz, pergunte sobre teste antes da compra, cenários e critérios de sucesso. Se a função for essencial, deixe essa validação como condição contratual.

Pix Cobrança não homologa equipamento

O Banco Central explica que a API Pix pode apoiar criação e gestão de cobranças, confirmação, conciliação e devoluções; a disponibilidade depende da instituição e da solução contratada. O BCB também informa que algumas funções são facultativas aos participantes. A existência do Pix não demonstra que controlador Oásis aceite o fluxo.

Se usar Pix, confirme QR estático ou dinâmico, recebimento de confirmação, conciliação e devolução. A página do BCB sobre Pix Cobrança e API Pix é referência geral, não certificação de máquina. Não inclua um meio na decisão sem proposta e teste completos.

Teste situações de falha além da compra normal

Teste aprovação com liberação, recusa sem liberação, aprovação sem resposta da máquina, interrupção, cancelamento, devolução, duplicidade, indisponibilidade, perda de rede e conciliação de valor e horário. Registre resultado esperado e observado. Não use dinheiro real de cliente sem informar e sem mecanismo de devolução.

Peça ambiente de homologação. Se só houver teste em produção, limite valores, obtenha concordância e feche conferência. Testar uma unidade não prova compatibilidade de toda a linha. Registre série, terminal e versões testados.

Inclua acesso e dados no escopo

Pergunte quais dados ficam guardados, por quanto tempo, onde, quem acessa e como credenciais são revogadas. Se houver telefone, e-mail ou histórico, esclareça finalidade e controles com o fornecedor. Não exponha senha administrativa. Defina responsáveis e rotina para trocar acessos.

Confirme exportação de transações e vínculo com equipamento, data, ciclo e estorno. Compare relatórios com extratos e registros. Aprovação visual não substitui confirmação de recebimento. Procure orientação profissional para privacidade e contabilidade se houver coleta de dados.

Defina critérios objetivos de aceite

Inclua modelo, versões, pagamento aprovado, liberação do ciclo, registro de erro, cancelamento, devolução, conciliação, suporte e treinamento. Defina prazo de correção se um cenário falhar e quem paga nova visita. Esclareça se homologação está incluída.

Guarde matriz, configurações e protocolos. Se mudar firmware, controlador ou terminal, repita os testes relevantes. A ficha pública não oferece matriz de pagamentos; ela precisa vir dos fornecedores envolvidos.

Quando não há compatibilidade demonstrada

Sem lista, diagrama ou demonstração, marque integração como pendente e não anuncie que está integrada. Pergunte se há combinação validada para o SKU e peça um plano de teste. Se existir alternativa operacional, compare custo e suporte sem presumir superioridade.

Na consulta de 23/10/2026, a fonte pública da Sill não identificava controlador ou meio homologado para Oásis. O BCB explica Pix em geral, não equipamentos. Consulte a Sill para orçamento e a Mentoria SPL para apoio educacional à operação. Compatibilidade precisa de confirmação dos responsáveis por todos os componentes.

Antes de escolher qualquer solução, desenhe o fluxo de uma compra em cada canal: como o cliente identifica a máquina, como vê o preço e a duração, em que momento autoriza o pagamento, como o equipamento recebe a autorização e como a operação sabe que o ciclo terminou. Depois descreva exceções: pagamento aprovado sem início, valor cobrado duas vezes, cancelamento, interrupção de energia ou rede, estorno, disputa e devolução. Para cada evento, anote qual sistema guarda o registro e qual pessoa pode resolver. Um terminal ou QR code no salão não demonstra que o controle da máquina recebeu autorização, nem que a cobrança será conciliada com a operação.

A matriz de compatibilidade deve nomear máquina e versão do painel, controlador, software, meio de pagamento, comunicação disponível, responsável por instalação e suporte de cada parte. Solicite diagrama, pré-requisitos de rede, custos recorrentes, política de atualização e tratamento de dados pessoais. Pergunte se há modo de contingência e como impedir início duplicado ou liberar um ciclo após falha; peça uma demonstração com ambiente de teste, sem dinheiro real, e um relatório que associe transação e máquina. A equipe que atende o consumidor precisa receber procedimento claro para divergência, sem ter acesso desnecessário a credenciais ou dados de pagamento.

Pix Cobrança permite cobrar por Pix segundo a documentação do Banco Central, mas isso não valida a comunicação entre uma solução de pagamento e o controlador da Oásis. São camadas diferentes: a instituição financeira ou provedor movimenta a cobrança, a integração identifica o resultado e o sistema da máquina autoriza um ciclo. Exija confirmação dos responsáveis por cada camada e leia termos de disponibilidade, privacidade e suporte. Se não houver integração comprovada para o SKU ofertado, compare uma alternativa operacional que não dependa de automação, desde que compatível com o fabricante e com a rotina planejada. Registre a decisão como contingência, não como promessa de funcionamento automático.

A conferência deve incluir a conciliação financeira: como o total cobrado se relaciona com a quantidade de ciclos, como taxas e cancelamentos aparecem no extrato e quem pode conferir um caso contestado. Solicite exemplos de relatórios sem dados reais de clientes e entenda o prazo de retenção de cada sistema. Uma tela de “pagamento aprovado” não comprova por si só a conciliação contábil nem resolve divergência. Mantenha os dados de acesso sob controle e use apenas as permissões necessárias para operação e suporte.

Registre uma árvore simples de incidentes antes de aceitar a integração. Se a cobrança aparecer aprovada e a máquina não iniciar, quem verifica o identificador do ciclo? Se a rede cair, o sistema bloqueia novas cobranças ou continua permitindo operação? Se houver repetição de cobrança, qual canal recebe o protocolo e quem pode consultar a conciliação? Cada ramo deve ter responsável, prazo de comunicação definido pelo contrato e ação autorizada. Não transforme uma tela ou mensagem de erro em instrução para reiniciar controlador.

Peça que o fornecedor descreva o relacionamento entre terminal, software, controlador e mecanismo de liberação. Confirme quem fornece atualizações, como são testadas e se uma mudança pode exigir nova homologação. Pergunte o que acontece com ciclos já autorizados durante indisponibilidade e como se preserva registro para atendimento posterior. Para dados pessoais, determine quais informações são coletadas, por quanto tempo, com quem são compartilhadas e que suporte pode acessá-las. Encaminhe essa revisão a quem responde por privacidade e contratos na operação.

Uma prova de conceito deve usar o ambiente e roteiro aprovados pelos fornecedores, registrar cada resultado e incluir falhas previstas, não apenas um pagamento que funcionou. Se não houver sandbox ou documentação, não faça um teste real com clientes para descobrir compatibilidade. Mantenha a compra condicionada a uma demonstração controlada ou planeje outro fluxo validado. Mesmo uma solução que conecte via Pix precisa explicar o tratamento de devolução, contestação e conciliação; o funcionamento do arranjo financeiro não resolve esses detalhes da máquina.

Inclua no aceite quem atualiza o painel se o preço de um ciclo mudar e como a nova tabela será comunicada. Atualização de cobrança e autorização da máquina precisam permanecer sincronizadas; peça ao fornecedor que mostre como a configuração é validada depois da mudança e como recuperar a versão anterior em caso de erro.

Inclua no roteiro quem atende uma transação contestada e que protocolo deve ser guardado, sem pedir senha do cliente. Separe o suporte da cobrança daquele que resolve a falha da máquina; um chamado pode envolver ambos, mas cada parte precisa ter um responsável claro.

Perguntas frequentes