{"id":13573764,"url":"https://github.com/jeffque/pix-credito","last_synced_at":"2026-03-07T07:32:38.300Z","repository":{"id":71333427,"uuid":"507774734","full_name":"jeffque/pix-credito","owner":"jeffque","description":"Um esboço do que seria a arquitetura do Pix Crédito","archived":false,"fork":false,"pushed_at":"2022-06-27T07:56:26.000Z","size":4,"stargazers_count":11,"open_issues_count":1,"forks_count":0,"subscribers_count":3,"default_branch":"main","last_synced_at":"2026-01-13T20:37:16.036Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jeffque.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-06-27T05:29:55.000Z","updated_at":"2024-08-09T18:11:53.000Z","dependencies_parsed_at":"2023-06-05T06:00:39.531Z","dependency_job_id":null,"html_url":"https://github.com/jeffque/pix-credito","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/jeffque/pix-credito","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jeffque%2Fpix-credito","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jeffque%2Fpix-credito/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jeffque%2Fpix-credito/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jeffque%2Fpix-credito/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jeffque","download_url":"https://codeload.github.com/jeffque/pix-credito/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jeffque%2Fpix-credito/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30209731,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-07T05:23:27.321Z","status":"ssl_error","status_checked_at":"2026-03-07T05:00:17.256Z","response_time":53,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T15:00:40.914Z","updated_at":"2026-03-07T07:32:38.281Z","avatar_url":"https://github.com/jeffque.png","language":null,"funding_links":[],"categories":["Challenges Pix Architecture"],"sub_categories":[],"readme":"# Pix crédito\n\nUm esboço do que seria a arquitetura do Pix Crédito.\n\n# Índice\n\n- [Personas](#personas)\n- [Uso do Pix Crédito](#uso-do-pix-crédito)\n  - [Uso do crédito](#uso-do-crédito)\n  - [Pagamento da fatura](#pagamento-da-fatura)\n  - [Saque do dinheiro](#saque-do-dinheiro)\n- [Aprovação de crédito](#aprovação-de-crédito)\n- [Riscos para a _issuer_](#riscos-para-a-issuer)\n\n# Personas\n\nSão 4 os personas:\n\n- _issuer_ de crédito\n- _customer_ de uma transação\n- o _shopper_ de um _customer_\n- _seller_ de uma transação\n\nO _customer_ de uma transação eventualmente pode ser\no _seller_ em outra transação.\n\nO _shopper_ é um representante do _customer_\nautorizado a fazer transações.\n\nA _issuer_ de crédito é quem vai operar e garantir o\nPix Crédito\n\n# Uso do Pix Crédito\n\nO uso do Pix Crédito se faz através de 3 formas:\n\n- [uso do crédito por parte do _customer_ para\n  obter bens ou serviços de um\n  _seller_](#uso-do-crédito)\n- [pagamento da fatura do\n  _customer_](#pagamento-da-fatura)\n- saque do dinheiro a ser recebido pelo _seller_\n\nPara isso, pressupõe-se que:\n\n- _seller_ é cliente Pix Crédito\n- _customer_ é cliente Pix Crédito\n- _customer_ já passou por uma análise de risco e\n  tem crédito limitado\n- _seller_ receberá automaticamente o dinheiro\n  devido no dia de saque via conta Pix\n- _customer_ configurou seu _shopper_\n- todo evento ocorre online\n- para todo evento, será mantido um _timestamp_\n  indicando quando ocorreu\n\n## Uso do crédito\n\nO _customer_ deseja adquirir um bem ou serviço do\n_seller_. _Shopper_ (representando o _customer_) e\n_seller_ chegam a uma conclusão de quais valores e\nsobre condição de pagamento desses valores. _Seller_\ninicia uma transação, indicando:\n\n- valor\n- condição de parcelamento\n- _shopper_\n- _customer_\n- identificação do dispositivo usado para criação da\n  transação\n\n_Seller_ recebe de volta o código da transação,\nvalor, condição de parcelamento, _shopper_ e qual o\ndispositivo usado para iniciar a transação.\n\n\u003e O dispositivo é sempre informado a fim de auditoria\n\u003e e garantia de segurança por parte dos operadores.\n\nNesse momento, _shopper_ recebe a transação, e os\natores no sistema podem tomar as seguintes ações:\n\n- _shopper_: validar a transação\n- _shopper_: negar a transação\n- _customer_: negar a transação\n- _shopper_: se abster de tomar ação\n- _seller_: invalidar a transação\n\nAo **_shopper_: validar a transação** temos ainda [2\ncenários](#aprovação-de-crédito):\n\n- o crédito ser aprovado pela _issuer_\n- o crédito ser reprovado pela _issuer_\n\nSe o crédito for aprovado pela _issuer_, então a\ntransação atualiza o _status_ para \"aprovada\",\npodendo então gerar movimentos.\n\nPorém o crédito pode ser reprovado pela _issuer_.\nNestas circunstâncias, o _shopper_ e o _customer_\nserão notificados disto e encorajados a **negar a\ntransação**, porém a eles será _facultada_ essa\nescolha, pois há a possibilidade de normalizar o\ncrédito disponível.\n\nO fato de tentar validar a transação (seja ela\nefetivada com sucesso ou não) implica no envio das\nseguintes informações:\n\n- identificação do dispositivo usado para validar a\n  transação\n- modo de autenticação e validação da autenticação do\n  _shopper_ para aquela transação\n\nAo **_shopper_: negar a transação**, a transação\natualiza o _status_ para \"rejeitada pelo _shopper_\".\nPara negar a transação, é necessário que o _shopper_\nforneça:\n\n- identificação do dispositivo usado para negar a\n  transação\n- modo de autenticação e validação da autenticação do\n  _shopper_ para aquela transação\n\nAo **_customer_: negar a transação**, a transação\natualiza o _status_ para \"rejeitada pelo _customer_\".\nPara negar a transação, é necessário que o _customer_\nforneça:\n\n- identificação do dispositivo usado para negar a\n  transação\n- modo de autenticação e validação da autenticação do\n  _customer_ para aquela transação\n\nO _customer_ tem um curto intervalo de tempo para\ninvalidar uma transação após validada pelo _shopper_.\n\nTambém há a possibilidade de **_shopper_: se abster\nde tomar ação** e deixar a transação sem reação.\nApós determinado tempo, _shopper_ será notificado\nsobre a existência da transação em aberto. Após\ndeterminado tempo, o _customer_ será notificado\nsobre a existência de transações em aberto pelo\n_shopper_ específico.\n\nFinalmente, após determinado tempo, a transação é\ncancelada, mudando o _status_ para \"tempo de\nautenticação execedido\". Isso deve ter mesmos efeitos\npráticos de negar a transação.\n\nPor fim, há a possibilidade de **_seller_: invalidar\na transação**. Isso pode ocorrer a qualquer momento\nantes da validação da transação. Caso ocorra condição\nde corrida e a requisição de invalidar a transação\nocorra após a validação pelo _shopper_ dentro de um\ndeterminado intervalor de tempo, a transação passará\npara o _status_ \"invalidada pelo _seller_\".\n\nPara invalidar uma transação, é necessário fornecer:\n\n- identificação do dispositivo usado para negar a\n  transação\n- modo de autenticação e validação da autenticação do\n  _seller_ para aquela transação\n\n\nInvalidar uma transação deve ter mesmos efeitos\npráticos de negar a transação.\n\nAo negar a transação, quaisquer pré-cálculos sobre\nuso do crédito, para esta transação, em _cache_\nprecisam ser invalidados. O _seller_ é notificado de\nque a transação específica não foi concluída.\n\nToda mudança de _status_ de uma transação precisa ser\narmazenada.\n\n## Pagamento da fatura\n\nUma fatura é composta por movimentos e juros. O\nvalor da fatura é o total da soma dos movimentos no\nintervalo de uso de crédito e a soma dos juros. Além\ndisso, a fatura tem data de publicação, intervalo de\ndatas para receber movimentos, movimentos vindos de\nparcelamento e data de vencimento.\n\nMovimentos advém de:\n\n- transações  \n  nestes casos, o movimento precisa indicar de qual\n  transação ele advém\n- taxa de serviço  \n  taxa da assinatura do Pix Crédito,\n  [taxa de saque]((#saque-do-dinheiro))\n- juros  \n  juros advindos de montante não pago\n\nSerá ofertado duas possibilidades:\n\n- pagamento parcial do montante devedor\n- pagamento total do montante devedor\n\nPagamentos são feitos via Pix endereçados a\n_issuer_, identificando a fatura ao qual o pagamento\nse refere. Pagamentos são identificados como advindos\nde transações externas.\n\nAs taxas de serviço entram como movimentações\nadvindas de transações externas, tendo como\nbeneficiário a _issuer_. Será cobrado um custo de\nanuidade para que o _customer_ possa usar os serviços\ndo Pix Crédito.\n\nCaso não aconteça pagamento o suficiente para cobrar\no montante devedor e os juros no vencimento da\nfatura, juros passarão a correr.\n\n## Saque do dinheiro\n\n\u003e TODO\n\n# Aprovação de crédito\n\nDado um _customer_ que tem limite de crédito `C`,\nsendo que já consumiu `D`, e _shopper_ do _customer_\nque foi configurado com limite de crédito `C' \u003c= C`\ne que consumiu `D' \u003c= D`, uma transação `T` de valor\n`T.vr` pode ser aprovada se:\n\n- `D + T.vr \u003c= C`\n- `D' + T.vr \u003c= C'`\n- `D' \u003c C'`\n\nCaso todas as condições sejam aprovadas, a transação\né devidamente aprovada, mudando de _status_ para\n\"aprovada\".\n\nCaso haja condições de aprovação de crédito não sejam\natendidas, a transação `T` não é aprovada e as\ncondições que não foram atendidas para aprovar a\ntransação são informadas ao _customer_ e ao\n_shopper_.\n\nDe posso da informação do porquê que determinada\ntransação não foi aprovada, o _customer_ pode tomar\nalguma ação:\n\n- pagamento de fatura (diminuindo `D`)\n- pedido de aumento de limite de crédito (aumentado\n  `C`)\n- configurar o _shopper_ para um limite maior\n  (aumentando `C'`)\n- aprovação individual desta transação\n\nNo caso de aprovação individual desta transação,\nteremos que `D' \u003e C'`, a transação vai para o\n_status_ de \"aprovada\" e será colocado como modo de\nautenticação:\n\n- identificação do dispositivo usado do _shopper_\n  para validar a transação\n- modo de autenticação e validação da autenticação do\n  _shopper_ para aquela transação\n- identificação do dispositivo usado do _customer_\n  para validar a transação\n- modo de autenticação e validação da autenticação do\n  _customer_ para aquela transação\n\nOutras formas de aprovação de crédito podem ser\ndescritas no futuro, como a possibilidade de limitar\nvalores altos de transações, limitação diária de\n_shopper_ ou outra limitação.\n\n# Riscos para a _issuer_\n\nAs datas de fatura dos _customers_ podem não\ncoincidir com as datas de saques dos _sellers_, isso\nimplica que há o risco de haver saques para os\n_sellers_ antes de haver o pagamento. Isso pode ser\nmitigado tendo capital de giro. Eventualmente\nempréstimos deverão ser adquiridos para que não haja\nperda de _trustness_ por parte dos _sellers_.\n\nTambém há o risco de o _customer_ não arcar com o seu\ngasto do mês, pagando menos do que o montande devedor\ntotal, ou até mesmo menos do que o \"mínimo\"\ncalculado. Para esse tipo de situação, enquanto for\nsustentável, cobrar os juros para no mínimo cobrir o\ngasto com dinheiro empenhado para pagar os _sellers_.\n\nCaso a situação com o _customer_ se torne\ninsustentável, pode-se vender a dívida do _customer_\npara algum serviço de proteção ao crédito para\nmitigar o prejuízo.\n\n# Fontes de arrecadação da _issuer_\n\n1. taxa de assinatura do serviço: _customer_\n1. taxa de saque: _seller_\n1. juros sobre montante devido: _customer_\n\nA principal fonte deve ser focada na _taxa de saque_.\nEssa modalidade de arrecadação de dinheiro não se dá\ndiretamente através da cobrança do _seller_.\n\n\u003e Explicar que se ganha retendo valor pago pelo\n\u003e _customer_.","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjeffque%2Fpix-credito","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjeffque%2Fpix-credito","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjeffque%2Fpix-credito/lists"}