Histórico de mensagens em sugestões

Bom dia, Noturno! Repassamos à nossa equipe do WHMCS para que implementem futuramente a sugestão.

Ficaria bem mais "didático" e coerente pois o mesmo "whmcs" tem tais campos de taxa e feed... obrigado.

Bom dia amigos, gostaria de deixar aqui uma sugestão, para API-Boleto - quando o mesmo for pago em atraso o callback para o whmcs viesse "descriminado" os juros e multas, coisa que nao acontece hoje. Aproveitando para adicionar a mesma descriminação para as taxas tanto na api-boleto como api-pix, claro essa taxa seria mostrada para os admins do whmcs.

Obrigado

Entendi. Obrigado pela sugestão!
Irei levar para nosso time avaliar, e qualquer novidade traremos aqui.

Certo.. Então, mas acho que vocês poderiam criar dados errados propositais para dar erro com as informações da primeira mensagem..

Se o dev digitar dados X, ele quer receber mensagem de numero do cartão inválido
Se o dev digitar dados Y, ele quer receber mensagem de data vencida
Se o dev digitar dados Z, ele quer receber mensagem de cvv inválido

e eetc

Isto ocorre, pois em homologação quaisquer dados de cartão seriam válidos desde que atendam o padrão dos campos.
Mas de toda forma, irei levar para o time responsável verificar esta questão para validar a data de expiração em homologação.

ambos com o mesmo cartão vencido

Se por alguma razão não for possível confirmar o pagamento, como dados inválidos do cartão, falta de limite, etc, o status da transação será alterado para unpaid e enviada uma notificação para seu sistema sobre este status.

Certo, mas ai se eu envio o token, depois de verificado os dados que foram enviados e eles estão incorretos não retornam mensagem de erro

Entendi, <@!517929783753965588>.
Em primeiro momento, na criação do payment_token é validado somente se os campos estão seguindo os formatos corretamente. Por exemplo, se você informar um código CVV com 2 caracteres (Ex: 23) irá apresentar uma falha para obter o payment_token.

No entanto, se os parâmetros estiverem seguindo o padrão correto, a verificação se o cartão é válido será feita no momento da criação da transação.

certo, mas um exemplo do que eu to falando é que na própria documentação os dados que estão lá é do cartão que venceu em maio, e passa normalmente

Olá, <@!517929783753965588>. Boa tarde. Tudo bem?
Em alguns locais da documentação você encontra dados de cartão de crédito de exemplo:
https://dev.gerencianet.com.br/docs/pagamento-com-cartao#section-a-obtendo-um-payment_token-getpaymenttoken-

Mas você pode utilizar qualquer número de cartão que seja válido. Você pode gerar alguns de exemplo no seguinte site: https://www.4devs.com.br/gerador_de_numero_cartao_credito

Oi pessoal, boa tarde!
Estava aqui pensando em algum jeito de testar alguns tipos de erros em transações e acho que tenho uma sugestão para vocês (caso já exista, por favor me sinalize como utilizar).

Eu gostaria que tivesse dados de cartão de crédito para a gente testar em sandbox onde a mensagem daria por exemplo que o digito (cvv) tá incorreto, a validade tá incorreta, numero do cartão ou outra coisa... Se tivessem esses dados na documentação seria ótimo para testarmos isso e poder retornar a informação correta para o usuário.

Muito obrigado.

Boa tarde, <@!809430559302352936>! No momento não, mas vou levar a sua sugestão para o backlog do nosso time de desenvolvimento.

@here Boa tarde pessoal só uma duvida, não temos api para cadastro de cliente?

Isso inclusive é quase obrigatório por causa do regulamento de segurança do SPB sobre poder dizer que um determinado contato está incluso ou isento do limite de 1000 reais à noite. E que vale também para TED e DOC.