RFC descrevendo o "Pix crédito", implementação levantada pelo challenge woovi, que propõe que usuários possam pagar utilizando Pix e Crédito em um único pagamento.
- organization: Fornecedor do Pix Crédito.
- seller: Usuário do Pix Crédito fornecido pela organization.
- client: Cliente do seller que irá efetuar o pagamento do Pix Crédito oferecido pela organization.
- Init Point: Link identificador de checkout retornado pela organization para que o pagamento de um client seja identificado.
- Seller controla a criação, expiração e cancelamento de um pagamento de seu client, a menos que o pagamento tenha um status diferente de PENDING.
- Assume-se que o seller pode definir um tempo para que seu client inicie o pagamento.
- Uma vez o pagamento sendo iniciado, o client terá 24 horas para finalizá-lo, ou o mesmo será cancelado.
- Assume-se os seguintes status para o pagamento: Pending, Processing, Canceled, Expired, Approved.
- O processo se inicia com o seller requisitando um init point para a organization.
- O payload pode incluir um tempo de expiração, o valor a ser cobrado e um identificador único personalizado para esse init point.
- A organization responde com um link para o checkout, que o seller envia para seu client.
- Dentro do perÃodo definido pelo seller, o client acessa o init point para iniciar o pagamento.
- A comunicação agora é entre client e organization através do init point para a segurança dos dados.
Estágio 1 - Pagamento da primeira parcela do Pix Crédito, efetuado em Pix.
- O init point faz a requisição para a organization para obter o Pix relacionado.
- Se o pagamento for bem-sucedido, o status é Processing.
- O client tem 24 horas para finalizar a segunda etapa, caso contrário, o pagamento será Canceled e o client receberá o estorno.
- Isso permite que o client possa reconsiderar a compra.
Estágio 2 - Segunda parte do pagamento dentro de 24 horas
- O init point solicita os dados da segunda parte do pagamento para a organization.
- O client envia os dados do cartão.
- Se a compra não for autorizada, o client terá retentativas dentro das 24 horas.
- Se falhar, o client recebe o estorno do Pix da etapa 1, e o pagamento é Canceled.
- Se bem-sucedido, o client é notificado e o pagamento é Approved.
- O seller é informado sobre o pagamento bem-sucedido pela organization.
- A partir desse ponto, o seller passa por um fluxo de pagamento de cartão, onde a organization decide sobre a antecipação do saldo e registra-o corretamente.
- É assumido um principio de funcionamento baseando-se na tecnologia(e suas nomenclaturas) conhecida por GraphQL.
- Sao assumidos os termos técnicos:
- Db como banco de dados.
- Amqp como sendo um serviço de messageria.
- Cache como um sistema de melhoria em performance no bando de dados.
- Worker como um sistema aalhador externo.
- Kubernetes sendo um executor de trabalho externo.
- É assumido o termo acessante como o úsuario humano(seller ou client) que interagem no sistema.
- É assumida uma entidade payment que sao os pagamentos feitos pelo client a um init point.
A api seria a forma aberta da organization se comunicar se comunicar com o seller e o init point. Através dela, a interface((Frontend)[#frontend]) pode se comunicar visualmente com o acessante.
Essa api teria rotas principais para que o seller e o init point criem, consumam e interjam com os dados. Por meio dela, seriam exportados os seguintes métodos.
-
Query:
- Seller(id): pegar os dados de um seller no db ou cache, junto aos seus init points criados, e os dados dos mesmos.
- InitPoint(id): pegar os dados atuais de um init point no cache ou banco.
-
Mutation:
- createSeller(id): cria um seller no sistema.
- createInitPoint(seller_id, value, expires_at): cria um init point dependente de um seller no sistema.
-
Webhook:
- updateInitPoint: essa é uma rota exclusiva do sistema, que faz com que açoes externas desencadeiem funções internas no sitema.
Se assume a funcionalidade de fazer o extorno de um pagamento a um worker, assim como monitoramento dos init points, atribuindo a eles os status de canceled e expired, quando elegiveis.
É o sistema que interage com o acessante. Por meio dele, um seller podera criar e monitorar seus init points, de forma privada e autenticada. Por meio dela, um init point pode ser acessado de forma pública, sendo reconhecida por seu identificador.
Como dito anteriormente:
Se assume a funcionalidade de fazer o extorno de um pagamento a um worker, assim como monitoramento dos init points, atribuindo a eles os status de canceled e expired, quando elegiveis.
Sendo assim, worker é um sistema externo que nao depende da api e init point diretamente, mas depende das dependencias gerais cache e db.
É natural que um sistema cresça em número de acessantes, por isso, definimos também uma forma de escalar o acesso a esses recursos. Sendo assim, prosseguimos.
Desacoplando o db da api e interagimos somente com o cache, toda vez que quisermos criar um conteúdo em db, chamaremos amqp.
Criamos um worker que se inscreve e interage com amqp de dentro de um Kubernetes. Por meio dele, consumiremos uma fila por meio de pacotes enviados ao db. O sistema de kubernetes ira se encarregar de criar novos workers para caso a demanda por interações no db aumente, assim como lidar com a destruiçao desses workers, caso nao sejam mais necessarios.
O kubernetes tambem ira lidar com a criaçao e destruiçao de apis conforme necessario. Criamos uma interface que sera a porta de entrada ao invés de uma instancia api diretamente, ela se encarregara de distribuir os pedidos dos acessantes entre as apis presentes no kubernetes. Iremos chamar essa interface de Load Balancer.
Iremos assumir o frontend como arquivos estaticos, que nao necessitam de escala por meio do sistema.
Dessa forma, passamos de um fluxo estatico:
accessante -> frontend -> api -> Cache | Db -> worker
Para um fluxo dinamico:
acessante -> frontend -> load balancer -> kubernetes.api[N -> Cache] -> amqp -> kubernetes.workers[N -> Cache | Db]