Resumo

criar documentação de exemplos para os métodos do BankAccountWrapper.

A criação de conta bancária está relacionada ao #31

Tarefas

• Criar exemplos
• Criar documentação

Resumo

Precisamos enviar alguns documentos para validar os vendedores.

Tarefas

• estudar os endpoints da zoop
• criar métodos de envio de documento
• criar exemplos

utilizar como referência
https://raw.githubusercontent.com/PokeAPI/pokeapi/master/README.md

• Criar exemplos
• Criar documentação

adicionar ZoopWrapperResponse stub com:

• instance
• instances
• data

Resumo

Precisamos ter o estorno de transação.

Dados mágicos

existe uma mágica transação de id 720ba7a640564c229437f0644cdf37fe que precisamos estornar.

ela está em PROD

Critérios de aceite

• fazer o estorno dessa transação mágica
• terminar o cancel_transaction
• fazer os testes desse método

• Criar exemplos
• Criar documentação

• Criar exemplos
• Criar documentação

Resumo

Atualmente o CONTRIBUTING.md está sugerindo que se use make config, não existe essa regra no make. Assim como não existe a regra make config.data.

Além disso, tem-se o problema de mistura entre inglês e português.

Critérios de aceite

• documentar de forma coerente com os comandos presentes no makefile;
• traduzir o resto do arquivo;
• no comando docker run -it usar a forma longa das flags -i = --interactive e -t = --tty e ordena-las alfabeticamente.

Resumo

Existe a flag capture para controlar a captura automática.

Tarefa

• adicionar o input capture no required_fields

Resumo

Existe o installment_plan na zoop!

https://docs.zoop.co/reference#post_v1-marketplaces-marketplace-id-transactions

O zoop-wrapper precisa ter suporte à isso!

Tarefas

• alterar models/wrappers caso seja necessário para adicionar suporte à esse atributo
• criar exemplos de transação de cartão parceladas (tanto presente quanto não presente)
• criar testes se for necessário alterar

Resumo

A zoop possui eventos de transação! Já temos uma lista com eles!

O Felipe Lavra ficou de me enviar vários payloads de exemplos de transação. Para serem utilizados como referência.

Descrição

Não utilizar os eventos de transação:

"transaction.authorization.failed",      
"transaction.authorization.succeeded",

Eles não funcionam!

Deve ser utilizado os eventos:

"transaction.failed",      
"transaction.succeeded",
transaction.canceled
transaction.capture.failed
transaction.capture.succeeded
transaction.created
transaction.failed
transaction.void.failed
transaction.void.succeeded

Tarefas

• adicionar documentação sobre eventos de transação da zoop
• alterar lista de eventos
• adicionar exemplos de eventos de transação

Resumo

Relacionado ao issue #101

Pode ser mais interessante installment_plan ir dentro do source do cartão. Para deixar uma interface mais homogênea no imopay!

Tarefas

• mudar o campo/objeto installment_plan para dentro do source
• testar
• alterar os exemplo e rodá-los

Nosso pacote pypi está com português como Natural Language e nosso README está em português.

Mas nossa documentação de código está em inglês.

Resumo

Relacionado aos issues:

• #32

Temos contas bancárias com dados inválidos no nosso ambiente de teste. Possui um cnpj no campo taxpayer_id, isso quebra o zoop-wrapper.

Precisamos ter suporte à deleção.

Tarefa

• implementar a ação remove_bank_account
• criar exemplo de utilização
• criar documentação

remove_bank_account

https://docs.zoop.co/reference#delete_v1-marketplaces-marketplace-id-bank-accounts-bank-account-id

https://docs.python.org/3/library/dataclasses.html

Resumo

Após um longo processo de troubleshoot foi possível identificar que o problema de erro na Zoop ocorre, até o presente momento, apenas na atualização de empresas que não tem endereço cadastrado.

Detalhes

Conforme @rodrigondec solicitou, disponibilizando dados relevantes a reprodução do erro com a Zoop.

Payload utilizado para reproduzir o erro de update de empresa na Zoop:

{
    "business_email": "foo",
    "ein": "64070465954529",
    "business_name": "foo",
    "business_phone": "foo",
    "business_opening_date": "foo",
    "business_website": "foo"
}

Note que o id no fim da URL foi obtido rodando primeiro o exemplo add_business_seller.py, obteu-se assim o id utilizado neste exemplo (diretamente do .json de retorno do exemplo).

Mensagem de erro obtida:

{
'status': 'Bad Request', 
'status_code': 400, 
'type': 'invalid_request_error', 
'category': 'missing_required_param', 
'message': 'Missing required param: address - line 1. Please verify request parameters.'
}

• Deixar todos os badges do pypi na primeira linha
• Deixar todos os badges do github na segunda linha
• Deixar badges do codacy na última linha com o snyk

Resumo

O exemplo de remover a conta bancária de um vendedor não está incluindo o arquivo .py, o nome esta errado, por isso não está sendo incluido.

Imagens

Tarefas

• Corrigir o nome do arquivo na linha .. literalinclude:: ../../examples/bank_account/bank_account_delete.py do arquivo docs/examples/bank_account.rst para bank_account_remove.py.

Resumo

precisamos criar os exemplos.py do CardWrapper.

Critério de aceite

Criar os exemplos de add_card e retrieve_card.

Adicionar na documentação (pasta docs) esse exemplo.

estudar sobre transferência na documentação oficial da zoop

• Criar models
• Criar métodos no wrapper
• Criar testes
• Criar exemplos
• Criar documentação

Resumo

Atualmente a declaração de inicialização está pegando o ZoopBase.__init__ que só tem o **kwargs.

Critério de aceite

Modificar os stubs de cada resource para mostrar os atributos possíveis a serem recebidos no __init__

O logging.BasicConfig sobreescreve as configurações de log dos projetos que utilizam o zoop_wrapper.

Resumo

A maioria dos testes de wrapper não testam muita coisa.

Todos os testes do wrapper deveriam estar semelhantes ao

Esse teste realmente verifica se foi chamado um PUT com url, payload e auth corretos.

Tarefas

• implementar esse estilo de teste em todos os testes do wrapper

Resumo

No nosso README tem um badge que não existe mais. Precisamos removê-lo

copiar parâmetros e extensões do requests

https://github.com/psf/requests/blob/master/docs/conf.py

Rodar a validação de cpf/cnpj pois a API da Zoop é PÉSSIMA!

Quando é um cpf inválido ela retorna uma resosta 200 ok com um dict de ERRO!!!!

Além disso fazer gambiarra para alterar o status_code da resposta para ser levantado um HttpError.

Resumo

Nossos testes de conjuntos estão testando apenas o conjuto de dados hard-coded.
Porém não testam a chamada do método super corretamente.

Tarefas

• Buyer
• BusinessOrIndividual
• Card
• Invoice
• Transaction
• PaymentMethod
• Token
• Seller

Exemplo

Método

    @classmethod
    def get_required_fields(cls):
        fields = super().get_required_fields()
        return fields.union({"expiration_date", "payment_limit_date"})

Teste

    def test_required_fields(self):
        self.assertIsSubSet(
            {"expiration_date", "payment_limit_date"}, Invoice.get_required_fields()
        )

Proposta para o teste

    def test_required_fields(self):
        with patch("caminho.do.import.do.objeto.pai.ObjetoPai.get_required_fields") as mocked_super:
            mocked_super.return_value = set()
            self.assertIsSubSet(
                {"expiration_date", "payment_limit_date"}, Invoice.get_required_fields()
            )
            mocked_super.assert_called_once()

Resumo

A zoop não tem restrição de unicidade no cpf nem email

Adendo

Isso foi testado no ambiente de teste e produção

Cenário

Dado que existe um cliente X que possui CPF Y na zoop
Quando for cadastrado cliente z que possui CPF Y na zoop
Então a zoop cadastra outro seller com o mesmo cpf.

Problema

O método search_individual_seller não está funcionando

• alterar o readme.md para readme.rst
• seguir o exemplo do sphinx_rtd_theme

Resumo

É necessário que o zoop-wrapper tenha suporte à atualização de Buyer's.

Direcionamento

Utilizar o wrapper.seller.update_seller como referência.

Tarefas

• Adicionar método
• Teste do método
• Documentação da ação

Resumo

A zoop possui webhooks!

https://docs.zoop.co/docs/sobre-os-webhooks
https://docs.zoop.co/docs/eventos-dispon%C3%ADveis

Tarefas

• criar o model zoop_wrapper.models.event.Event
• criar o wrapper zoop_wrapper.wrappers.webhook.WebhookWrapper
• cenários de teste

zoop_wrapper.models.event.Event

https://docs.zoop.co/docs/sobre-os-webhooks#corpo-de-um-evento

Eventos são como comunicação assíncrona são feitas. Precisamos ter o model Event. Ele precisa ter:

• lista de possíveis eventos
• payload sendo transformado em um outro Model (?)

zoop_wrapper.wrappers.webhook.WebhookWrapper

create

Precisa ter o método de criação de um webhook. Que faz um POST corretamente na url da zoop.

update

Precisa ter o método de atualização de um webhook. Que faz um PATCH/PUT corretamente na url da zoop.

retrieve/search

Precisa ter o método de retrieve/search de um webhook. Que faz um GET corretamente na url da zoop.

Resumo

a função ZoopObject.from_dict não está validando o argumento recebido.

Critério de aceite

Se for enviado qualquer coisa que não seja um dict no arg data deverá estourar um ValidationError.

• Criar exemplos
• Criar documentação

Resumo

É possível remover um cartão.

https://docs.zoop.co/reference#delete_v1-marketplaces-marketplace-id-cards-card-id

Tarefa

• adicionar método remove_card no CardWrapper
• testar método
• adicionar exemplo
• adicionar exemplo na documentação

Resumo

A zoop retorna um erro muito bizarro de cartão de crédito.

Input de exemplo

{
	'customer': '8135bacf678842d18d71f1198377402f', 
	'payment_type': 'credit', 
	'on_behalf_of': '25037b2978b14e7fa5b902d9322e8426', 
	'description': 'Imobanco - Pedido no cartão de crédito', 
	'currency': 'BRL', 
	'capture': True, 
	'source': {
		'amount': 5400, 
		'usage': 'single_use', 
		'card': {
			'card_number': '1234123412341234', 
			'expiration_month': '12', 
			'expiration_year': '2023',
			'holder_name': 'abcde fghij',
			'security_code': '123'
		}
	}
}

Erro retornado

Sorry, the card (id: 661321d604d5484d845a44ba3b1c2b74) you are trying to use does not exist or has been deleted

Tarefa

• Fazer uma validação do card_number na criação do token

O que acontece se for passado errado algo aqui, especialmente se for algo trocado, digo onde era para passar um CNPJ for passado um CPF válido? O pycpfcnpj vai detectar, ou algo irá detectar? Ou só lá na api da Zoop que vai dar o erro? Posso esta falando besteira, ou isso pode vir a ser um bug bem chato de achar caso ocorra.

#54 (comment)

Originally posted by @PedroRegisPOAR in #54

• Criar exemplos
• Criar documentação

Resumo

A zoop possui Transação documentação oficial da zoop.

Descrição

A transação utiliza um 'objeto' nesteado chamado Payment Method.

O Payment Method 'boleto' já está funcionando.

Já existe o objeto PaymentMethod nos models.

Precisa testar e criar uma transação com o Payment Method 'credit_card'.

Cartão presente vs cartão não presente

Já temos o 'suporte' à cartão não presente. Que é justamente o fluxo de adicionar um cartão e utilizar o cartão já cadastrado na zoop para a transação.

documentação de cartão não presente/tokenizado

Porém me recordo de algo sobre ser utilizado um cartão 'on the fly' na transação.

documentação de cartão presente/'on the fly'

Source

Exist um objeto Source nesteado em transaction. Deverá ser criado o model para ele com os atributos do exemplo.

O Source herda de ZoopObject, por ele não ter nenhum atributo.

O source terá 'tipo dinâmico'. Ou seja, ele é um source do tipo 'cartão presente' ou então do tipo 'cartão tokenizado'.

Isso irá ditar quais são os atributos required.

Atributos

• type
• card
• usage
• currency
• amount

Tipos de cartão

Cartão não presente

Exemplo de dados

"source": {
    "type": "card",
    "card": {
      "id": "8c795953db6342be9fc14a36d5308bed"
    }
  },

Conjunto do get_all_fields

{'type', 'card'}

Conjunto do get_validation_fields

como não temos outros valores para saber se tem algum outro campo 'não obrigatório' deduzimos que todos os campos são necessários

{'type', 'card'}

Tipo cartão presente

Exemplo de dados

"source":{
      "usage":"single_use",
      "card":{
         "holder_name":"JOAO SILVA",
         "expiration_month":"9",
         "expiration_year":"2027",
         "card_number":"4539003370725497",
         "security_code":"123"
      },
      "currency":"BRL",
      "type":"card",
      "amount":7
   },

Conjunto do get_all_fields

{'type', 'card', 'currency', 'usage', 'amount'}

Conjunto do get_validation_fields

como não temos outros valores para saber se tem algum outro campo 'não obrigatório' deduzimos que todos os campos são necessários

{'type', 'card', 'currency', 'usage', 'amount'}

Transaction

A transação possui tipos dinâmicos.

O tipo dinâmico é identificado a partir do atributo obrigatório payment_type.

conjunto get_required_fields

Esses campos são iguais para os dois tipos dinâmicos

{
   "amount",
   "currency",
   "description",
   "on_behalf_of",
   "payment_type"
} 

Tipo credit

Esse é o tipo do cartão.

https://docs.zoop.co/docs/cobrando-cart%C3%B5es-tokenizados

conjunto do get_all_fields

{
  "source", 
} 
+ conjunto de `get_required_fields` +
+ conjunto de `get_non_required_fields`

conjunto do get_validation_fields

{
  "source", 
} 
+ conjunto de `get_required_fields`

Tipo boleto

Esse é o tipo do boleto.

https://docs.zoop.co/docs/gerando-um-boleto

conjunto do get_all_fields

{
  "payment_method", 
} 
+ conjunto de `get_required_fields` +
+ conjunto de `get_non_required_fields`

conjunto do get_validation_fields

{
  "payment_method", 
} 
+ conjunto de `get_required_fields`

Tarefas

• Estudar os campos de uma transação de cartão de crédito
  • Transação com cartão não presente
  • Transação com cartão presente
• Criar Model Source
• Alterar o model Transaction para ter o atributo source
  • Não quebrar o invoice
  • Identificar dinamicamente quando é um invoice e quando é um card utilizando algum atributo distinto
    • Fazer construção dos campos required a partir do tipo identificado dinamicamente
• Criar testes
  • Para os models
  • Para o wrapper de transação card
• Criar exemplos
• Criar documentação

Resumo

temos alguns misses no nosso coverage.

Models

Base

BankAccount

Seller

Token

Wrapper

Base

BankAccount

Card

Invoice

Seller

Transaction

Resumo

Os stubs não estão sendo carregados na instalação do pacote.

Referências

https://www.python.org/dev/peps/pep-0561/#id18

https://blog.ian.stapletoncordas.co/2019/02/distributing-python-libraries-with-type-annotations.html

Tarefas

• Estudar referências
• Configurar stubs no pacote
• Testar instalação local para ver o type hint