Contextualizando, a situação é o seguinte. Fui contratado para para dar continuidade no desenvolvimento de um software que foi feito em Maker. Então o antigo programador fez vários JSONs na camada servidor. E foi através dos fluxos dele que estou me espelhando. Então a mesma estrutura que ele utilizou está funcionando no fluxo dele, no servidor.
Só que antes de passar para a camada servidor, fiz toda a funcionalidade na camada cliente, porque a documentação deixa claro que as funções funcionam em ambas as camadas.

A documentação do Maker não ajuda. O que é que a documentação diz sobre a função JSON - Atualiza Valor:

##############
Essa função atualiza um elemento no objeto JSON passado no primeiro parâmetro.
Caso a chave passada no segundo parâmetro não exista a mesma será criada.

Parâmetros:

1. Objeto JSON
2. Chave
   3. Valor <Aqui não está dizendo o tipo de entrada do parâmetro.>

FIM ##############

O antigo programador usa a função JSON - Criar objeto no terceiro parâmetro na camada servidor. Peguei a variável Valor e a converti para inteiro com a função Para Inteiro e funcionou.

Também funcionou com a conversão, mas sem a função JSON - Criar objeto:

Passei a variável pura sem conversão e também funcionou:

O que a documentação diz sobre a função JSON - Criar Objeto:
##############
Esta função recebe um texto JSON e retorna um objeto:

Parâmetro:
1. Texto em JSON. <Aqui não diz qual é o tipo de entrada, mas pela descrição podemos supor que recebe texto em JSON. Então aceitou um valor Integer, mas rejeitou uma String numérica na camada servidor. A String numérica foi aceita na camada cliente.>

Retorno:
Objeto JSON.
FIM###########

Portanto meu caro, se a função é do Maker. Se o Maker usa ou não Javascript, se usa ou não Java, Scalla, C++, .NET, etc, é obrigação da equipe de desenvolvimento fazer com que a função Maker se comporte de acordo com a sua documentação independente se está no cliente ou no servidor. Sou programador Java desde a versão 1.8, lá pelo ano 2000. É muito fácil em Java identificar o tipo ou verificar se uma conversão é possível ou não sem mostrar isso ao usuário. Portanto é muito fácil fazer em Java, na camada servidor, essa função se comportar da mesma forma que a camada cliente e portanto estar mais fiel a sua documentação.

Então no momento em que a documentação do Maker deixa "claro" que a mesma função pode ser usada no cliente ou no servidor, os comportamentos dessa mesma função devem ser idênticos em qualquer aspecto em ambas as camadas. Se há diferença, então é BUG.
Se a equipe de desenvolvimento do Maker não consegue igualar os comportamentos da função tanto no cliente quanto no servidor, então é obrigação estarem descritas na documentação, as diferenças de comportamento.
A documentação do Maker não é boa. Há uma função que não me recordo o nome(teria que pesquisar nos e-mails que enviei ao suporte), que tem tipo de retorno Variante, e o valor era uma String numérica. Tentei as duas formas, passar o valor para uma variável tipo Inteiro, deu PAU, e depois passei o valor para uma variável de tipo Letras, funcionou. Depois converti para Inteiro.
Reportei o problema ao suporte, só do que deu erro e o suporte me disse que o retorno poderia ser Inteiro ou Letras. Inteiro deu pau, então há um BUG aí. Por essa e muitas outras dores de cabeça que tive com a documentação do Maker, que já inicio qualquer texto dizendo que o Maker é a ferramenta mais bugada que conheci na vida.

Prezado @dngadelha, agradeço a sua ajuda. Tentei novas possibilidades em cima de um código que estudei de um outro programador, mas se a documentação afirma que a mesma função pode ser usada em ambas as camadas e há diferenças de comportamento entre essas camadas, então é erro da equipe de desenvolvimento , que poderia sim, converter para inteiro uma String numérica na camada servidor, igualando os comportamentos da função em ambas as camadas.

Se na documentação estivesse claramente a descrição de que essas funções possuem comportamentos diferentes em ambas as camadas, com certeza não teria me esforçado em criar o meu primeiro BODY em JSON na camada cliente. Teria quebrado a cabeça só na camada servidor até conseguir. Fiz isso na camada cliente por culpa da documentação e pela comodidade dos parâmetros necessários para o JSON já estarem na camada cliente, depois era só transferir para a outra camada.

Abraços meu caro, muito obrigado e se há comportamentos diferentes na mesma função e não está documentado, é BUG sim.

O problema na sua regra está na sua chamada da função JSON - Atualizar Valor do processamento topupData, mais especificamente no 3º parâmetro dessa função, onde acredito que você tenha se equivocado em chamar a função JSON - Criar Objeto passando o valor do componente. Assim como mostra no seu print:

Basicamente o que você tentou fazer é:

A camada Cliente é meramente Javascript e, por natureza, ele é muito permissivo em muitas questões de sintaxe e funcionalidade.

No console do navegador se você executar um JSON.parse da string "25" ele vai funcionar e te retornar o número inteiro, que você está associando a chave value do seu JSON.

Esse tipo de abordagem é incorreta em qualquer camada. Uma string "25" (que é o valor do seu componente no vídeo apresentado) não é um JSON válido. Apenas funciona na camada cliente pela natureza do Javascript ser muito permissivo.

Fiz uma regra que dá um console.log no resultado dessa função e me retornou exatamente o trecho do JSON que você espera:

Entretanto a camada Servidor não é assim, o Java é muito mais rigoroso nesses aspectos. Se você tentar dar um parse num JSON que não é válido, ele vai dar erro.

Assim, ao colocar o mesmo fluxo na camada Servidor dá o erro que está ocorrendo com você:

O Maker deixa livre ao desenvolvedor fazer as regras da forma que bem entender e precisar, e ele tenta auxiliar e validar as coisas o máximo que ele puder. Mas esse tipo de situação é meramente erro de lógica de programação do desenvolvedor que está fazendo a regra, coisas essas que o Maker não tem como validar.

Atenciosamente,
Danilo Gadelha.