O campo JSON Data está vazio e eu preciso das variáveis presentes nele para reconstruir o layout do e-mail, onde consigo um JSON Data ‘default’ do e-mail de Pagamento não autorizado?
No fluxo normal quando um pagamento é negado, o usuário não chega a completar o checkout, e, se o pedido é criado mas o pagamento é recusado, o pedido é cancelado sem disparar o e-mail transacional “pagamento não autorizado”.
Exatamente em qual contexto esse e-mail é disparado eu ainda não descobri, mas acredito que tenha haver com transações de negócios b2b ou com um meio de pagamento que não utilize a captura automática por padrão e com processamento em período específico que pode ocorrer durante o faturamento do pedido.
Mas se você está alterando os templates, recomendo a ferramenta abaixo que facilita muito a manutenção dos templates, além de permitir versionar todos os ajustes realizados nos templates.
Complementando o @andremiani, você só vai conseguir ver o JSON se algum pedido passou por esse fluxo.
Quem preenche esse JSON é o backend da VTEX. Portanto, se nunca houve um pagamento não autorizado na loja, é por isso que ele está vazio.
Você pode tentar pedir para a VTEX via chamado um json de exemplo, mas acho que você ainda terá um trabalho para mexer em campos que muda dados do pagamento por exemplo.
O ideal seria você tentar simular um pedido em que o pagamento fosse negado/não autorizado para que passe por esse fluxo de email e poder carregar o JSON para você.
Espero que essas informações te ajude de alguma forma.
Acho que o maior desafio do Henrique é conseguir que um pedido caia nesse cenário!
Especialmente se a loja já é “rodada” e o JSON correspondente ainda está vazio no VTEX Message Center, isso me parece um indicativo de que o template não está sendo usado e, portanto, não precisa de revisão.
@henrique98, no repositório que compartilhei acima, na pasta source/data/vtex, você encontra os principais JSONs de exemplo que a maioria dos projetos utiliza.
Mas seria ótimo se a ferramenta acima oferecesse mais flexibilidade, como diferentes JSONs para cada cenário, o que ajudaria a testar casos comuns, por exemplo, como cada template se comporta para pedidos enviados ou retirados na loja.