😀 Ao recarregar e lançar créditos para o usuário, o mais perigoso não é a falta de observação (memo), e sim tratar o memo como se fosse um documento de identidade.
Na minha guia de leitura do Moonlight em @Dusk , notei duas frases quase adjacentes.
O documento retorna o memo em hexadecimal e o classifica como “dados de rotas não confiáveis” que precisam ser validados antes.
Em seguida, o aviso fica mais direto: nunca use o memo como uma chave de idempotência. O que realmente deve ser único é o ID da transação Dusk.
Essa diferença determina o que o sistema de lançamento considera como fato. O memo serve apenas como uma pista para dizer ao sistema “para quem talvez deva ir”; o ID da transação é o que responde “este dinheiro já foi processado?”.
Se a plataforma misturar esses dois, a marcação conveniente na interface pode acabar sendo tratada erroneamente como o livro-razão do backend.
O cenário ruim é quando duas recargas levam um memo idêntico, ausente ou com formato inválido. Se o sistema desduplicar pelo memo, pode deixar de registrar uma delas; se simplesmente atribuir por ele, pode empurrar requisições anômalas para a conta errada. O usuário só vai ver a recarga demorando a cair, enquanto a equipe de operações terá de conciliar valores, logs e clientes repetidas vezes.
Isso não é um problema de design do memo em $DUSK ; é uma questão de o integrador querer ou não admitir que as informações de roteamento, por natureza, precisam de validação. A documentação de @Dusk já indica o caminho: metadados desconhecidos ou inválidos devem ir para revisão manual, e não serem descartados em silêncio.
O que realmente vale a pena verificar é se a parte que integra vai embutir essa regra no produto e fazer o usuário ver que ele está, de fato, passando por revisão manual. #dusk
Na minha guia de leitura do Moonlight em @Dusk , notei duas frases quase adjacentes.
O documento retorna o memo em hexadecimal e o classifica como “dados de rotas não confiáveis” que precisam ser validados antes.
Em seguida, o aviso fica mais direto: nunca use o memo como uma chave de idempotência. O que realmente deve ser único é o ID da transação Dusk.
Essa diferença determina o que o sistema de lançamento considera como fato. O memo serve apenas como uma pista para dizer ao sistema “para quem talvez deva ir”; o ID da transação é o que responde “este dinheiro já foi processado?”.
Se a plataforma misturar esses dois, a marcação conveniente na interface pode acabar sendo tratada erroneamente como o livro-razão do backend.
O cenário ruim é quando duas recargas levam um memo idêntico, ausente ou com formato inválido. Se o sistema desduplicar pelo memo, pode deixar de registrar uma delas; se simplesmente atribuir por ele, pode empurrar requisições anômalas para a conta errada. O usuário só vai ver a recarga demorando a cair, enquanto a equipe de operações terá de conciliar valores, logs e clientes repetidas vezes.
Isso não é um problema de design do memo em $DUSK ; é uma questão de o integrador querer ou não admitir que as informações de roteamento, por natureza, precisam de validação. A documentação de @Dusk já indica o caminho: metadados desconhecidos ou inválidos devem ir para revisão manual, e não serem descartados em silêncio.
O que realmente vale a pena verificar é se a parte que integra vai embutir essa regra no produto e fazer o usuário ver que ele está, de fato, passando por revisão manual. #dusk
