105.dados_dos_clientes

Objetivo

Proteger os dados sensíveis dos nossos clientes.

Necessidades

Armazenar o documento do cliente de maneira criptografada.

Restrições

• Não deve ser possível identificar o documento do cliente na base de dados.

Resultado Esperado

• O documento deve ser armazenado criptografado no banco de dados.

100.rodando_prometheus

Necessidades

Configurar os endpoints para a coleta de métricas no prometheus e fazer com que o prometheus colete sua métrica.

Resultado Esperado

Métricas armazenadas no Prometheus. Consultar via interface gráfica

095.falhar_nas_chamadas

Necessidades

Repassar headers requeridos pelo padrão OpenTracing para todas as interações entre serviços, via HTTP Headers.

Resultado Esperado

Informações sobre tracing presente em todas as requisições.

090.associacao_samsung_pay

Objetivo

Realizar a inclusão do nosso cartão na carteira digital Samsung Pay.

Necessidades

O portador do cartão deseja associar seu cartão a carteira digital do Samsung Pay, para isso será necessário consumir a API
do sistema bancário.

Temos uma API específica para cadastrar a carteira digital, vamos analisá-la?

http://localhost:8888/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/

Restrições

Devemos criar uma API com as seguintes restrições:

• O identificador do cartão é obrigatório e deve ser informado na URL (path parameter).
• O email é obrigatório, ou seja, não pode ser nulo, vazio ou inválido.

Resultado Esperado

• A carteira deve estar armazenada no sistema, com um identificador gerado pelo sistema.
• Retornar 201 com Header Location preenchido com a URL da carteira em caso de sucesso.
  • Quando o sistema bancário retornar sucesso (status code na faixa 200) a carteira deve ser armazenada no sistema.
  • Quando o sistema bancário retornar erro (status code na faixa 400 ou 500) a carteira não deve ser armazenada no sistema.
• Retornar 400 quando violado alguma das restrições.
• Retornar 404 quando o cartão não for encontrado.

085.associacao_paypal

Objetivo

Realizar a inclusão do nosso cartão na carteira digital Paypal.

Necessidades

O portador do cartão deseja associar seu cartão à carteira digital do Paypal, para isso será necessário consumir a API
do sistema bancário.

Temos uma API específica para cadastrar a carteira digital, vamos analisá-la?

http://localhost:8888/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/

Restrições

Devemos criar uma API com as seguintes restrições:

• O identificador do cartão é obrigatório e deve ser informado na URL (path parameter).
• O email é obrigatório, ou seja, não pode ser nulo, vazio ou inválido.
• O mesmo cartão não pode ser associado mais de uma vez a mesma carteira digital, no caso aqui o Paypal.

Resultado Esperado

• A carteira deve estar armazenada no sistema, com um identificador gerado pelo sistema.
• Retornar 201 com Header Location preenchido com a URL da carteira em caso de sucesso.
  • Quando o sistema bancário retornar sucesso (status code na faixa 200) a carteira deve ser armazenada no sistema.
  • Quando o sistema bancário retornar erro (status code na faixa 400 ou 500) a carteira não deve ser armazenada no sistema.
• Retornar 400 quando violado alguma das restrições.
• Retornar 404 quando o cartão não for encontrado.
• Retornar 422 no caso de tentativa de associação de um cartão que já era associado com a carteira

080.notificando_sistema_bancario_viagem

Objetivo

O sistema bancário precisa ser notificado que foi realizada uma notificação de aviso de viagem.

Necessidades

Realizar a confirmação da notificação do aviso de viagem para o sistema bancário. A chamada deve ser realizada para o
sistema de accounts (cards).

Temos uma API específica para notificar o sistema bancário sobre o aviso de viagem, vamos analisá-la?

http://localhost:8888/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/

Restrições

• O identificador do cartão é obrigatório e deve ser informado na URL (path parameter).
• O destino da viagem é obrigatório, ou seja, não pode ser nulo ou vazio.
• A data de validade da viagem é obrigatória, ou seja, não pode ser nulo ou uma data antiga.

Resultado Esperado

• Quando o sistema bancário retornar sucesso (status code na faixa 200) o aviso deve ser armazenado no sistema.
• Quando o sistema bancário retornar erro (status code na faixa 400 ou 500) o aviso de viagem não deve ser armazenado no sistema.

075.aviso_viagem

Objetivo

Cadastrar um aviso de viagem para o cartão.

Necessidades

O portador do cartão pode realizar uma notificação para o banco, dizendo que pretende utilizar o cartão em um
determinado destino, isso ajuda o banco no controle das fraudes.

• Informar o identificador do cartão.
• Informar o destino da viagem.
• Informar a data do término da viagem.
• Armazenar o instante do aviso de viagem.
• Armazenar o IP do cliente que fez a requisição.
• Armazenar o User Agent do cliente que fez a requisição.

Restrições

• O identificador do cartão é obrigatório e deve ser informado na URL (path parameter).
• O destino da viagem é obrigatório, ou seja, não pode ser nulo ou vazio.
• A data do término da viagem é obrigatória, ou seja, não pode ser nulo ou uma data antiga.

Resultado Esperado

• O aviso de viagem deve estar armazenado no sistema, com um identificador gerado pelo sistema.
• Retornar 200 em caso de sucesso.
• Retornar 400 quando violado alguma das restrições.
• Retornar 404 quando o cartão não for encontrado.

065.como_saber_tudo_funcionando_corretamente

Necessidades

Precisamos criar um endpoint HTTP REST para "mostrar" a métrica da instância para um serviço externo de armazenamento
de métrica. Vamos usar o formato do Prometheus que é o padrão da Cloud Native Computing Foundation.

Resultado Esperado

Endpoint com métricas expostas para uma futura coleta.

060.notificando_legado_cartao

Objetivo

Precisamos notificar o sistema legado do banco, que houve um bloqueio no cartão. Para que de fato o cartão esteja
bloqueado em todos os canais de venda.

Necessidades

Notificar o sistema bancário que o usuário solicitou o bloqueio do cartão a fim de garantir o bloqueio em todos os
canais de utilização do mesmo.

Temos uma API específica para notificar o sistema bancário sobre o bloqueio do cartão, vamos analisá-la?

http://localhost:8888/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/

Restrições

O identificador do cartão é obrigatório.

Resultado Esperado

• Quando o retorno do sistema bancário retornar sucesso (status code na faixa 200) devemos alterar o estado do cartão para "BLOQUEADO".
• Quando o retorno do sistema bancário retornar erro (status code na faixa 400 ou 500) não devemos alterar o estado do cartão.

055.bloqueio_cartao

Objetivo

Realizar o bloqueio do cartão.

Necessidades

O usuário do cartão pode realizar o bloqueio do cartão por alguma suspeita de fraude.

• Informar o identificador do cartão a ser bloqueado.

• Armazenar o instante do bloqueio.

• Armazenar o IP do cliente que fez a requisição.

• Armazenar o User Agent do cliente que fez a requisição.

Restrições

• O identificador do cartão é obrigatório e deve ser informado na URL (path parameter).

• Caso o cartão esteja já bloqueado devemos retornar um erro de negócio.

Resultado Esperado

• Bloqueio deve estar armazenada no sistema, com um identificador gerado pelo sistema.

• Retornar 200 quando o bloqueio em caso de sucesso.

• Retornar 400 quando violado alguma das restrições.

• Retornar 422 quando violado alguma regra de negócio.

• Retornar 404 quando o cartão não for encontrado.