Descrição do bug 💣

Ao adicionar um produto avulso e uma assinatura no mesmo carrinho, o produto avulso é adicionado na assinatura com ciclo permanente.

Solução de contorno ⚠️

Não há solução para contorno.

Como reproduzir 👮

Acessando a loja do Magento com o Módulo Vindi instalado:

• Adicionar um produto de assinatura no carrinho;
• Adicionar um produto avulso no carrinho;
• Finalizar a compra utilizando um método de pagamento Vindi.

Comportamento atual

O produto avulso será adicionado na assinatura com ciclo permanente.

Comportamento esperado

Criar o produto avulso como apenas 1 ciclo.

Impacto do problema 💥

Clientes terão produtos avulsos cobrados como recorrentes.

Prioridade 📝

Normal:

• Funcionalidade não está operando conforme expectativa e especificação;

Proposta de correção ✔️

Não há uma proposta para correção.

Devemos verificar a possibilidade de segmentar os produtos pelo tipo, neste caso, caso o produto utilizado seja do tipo simples, enviamos o ciclo do produto na assinatura como 1, exemplo:

model/vindi/ProductManagement.php

Critérios de aceite

• Criar os produtos avulsos com apenas 1 ciclo se finalizada a compra junto a uma assinatura;

Descrição do bug 💣

Clientes criados via Magento não possuem telefone cadastrado, mesmo que o telefone seja informado no checkout.

Solução de contorno ⚠️

Não há. É necessário modificar o plugin.

Como reproduzir 👮

Apenas realize uma compra e informe um telefone nos campos do checkout.

Comportamento atual

O telefone não está sendo enviado para a Vindi

Comportamento esperado

O telefone deveria estar preenchido na Vindi

Impacto do problema 💥

Nenhum cliente possui telefone cadastrado na Vindi.

Prioridade 📝

Normal:

• Funcionalidade não está operando conforme expectativa e especificação;

Proposta de correção ✔️

A chamada do método está incorreta. Deveria ser algo como:

$customer->getDefaultShippingAddress()->getTelephone();

Critérios de aceite

• Deve ser possível criar clientes com telefone;

É possível realizar a verificação da Chave API ao tentar habilitar um método de pagamento da Vindi?

O objetivo, é não deixar o cliente habilitar os métodos (salvar), caso a chave API não esteja setada.
Desse modo, não é necessário validar $this->apiKey no request da API, pois caso não possua chave API, não irá chegar no request.

Descrição do bug 💣

Os campos do checkout no Magento 2 são preenchidos em linhas que é a forma que identificamos para segmentar o que cada linha significa exemplo: Linha 1 é para preenchimento da rua, linha 2 preenchimento do número, etc. O problema ocorre pois caso um dos campos não venha ser preenchido o próximo campo será populado na linha do campo que não foi preenchido, chegando incorretamente na Vindi.

Solução de contorno ⚠️

Solução para contorno seria deixar todos os campos com preenchimento obrigatório.

Como reproduzir 👮

Como exemplo poderá realizar o preenchimento do checkout preenchendo a rua e complemento deixando o número em branco.

Comportamento atual

O campo complemento será preenchido no lugar do número na Vindi

Comportamento esperado

Preencher os campos corretamente na Vindi.

Impacto do problema 💥

Cliente que utilizam boleto bancário não conseguirão emitir boleto pois é necessário ter todos os campos de endereço para registro, como os campos serão preenchidos indevidamente não será possível a emissão do boleto

Prioridade 📝

Normal:

• Funcionalidade não está operando conforme expectativa e especificação;

Proposta de correção ✔️

Os campos para preenchimento de endereço são capturados da seguinte forma:

Caso um dos campos não sejam preenchidos a linha que esperamos receber este campo será populada pelo próximo campo informado.

Acredito que a captura por linha no endereço de cobrança não seria o ideal pois não conseguimos mapear se o campo será preenchido ou não, impossibilitando qualquer validação do nosso lado.

Não encontrei uma proposta para correção.

ID ticket do problema: 162775

Critérios de aceite

• Preencher os campos corretamente na plataforma;

Descrição do bug 💣

Ao desabilitar a opção de parcelamento nas configurações de método de pagamento da Vindi não está sendo possível finalizar a compra.

Solução de contorno ⚠️

Permitir que o valor 1 seja atribuído na primeira validação, desta forma o mesmo estará disponível para visualização no dropdown:

Aparecerá desta forma no checkout:

Como reproduzir 👮

1. Desabilitar configurações de parcelamento no método de pagamento da Vindi no Magento.
2. Realizar uma compra utilizando método cartão de crédito

Comportamento atual

Na tentativa de finalização de compra há um alerta solicitando preenchimento do número de parcelas:

Comportamento esperado

Permitir que o cliente finalize compras com o parcelamento desabilitado.

Impacto do problema 💥

Cliente impossibilito de vender pois não utiliza como regra de negócios o parcelamento

Prioridade 📝

Alta:

• Cliente impossibilitado de vender e não existe solução de contorno;

Proposta de correção ✔️

Não há proposta para correção.

Critérios de aceite

• Permitir que o cliente realize vendas mesmo com o parcelamento desativado;

Descrição do bug 💣

Não é possível realizar compras com cartões da bandeira American Express.

Solução de contorno ⚠️

Não há. É necessário modificar o plugin.

Como reproduzir 👮

Tente realizar uma compra com um cartão Amex. Na inserção do CVV, não será possível prosseguir pois só será permitido colocar 3 dígitos.

Comportamento atual

O usuário é obrigado a preencher 3 dígitos no CVV para finalizar a compra.

Comportamento esperado

O usuário deveria poder preencher 4 dígitos de seu CVV para finalizar a compra.

Impacto do problema 💥

Nenhum cliente pode realizar compras com cartões Amex.

Prioridade 📝

Normal:

• Funcionalidade não está operando conforme expectativa e especificação;

Proposta de correção ✔️

Isso está ocorrendo pois não estamos utilizando a validação padrão de bandeiras do Magento e, por conta disso, ao chamar a class validate-card-cvv no checkout, essa validação sempre irá retornar false, ou seja, 3 dígitos para o CVV.

Precisamos adaptar o módulo para mandar o campo size do CVV da bandeira Amex.

Critérios de aceite

• Deve ser possível realizar compras com cartões Amex;

@leonardola não é possível realizar uma compra no ambiente de homologação erro 400 Bad request, sem o ambiente de homologação não poderemos aprovar as PRs

Referente ao PR #3

Vindi & Yapay offer Pix Payments, however this method is not currently available on the magento plugin and we would really like to have it available

Descreva o bug
Não consegui finalizar uma compra.

Como reproduzir
Passos para reprodução do comportamento:

1. Vá para checkout da loja
2. Click em finalizar
3. Veja erro: Invalid method Vindi\Payment\Model\Payment\Api::createCustomer

Comportamento Esperado
A compra deveria ser finalizada.

Prints de tela

Motivação

Deve ser possível ao cliente criar novo plano ou utilizar um já existente na Vindi (​endpoint plans : Planos)

Isso não está acontecendo hoje, o que limita o cliente a sempre criar um novo plano.

Solução proposta

Inserir a opção de selecionar o ID de planos já existentes na Vindi na criação/edição de produtos bundle Assinatura Vindi

Descrição
Testando o fluxo de compra no magento, o pagamento não está sendo confirmado através do webhook após o pedido ser criado. Acompanhando o 'debug.log' no momento da criação do pedido, verifiquei esse comportamento:
[2020-09-01 21:04:08] main.INFO: Webhook New Event!
{"event":{"type":"bill_paid","created_at":"2020-09-01T18:04:03.192-03:00","data":{"bill":...... (continuacao do array)
[2020-09-01 21:04:08] main.ERROR: Warning: array_key_exists() expects parameter 2 to be array, null given in vendor/vindi/vindi-magento2/Helper/WebHookHandlers/BillPaid.php on line 55 [] []
Quando o subscription vem null, esse erro é disparado e imagino que a execução esteja interrompendo, pois não há o registro da fatura e nem dos logs dos metodos seguintes.

Como reproduzir
Com o módulo configurado, fazer uma compra como cliente comum e o pedido não é confirmado pelo webhook.

Comportamento Esperado
A compra com cartão de crédito ser confirmada após a criação do pedido.

• Magento [2.3.4]
• PHP [7.1]

Eu consegui resolver adicionando mais uma condição ao primeiro if do metodo helper/WebHookHandlers/BillPaid::billPaid($data) linha 42 is_array($data['bill']['subscription'])
Não sei se é a melhor solução, mas segue sugestão.

A validação dos dados do cliente, verifica se o cliente já existe na Vindi, utilizando os dados já cadastrados.

No caso do cliente alterar algum dado, o mesmo não é refletido na Vindi, por não possuir o método PUT.

Deve ser inserido um método para alteração dos dados do cliente para contornar esse processo.

Países permitidos todos por default e retirar o seletor de países no modo de pagamento, porque isso deveria de ser na configuração do modulo em si.

Descrição do bug 💣

Ao gerar um pedido através do painel administrativo do Magento selecionando o método cartão de crédito ocorre o seguinte erro:

Solução de contorno ⚠️

Cliente está gerando a fatura no método boleto bancário e alterando manualmente para cartão de crédito através da plataforma.

Como reproduzir 👮

Acessando o painel administrativo do Magento 2:

• Acessar Clientes -> Todos os clientes;
• Selecionar um cliente
• Selecionar a opção Criar pedido;
• Na finalização da criação do pedido, selecionar o método de pagamento Vindi - Cartão de crédito.

Comportamento atual

Ocorre erro que impossibilita a criação do pedido.

Comportamento esperado

Permitir que o cliente gere a cobrança no método cartão de crédito;

Impacto do problema 💥

Cliente não consegue gerar vendas no método cartão de crédito através do painel admin do Magento.

Prioridade 📝

Normal:

• Funcionalidade não está operando conforme expectativa e especificação;

Proposta de correção ✔️

Não há uma proposta para correção.

O problema ocorre pois o parâmetro solicitado no método getCcTypeFullName(ccType) está vazio quando o pedido é criado pelo painel admin:

Critérios de aceite

Informe os critérios de aceite para esse bug

• Permitir a criação de pedido no método cartão de crédito;

O valor do frete não está sendo enviado, gerando uma inconsistência entre Magento > Vindi.

Realizar ajuste na lista "hard coded" das bandeiras de cartão de crédito

A URL dos Webhooks deve ser exibida em modo Somente Leitura na pagina de configurações do módulo;

Ex:
{$this->url}vindiPayment/index/webhook?key={$webhook_token}

https://mysite.com/vindiPayment/index/webhook?key=aBcDeFgH123

Essa função pode nos gerar problemas no tratamento dos Webhooks, eu removi ela no Magento 1, porque o Magento já tinha uma validação no próprio Checkout;

It is common practice for subscription companies to discount and trial their services during a grace period. In Magent 2 we can do this with vouchers. However, in Vindi, this discount becomes a lifetime discount if we do not treat it. It would be great if the discount can be temporary (or even configurable) so as to follow best practices.

Os campos Endpoint da Api e Sandbox possuem a mesma função?

É exaustivo ter que digitar corretamente o endpoint da API, principalmente para o usuário final;

Podemos seguir o padrão do módulo 1 e transformar as opções atual em 'Modo' com as alternativas (Sandbox e Produção) e a URL ser alterada automaticamente no backend?

Descreva o bug
Após uma tentativa de compra com o retorno de suspeita de fraude (fraud review) ou com revisão de fatura (review). O módulo está setando o pedido para o status personalizado (StatusToOrderComplete);
No entanto, esses retornos devem possuir um tratamento semelhante ao Boleto bancário, onde o pedido no Magento ficará pendente (pending) até a confirmação de pagamento via Vindi.

Como reproduzir

1. Habilitar a aprovação manual de faturas na Vindi
   
2. Tentar realizar uma nova compra
3. O pedido irá receber o status processing

Comportamento Esperado
O pedido deve receber o status pending

Contexto adicional
Tentei realizar alguns testes porém por algum motivo o magento cria a Invoice logo após a conclusão do pedido. Impossibilitando a alteração somente via Webhook 🤷‍♂️
Ex:

    public function afterPlace(Payment $subject, $result)
    {
        $this->pendingStatus($subject);
        return $result;
    }

Irá funcionar da maneira esperada (durante a criação do pedido). Porém, ao receber o Webhook de bill_paid estou recebendo o erro de que não foi possível gerar uma invoice para o pedido.
Acredito ser justamente porque o pedido já tem uma invoice gerada.

Criar um PR para colocar o módulo na estrutura composer de instalação

Descrição do bug 💣

Clientes utilizando parcelamento não estão tendo o valor do frete sendo calculado no plugin. Apenas o valor total do carrinho, sem a inclusão do frete.

Solução de contorno ⚠️

Não há. É necessário modificar o plugin.

Como reproduzir 👮

Realize uma compra com frete e parcelamento habilitado no plugin.

Valor de parcelas:

Comportamento atual

O valor do frete não é somado no parcelamento

Comportamento esperado

O valor do frete deveria ser somado no parcelamento.

Impacto do problema 💥

Nenhum cliente consegue realizar o parcelamento corretamente.

Prioridade 📝

Normal:

• Funcionalidade não está operando conforme expectativa e especificação;

Proposta de correção ✔️

A função getInstallments() não possui uma chamada para receber o frete. Deveria estar dessa forma:

$total = $quote->getGrandTotal() + $order->getTaxAmount();

Critérios de aceite

• O parcelamento de compras deve incluir fretes;

Motivação

O status da ordem será marcado como processando sempre que um novo ciclo de pagamento seja feito.

Isso não acontece hoje, o status é alterado após o primeiro pagamento, e nunca mais é alterado.
Isso é problemático pois o Magento não está refletindo (nas Orders) como as Assinaturas estão na Vindi.

Solução proposta

No caso de cancelamento de Assinatura a Order deve ser atualizada para Cancelada, e o status Processing se refere a um status de pagamento, então, a Order só pode possuir esse status caso o pagamento tenha acontecido.

Motivação

Deve ser permitida a troca do método de pagamento entre as escolhas já presentes no perfil de pagamento do cliente.

Estão sendo exibidos perfis que não podem ser utilizados para novas compras.

Solução proposta

A query tem que ser feita filtrando os perfis de pagamento com status ativo.

Criar documentação com os detalhes do método upgrade da classe UpgradeData e metodo upgrade da classe UpgradeSchema

public function upgrade(
        ModuleDataSetupInterface $setup,
        ModuleContextInterface $context
    ) {
        if (version_compare($context->getVersion(), "1.0.0", "<")) {
            //Your upgrade script
        }
    }

Motivação

Deve existir uma lista de assinaturas provenientes da API com persistência no Magento.

Atualmente estão sendo consultadas as primeiras 50 assinaturas da Vindi.

Solução proposta

Deve ser feita uma paginação com a quantidade máxima por página de 50.

A classe API não deve possuir nenhuma responsabilidade além de realizar requisições!

Os métodos relacionados a entidades específicas devem ser movidos (ex: createCustomer/Bill...)

Motivação

Em caso de rejeição de pagamento no início da assinatura a fatura está sendo cancelada, porém a assinatura também deve ser cancelada.

Solução proposta

Uma ação possível é ao invés de chamar o endpoint DELETE em bills.
Chamando o método DELETE em subscriptions passando o parâmetro cancel_bills com o valor true

Descreva o bug
O Magento 2.3 está reconhecendo como um caminho errado ao enviar o email, isso também acontece ao fazer a compra pela loja. O processo com o Vindi funciona perfeitamente, só existe o detalhe de enviar o email com a informação esperada

Como reproduzir
Passos para reprodução do comportamento:

1. Vá para 'Vendas->Pedidos->View Pedido'
2. Click em 'Enviar e-mail'
3. Veja erro
   Invalid template file: 'Vindi_Payment::info/cc.phtml' in module: 'Vindi_Payment' block's name: 'info\cc_0'

Comportamento Esperado
Ao clicar, o sistema deve enviar o email com as informações esperadas para esse modelo.

Prints de tela

Desktop (favor completar as seguintes informações):

• OS: Linux Mint, Windows, OS
• Browser Firefox, Google Chrome
• Magento 2.3
• PHP 7.1

Poderia destacar mais o endereço de URL com cor diferente, negrito algo que o usuário não tera duvidas o que realizar com ele

Motivação

Foram relatadas falhas ao tentar realizar a compra utilizando produtos que o tipo seja diferente de 'Simples'.
Desse modo, iremos realizar uma validação para garantir a compatibilidade com os tipos de produtos existentes no Magento 2 atualmente, ou remover a possibilidade de utilizar produtos não suportados.

Os tipos disponíveis são:

Produto simples:

É o mais básico dos produtos, que pode ser usado inclusive pra formar os dois tipos seguintes; corresponde a um produto específico, com suas características únicas. Por exemplo, caneta esferográfica cor vermelha, com tampa

Produto agrupado:

Usado quando se deseja dar opções ao cliente, de modo que ele possa comprar mais de um produto. Por exemplo, canetas esferográficas, com tampa, nas cores vermelha (produto simples), azul (outro produto simples) e preta (mais um produto simples)

Produto configurável:

Usado quando se quer consolidar um mesmo tipo de produto em um só, dando ao cliente a escolha por um só tipo. Por exemplo, camisetas brancas com estampa do Tux (produto configurável), nos tamanhos P (um produto simples), M (outro), G (outro) e GG (mais um produto simples)

Produto virtual:

Está relacionado a serviços, ou seja, produtos que não existem fisicamente e não são enviados para o cliente. Por exemplo, instalação do software em servidor ou horas de assistência técnica online

Produtos para download:

Referem-se a arquivos que serão baixados pelo cliente após a confirmação de pagamento. Por exemplo, e-books

Pacotes de produtos:

São kits, compostos por produtos simples, de maneira que o cliente possa montar o seu produto. Por exemplo, um computador, composto por processador, placa-mãe, discos rígidos, teclado, mouse, leitor de DVD e assim por diante

Critérios de aceite

O módulo deverá reconhecer os tipos de produtos configurados como:

• Simple Product
• Configurable Product
• Grouped Product
• Downloadable Product
• Virtual Product
• Bundle Product

As configurações do módulo estão inseridas dentro dos Métodos de Pagamento!

Os métodos devem exibir apenas configurações de métodos na Vindi.
Ex:

• ajuste de parcelas
• transação de verificação
• habilitar/desabiltar

O menu próprio deve disponibilizar as configurações do módulo Vindi.
Ex:

• habilitar/desabilitar
• chave API
• sandbox/production
• url webhook