Como eliminámos cobranças duplicadas a nível arquitetural

Um hóspede num hotel toca em "alterar reserva" no tablet do quarto às 11:47pm. A verificação 3DS demora 40 segundos. O sinal de telemóvel cai. Toca novamente. Na maioria dos sistemas de hotelaria, é cobrado duas vezes e estará a ligar para a receção de manhã. No nosso, é cobrado apenas uma vez. Fisicamente. Não é "normalmente". Não é "com monitorização". É arquiteturalmente.

Este artigo aborda o motor de alteração em Self-Service que a mDOS lançou em produção este mês e por que motivo o trabalho de engenharia de pagamentos que lhe subjaz é comercialmente mais relevante do que a sua utilidade operacional sugere.

O problema que a maioria dos SaaS de hotelaria não resolveu

A alteração em self-service (permitir que o hóspede altere a sua própria reserva, pedido ou estadia sem ligar para a receção) parece uma funcionalidade. E é. Contudo, a base de engenharia onde assenta é implacável de uma forma que a maioria das equipas de produto só percebe quando a lança em produção e começa a receber estornos (chargebacks).

O cenário base: um hóspede precisa de alterar algo que envolve custos. Talvez esteja a fazer um upgrade de quarto. Talvez esteja a adicionar um tratamento de spa a uma estadia já em curso. Talvez esteja a solicitar o reembolso parcial de um depósito porque o seu grupo reduziu de 12 para 10 pessoas. Ou talvez esteja a alterar as datas de uma reserva com tarifa flexível e precise de absorver a diferença de tarifa.

Em todos estes casos, o fluxo operacional funciona assim: identificar a alteração, calcular a variação financeira (que pode ser uma cobrança, um reembolso ou ambos em cenários complexos de alteração parcial), encaminhar o pagamento, atualizar o registo da reserva e acionar os fluxos subsequentes (ajustes de fidelização, e-mails de confirmação, notificações operacionais).

Na maioria das plataformas de hotelaria, este fluxo é construído sequencialmente, com cada passo a comunicar com um sistema diferente: o sistema de reservas atualiza primeiro, depois é acionado o processador de pagamentos, em seguida o sistema de fidelização é notificado e, por fim, o sistema de e-mail envia uma confirmação. Cada passo tem o seu próprio modo de falha. Cada passo representa uma oportunidade para uma conclusão parcial.

O modo de falha específico que custa dinheiro real aos operadores: a ligação do hóspede cai entre a chamada de pagamento e a confirmação do sistema de reservas. Do ponto de vista do hóspede, o pedido falhou. O tablet mostra um erro. Tenta novamente. A nova tentativa é concluída com sucesso. No entanto, o pagamento original também foi processado, pois estava em curso quando a ligação caiu. O hóspede é cobrado duas vezes. A receção descobre na manhã seguinte. O hóspede contesta a cobrança. O operador absorve o prejuízo, a taxa de disputa, o tempo do serviço de apoio ao cliente e os danos reputacionais.

Isto não é uma hipótese. É o ticket de apoio ao cliente relacionado com pagamentos mais comum no SaaS para hotelaria. A maioria dos operadores simplesmente aprendeu a viver com isso.

O que a mDOS fez de diferente

O motor de Self-Service trata cada alteração como uma transação com uma chave de idempotência determinística. A chave é derivada da intenção do hóspede: a reserva que está a ser alterada, a mudança específica que está a ser efetuada e a variação financeira aplicada. Se a mesma chave chegar duas vezes num curto intervalo de tempo, o sistema reconhece-a como uma nova tentativa e devolve a resposta original, em vez de processar a alteração novamente.

Parece simples, mas não é. As partes difíceis são:

Derivação de chaves capaz de resistir a informação parcial. A primeira tentativa do hóspede pode ter o estado do formulário incompleto. A sua nova tentativa pode apresentar um estado de formulário ligeiramente diferente se algo tiver sido reintroduzido. A chave precisa de ser suficientemente específica para identificar a intenção de forma única, genérica o bastante para corresponder à nova tentativa e impossível de falsificar para evitar que um utilizador mal-intencionado repita um pagamento bem-sucedido.

Cobranças fora de sessão com cartão guardado no cofre (vault). Na primeira vez que um hóspede paga durante uma estadia, o cartão é guardado de forma segura através do armazenamento de métodos de pagamento da Stripe. As alterações subsequentes durante a mesma estadia utilizam o cartão guardado para efetuar cobranças fora de sessão: sem reintrodução de cartão, sem fricção e sem taxas de abandono na alteração. Contudo, as cobranças fora de sessão podem acionar verificações 3DS que exigem que o hóspede confirme a transação na app do seu banco, o que significa que o sistema deve alternar de forma fluida para um fluxo em sessão se o banco o exigir.

Contabilidade baseada em unidades inteiras (pence). O dinheiro é armazenado e liquidado em números inteiros na menor unidade monetária (pence ou a unidade base equivalente para moedas diferentes de GBP). Saldos, cobranças e reembolsos nunca passam por vírgula flutuante. Quando um total tem de ser repartido por várias partes (como atribuir um desconto ao nível do carrinho entre vários artigos ou dividir um depósito), a quota proporcional é calculada e arredondada para a unidade inteira no momento da alocação. Manter o livro-razão em unidades inteiras elimina toda uma classe de erros de arredondamento que os SaaS de hotelaria habitualmente lançam (e corrigem discretamente com tarefas de reconciliação noturnas).

Fluxos combinados de reembolso parcial e upsell. Um cenário comum: um hóspede reduz o número de pessoas do seu grupo de 8 para 6, o que implica o reembolso parcial de dois depósitos, mas também faz o upgrade do menu, o que gera uma cobrança adicional. O sistema precisa de calcular o saldo líquido de forma correta, aplicar o reembolso e a cobrança numa ordem determinística e apresentar a variação final ao hóspede com o descritivo correto. A mDOS trata esta operação como uma transação composta única; os sistemas legados tratam-na como duas transações sequenciais e torcem para que nada falhe entre elas.

Por que motivo isto é comercialmente relevante

O motor de Self-Service exigiu cerca de seis semanas de trabalho de engenharia para ser lançado com qualidade de produção. É um investimento enorme para o que parece ser uma funcionalidade simples.

A fundamentação comercial por trás deste investimento foi muito concreta: os adquirentes e operadores hoteleiros empresariais realizam o que se chama de due diligence de sistemas de pagamento durante a avaliação de aquisição. O CTO irá perguntar: "O que acontece quando a ligação do hóspede cai durante uma verificação 3DS?" Se a resposta for "temos monitorização", "é raro" ou "temos uma tarefa de reconciliação executada todas as noites", a plataforma chumba na auditoria de due diligence.

Se a resposta for "a arquitetura previne isso: aqui está a lógica de derivação da chave de idempotência e os testes Playwright que o comprovam", a plataforma é aprovada.

O mDOS agora é aprovado. Essa única frase é o que desbloqueia uma classe de clientes empresariais que não teriam considerado a plataforma há seis meses.

O que isto significa para os operadores

Para um operador com múltiplos estabelecimentos que gere 200 espaços, o motor de Self-Service elimina, segundo as estimativas, 3 a 7% de todos os pedidos de apoio ao cliente relacionados com pagamentos. O valor exato varia consoante o tipo de estabelecimento e o perfil dos clientes, mas o padrão é consistente: todos os operadores que comparámos com a infraestrutura legada relatam cobranças duplicadas como uma ocorrência habitual.

Eliminar esses 3 a 7% tem efeitos cumulativos. As horas dedicadas ao apoio ao cliente diminuem. As taxas de estorno reduzem. O trabalho de reconciliação contabilística associado a reembolsos cai. A confiança dos clientes melhora de forma mensurável, especialmente entre os clientes de elevado valor que têm maior probabilidade de utilizar funcionalidades de modificação em self-service. O ROI operacional do motor de Self-Service em grande escala é suficientemente significativo para constituir uma rubrica orçamental própria.

Para um adquirente que avalia o mDOS como propriedade intelectual, o motor de Self-Service sinaliza algo diferente: indica que a equipa de engenharia optou por resolver problemas complexos da forma correta, em vez de lançar soluções mais rapidamente acumulando dívida técnica. É isto que a due diligence técnica dos adquirentes procura verdadeiramente: não o número de funcionalidades, mas provas de maturidade arquitetural nas vertentes menos visíveis do sistema.

O padrão arquitetural num parágrafo

Cada modificação tem origem numa intenção do cliente. A intenção é convertida por hash numa chave de idempotência determinística. A chave é verificada numa tabela de pedidos recentes. Se a chave corresponder a um pedido recente bem-sucedido, o sistema devolve a resposta original. Se a chave não corresponder, o sistema inicia uma transação que processa o delta financeiro (cobrança, reembolso ou composto), a atualização da reserva e o disparo de acionadores como uma única operação atómica. Se algum passo falhar, toda a transação é revertida. Se o cliente tentar novamente a mesma intenção dentro da janela de idempotência, recebe a resposta bem-sucedida original, mesmo que a ligação tenha ido abaixo no pior momento possível.

Este padrão está amplamente documentado na literatura de engenharia de pagamentos. A própria Stripe recomenda-o. Além disso, está quase universalmente ausente no SaaS para a hotelaria e restauração, porque a sua implementação correta exige o tipo de disciplina transacional entre sistemas que as arquiteturas fragmentadas são fundamentalmente incapazes de oferecer.

O mDOS consegue oferecê-lo porque cada etapa do fluxo de modificação reside na mesma base de dados Postgres. O cálculo do delta financeiro, a atualização da reserva, o ajuste de fidelização, o disparo de acionadores: tudo se encontra na mesma transação. A atomicidade não é uma funcionalidade; é uma propriedade da arquitetura unificada.

O que perguntar à sua plataforma atual

Se gere uma operação com múltiplos estabelecimentos na hotelaria ou restauração, três perguntas testam se a sua infraestrutura resolve esta classe de problemas.

Como lida a sua plataforma atual com um cliente que toca em "modificar" duas vezes durante um desafio 3DS com conetividade intermitente? Se a resposta honesta envolver monitorização, reconciliação manual ou intervenção do apoio ao cliente, está a absorver custos operacionais que a arquitetura deveria estar a eliminar.

Que proporção dos seus pedidos mensais de apoio ao cliente se refere a cobranças duplicadas, reembolsos em falta ou discrepâncias de faturação relacionadas com modificações? A maioria dos operadores não mediu isto porque o aceitou como ruído de fundo.

O que faz a sua plataforma quando uma cobrança fora de sessão armazenada desencadeia um desafio 3DS inesperado? Se a resposta for "a cobrança falha e temos de pedir ao cliente para voltar através do checkout normal", tem um problema significativo de taxa de conversão em cada fluxo de modificação.

Estas perguntas não dizem respeito a funcionalidades. Dizem respeito a saber se a engenharia de pagamentos da sua plataforma é suficientemente madura para a escala empresarial.

---

O motor de Self-Service foi lançado em produção em maio de 2026. Documentação técnica disponível mediante NDA mútuo para avaliações em curso.