Loading repository data…
Loading repository data…
hellyaxs / repository
uma API RESTful conectada a um banco de dados e a duas APIs de terceiros. Trata-se de um sistema gerenciador de pagamentos multi-gateway.
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
API RESTful para gerenciamento de pagamentos multi-gateway com fallback por prioridade, autenticacao, autorizacao por roles, CRUD de usuarios e produtos, compras assincronas em fila e fluxo de reembolso.
flowchart LR
A["Cliente HTTP"] --> B["/api/v1/*"]
B --> C["Middlewares<br/>Auth + Roles"]
C --> D["Controller"]
D --> E["Contract / Port"]
E --> F["PurchaseAdapter"]
F --> DB[("MySQL<br/>Transaction pending")]
F --> Q["Redis Queue<br/>jobs::payments::pending"]
Q --> W["Worker<br/>ProcessPaymentJob"]
W --> P["PaymentProcessor"]
P --> GS["GatewaySelector"]
GS --> H1["GatewayOneAdapter"]
GS --> H2["GatewayTwoAdapter"]
H1 --> I1["Gateway Externo 1"]
H2 --> I2["Gateway Externo 2"]
W --> DB2[("MySQL<br/>Transaction update")]
(como grandes banco fazem): o request HTTP retorna imediatamente com status: pending enquanto o job e processado pelo worker em background.ProcessPaymentJob garante idempotencia: ignora transacoes que nao estejam com status: pending.sqids oculta o id real protegendo indices do sistemafailed() marca a transacao como status: error com lastError: payment_processing_failed.QUEUE_DRIVER=sync pode ser usado em testes para processar jobs de forma sincrona sem Redis.User e client estavam muito ambiguios, pesando em normalizaçaõ de dados defini apenas 1 tabela que contepla os dois