Customização Pagamento Crediário | MasterData | Checkout

[four2one]

Oi pessoal,
Boa noite.

Nós temos um cenário de customização e gostaríamos de entender se alguém já fez algo parecido onde podemos ter alguma saída mais assertiva.

CONTEXTO
Existe uma customização num cliente nosso onde foi feito por uma agência antiga. A customização é:

1. Clientes só podem usar o método de pagamento Crediário se estiver aprovados;
2. A aprovação é setada no MasterData como true;
3. A customização está na versão do checkout antiga ainda e é feita uma consulta no MD para verificar se aquele email está como true ou false. Nisso, é feito a custom de hide ou block no método de pagamento crediário.

Só uma pequena visualização de como está:

Porém, como é evidente, pode haver inconsistências visto que a VTEX não dá suporte para inserção de customizações no checkout e o maior problema sobre isso é que uma hora ou outra algum cliente consegue comprar sem estar de fato aprovado na planilha de crediário.

Nós realizamos algumas tratativas para que a função possa ser executada o mais rápido, dando um retorno mais assertivo, mas ainda assim não está 100%.

Estamos imaginando que alguma versão customizada de um app backend possa resolver. Vocês já atuaram em algo parecido? Tem alguma ideia para este cenário?

Outra questão é: a ordem dos métodos de pagamentos que exibem no frontend está ligado diretamente com quando eles foram cadastrados. Logo, nosso pensamento é que se a opção crediário fosse a penúltima e não a última, a customização poderia funcionar melhor.

O que vocês acham?

Aguardamos um retorno.

Obrigado,

Diretoria Four2One

[andremiani]

Olá Equipe @four2one, tudo bem?

Pensando aqui, talvez funcione criar uma nova política comercial com uma Regra Condicional para que esta politica comercial seja aplicada apenas ao cluster de cliente desejado.

Em seguida configurando a condição de pagamento restringindo a disponibilidade do meio de pagamento desejado para a política comercial desejada, recém criada e amarrada ao cluster desejado por meio de condições especiais.

Mas acho que o caminho mais comum acaba sendo implementar estas customizações via Checkout UI Custom ou configurando diretamente no template no SmartCheckout, que desde que não tenha erro, deveria ser executado sempre. Só se tiver erros de script no checkout que poderia impedir o seu funcionamento.

[four2one]

Fala @andremiani tudo certo e contigo?

Show de bola. Aparentemente é um caminho sim, mas envolve mexida em política comercial né. Cremos que isso realmente seria uma alteração maior até mesmo na regra de negócios da cliente. Estamos tentando evitar ao máximo.

O que nós realmente estamos testando aqui é algo sobre a ordem dos métodos de pagamento no checkout mesmo. Ou seja, salvamos outra opção de pagamento para que ela fique em evidência antes da do crediário e assim a função consegue finalizar todo o processo de lógica.

Até o momento é a alternativa mais simples e mais assertiva que encontramos. Estamos testando para ver se realmente vai funcionar.

Mas obrigado pela sugestão.

Abs.

[andremiani]

Hmmm talvez eu não esteja entendendo teu cenário, mas especificamente sobre a ordem das opções de pagamento no checkout seria com CSS mesmo.

Primeiro definindo o elemento parent com os atributos display como flex e o flex-direction para a direção desejada, column ou row;

.payment-group .payment-group-list-btn {
    width: 100%;
    display: flex;
    flex-direction: column;
}

Então seria só mudar o atributo order dos meios de pagamentos desejados, exemplos:

#payment-group-creditCardPaymentGroup {
    order: 1;
}

#payment-group-bankInvoicePaymentGroup {
    order: 2;
}

Mas se a ideia for restringir um determinado meio de pagamento para um determinado público, acredito que o caminho é este mesmo que eu havia comentado.

[four2one]

Opa @andremiani ah sim. Realmente, pensando em uma outra versão de cluster, talvez a política faça mais sentido.

Sobre a alteração de ordem:
Até usamos esse versão, forçando ali no código. Mas não estava pegando ainda provavelmente por conta do próprio carregamento do backend.

O que nós vimos dessa alteração da ordem é apenas salvando o método no admin mesmo. A VTEX mostra frontend em primeiro lugar sempre aquele foi salvo por último no admin. Então fizemos isso.

Vamos monitorar por alguns dias para ver se vai ter o efeito esperado.

Qualquer coisa, avisamos aqui se funcionou.

Abs.

[four2one]

Oi pessoal,

Só para sinalizar que o procedimento que descrevemos acima está agora funcionando. Sem reincidências.

Portanto, salvar por último a forma de pagamento tem efeito na customização que estamos usando no checkout.

Vou fechar o tópico.

Abs.

Four2One Team