Você está na página 1de 3

Delivery Próprio

Requisitos da versão 2.0


Loja Web · App Android · App iOS

1.0 – Cadastro de Cartões


1.1 Cadastro
O cartão será inicialmente cadastrado pelo Usuário com todas as informações no aplicativo. No
entanto, o objeto deverá ser convertido em um JWT (Json Web Token - framework) antes de
ser enviado para a API. Dessa forma, garantimos a segurança das informações enquanto são
trafegadas pela rede.
A data de validade terá o formato dd/mm/aaaa no campo.

1.2 Listagem
Uma vez cadastrado, o cartão será retornado pela API, mas de forma incompleta. Por exemplo,
o número do cartão virá apenas com os 4 últimos dígitos. Para que seja exibido na listagem de
cartões disponíveis do usuário. O Código de segurança (CVV) também não será informado.

No menu do aplicativo,deve ser criada uma aba para “Meus cartões”.


Nesta tela, o usuário poderá ver seus cartões, criar um novo cartão, editar ou excluir os já
cadastrados.
1.3 Edição
Na tela de edição, o usuário não poderá ver o número completo do cartão (como já vimos, ele
estará incompleto). Caso ele deseje alterar, todo o número do cartão deve ser informado
novamente, incluindo o código de segurança (CVV).
Novamente, o método de gravação será chamado, mas, desta vez, terá o Id informado, de
modo que a API saiberá qual cartão atualizar no banco de dados.

1.4 Exclusão
Apenas o Id será informado para a API, mas deve ser exibida uma mensagem de confirmação
antes da exclusão do Cartão: “Excluir o cartão _#Nome do cartão#_?” <Sim> <Não>.

2.0 – Nova Forma de Pagamento


2.1 Cartões na lista de Pagamentos do Pedido
O tipo do pagamento será 1 ou 2, conforme enum EPagamentoTipo (previamente definido).
Nos pagamentos, será informado o Id do Cartão, e não as informações completas.
Com isso, fica definido que todos os cartões utilizados no pagamento devem estar
devidamente cadastrados antes da utilização.

3.0 – Seleção de Cartões no Pagamento


Na tela de pagamento, teremos a listagem de cartões do usuário (0..*) e, ao final, a opção de cadastrar um novo
cartão, conforme segue exemplo:

4.0 – Novos retornos na gravação de pedido


No enum EPedidoProtocoloStatus será adicionado o item ppsPagamentoAguardandoProcessamento, que significa
que o pagamento é em cartão (crédito ou débito) e seu pagamento está sendo analisado.

Lembrando que o campo Mensagem, dentro do objeto de resposta, também conterá uma mensagem amigável
para o usuário, podendo ser exibida na tela em vez do aplicativo ter uma mensagem própria.

5.0 – Novos status de pedido


Na visualização do pedido, uma vez que o pagamento ainda está sendo analisado, teremos mais status:
5.1 psPagamentoPendente - Pagamento em análise;
5.2 psTransacaoNegada - Pagamento negado / Transação negada (limite excedido, cartão
bloqueado, etc);
5.3 psPagamentoCancelado – O dono do cartão cancelou o pagamento.

Será criado um serviço que analisará o status do pagamento a cada 1 (um) minuto, atualizando o status do
pedido, dependendo do resultado do pagamento.
6.0 Tokenização dos headers de segurança
Hoje, os headers
aders das requisições autenticadas (que requerem o usuário logado para serem realizadas), como o
cadastro de Cartões, Envio de Pedido, etc) estão separados.
Com a informação dos cartões, será necessário juntá
juntá-los
los em um único header contendo um JWT.
Todas ass requisições autenticadas deverão ser alteradas para esse novo header.

Mais informações sobre os modelos utilizados na API (como nomes de campos, estrutura do JSON, etc) estão
disponíveis na própria API e serão passados no início do desenvolvimento.

Você também pode gostar