Mapa do MVP — Funcionalidades e Estruturas

Inventário de tudo que precisa estar pronto para um MVP funcional do internet banking FastGivr: o caminho em que um cliente abre a conta, entra, vê o saldo, recebe e envia Pix, paga um boleto e consulta o extrato.

Escopo deste mapa: fastgivr-api (Laravel) + fastgivr-internet-bank (React). O fastgivr-backoffice e o portal de cobranças (billing) ficam para a Fase 2.

---

1. Caminho de ouro do MVP

Cada passo precisa de backend integrado ao banco liquidante e tela funcional no fastgivr-internet-bank.

---

2. Legenda de status

	Significado
✅	Pronto — backend e frontend integrados e testáveis
🟡	Parcial — só um lado pronto (o outro é mock/pendente)
⛔	Não iniciado
🔌	Depende de integração bancária real (hoje só o gateway Teste cobre 100%)

---

3. Matriz de capacidades

3.1 Acesso e conta

Capacidade	Backend	Frontend	Lacuna para o MVP
Login com verificação de dispositivo (/auth/login → /auth/device/verify)	✅	✅ LoginPage / VerifyDevicePage	— (Fluxo de Login)
Sessão (/auth/{me,profile,logout,refresh})	✅	✅ AuthContext + auto-logout por inatividade	—
Recuperação de senha (/auth/{forgot,reset}-password)	✅	✅ ForgotPasswordPage / ResetPasswordPage	—
Abertura de conta — onboarding multi-etapas (/access/register/*)	✅ — no sandbox (config('banks.sandbox')) o submit aprova automaticamente: cria Account (gateway Teste) + UserAccount + papel de admin (AccountProvisioningService). Produção: UNDER_REVIEW → php artisan register:approve ou backoffice	✅ RegisterPage / OnboardingPage (tela "conta criada" no auto-approve)	— (Fluxo de Cadastro)
Login → área bancária (subject do JWT)	✅ — login / device/verify emitem token com o UserAccount como subject (as rotas /consolidation, /pix, /payments, /access leem Auth::user()->account_id); fallback para User durante o onboarding	✅	—
Dados da conta / perfil (/access/account)	🟡 (update genérico + metadata)	✅ MyAccountPage (perfil, endereço, senha, PIN, preferências)	—
PIN de segurança — cadastro (/access/account/pin) + validação (PinValidator)	✅ (lockout 5 tentativas / 15 min)	✅ 1º cadastro em MyAccountPage; PinDialog nas transferências Pix; boleto com PIN	—
Preferências de Notificação (/access/account/notification-preferences)	✅ (pix_credit, pix_debit, bill_payment, payment_receipts, security_access, product_news)	✅ MyAccountPage (aba Preferências)	—
Notificações in-app (/access/notifications/*)	✅ — gatilhos: Pix recebido (PixReceivedNotification), Pix enviado (PixSentNotification), boleto pago (BoletoPaidNotification)	✅ NotificationsPage	—
Área manager (/access/manager/{users,api-tokens,roles})	✅	⛔	fora do MVP do cliente final

3.2 Saldo, extrato e visão geral

Capacidade	Backend	Frontend	Lacuna para o MVP
Saldo (GET /consolidation/balance)	✅	✅ StatementPage	—
Extrato — lista paginada + statistics (GET /consolidation/transactions)	✅ (saldo corrido, by_type, daily_evolution)	✅ StatementPage	— (Fluxo de Saldo & Extrato)
Extrato por dia / série temporal / agregado por tipo (/consolidation/transactions/{daily,time-series,by-type})	✅	✅ ReportsPage (fluxo diário + composição por tipo)	—
Exportação de extrato (POST /consolidation/transactions/export)	✅ (assíncrono, notifica)	✅ botão em StatementPage + ReportsPage (PDF/XLSX/CSV)	download direto (hoje é assíncrono)
Dashboard / visão geral	✅ (GET /consolidation/dashboard — relatório composto: /consolidation/statistic/cards, time-series, by-type)	✅ DashboardPage	—
Relatórios — KPIs, gráficos e indicadores por período (rápido ou datas personalizadas)	✅ (GET /consolidation/dashboard com start_date/end_date)	✅ ReportsPage (/relatorios)	—

3.3 Pix

Capacidade	Backend	Frontend	Lacuna para o MVP
Cobrança Pix dinâmica (POST /pix/charges) — QR + copia e cola	✅ 🔌	✅ PixQrCodePage (QR real + status)	—
Pix estático da conta (GET /pix/charges/static)	✅	⛔	opcional no MVP
Lista / detalhe de cobranças (GET /pix/charges[/{txid}])	✅	✅ PixQrCodePage (bloco "Cobranças recentes" — valor, txid, status, copiar código)	—
Recebimento de Pix → marca Pix pago, lança no ledger, notifica	✅ 🔌 PixInSettlementService (Pix→PAID + pix-in/fee-pix-in + Charge→paga + PixReceivedNotification + webhook do lojista; idempotente por txid). Gateway Teste: POST /webhook/teste/pix-in (público) e POST /pix/charges/{txid}/simulate-payment (autenticado)	n/a	—
Consulta de chave (DICT) (POST /pix/keys/lookup)	✅ — StricService: mock determinístico (sandbox) ou provedor real (PrismaPay/STRIC) quando STRIC_ENABLED=true	✅ PixTransferPage (preview)	—
Pix Out por chave (/pix/transfers/key/preview → /pix/transfers/key)	✅ 🔌 (PinValidator + makePixTransfer)	✅ PixTransferPage (review → PIN → comprovante)	—
Pix Out copia e cola (/pix/transfers/copy-paste[/preview]) — decoder EMV/CRC16	✅ (estático) · 🔌 (dinâmico: só Teste/getPixCharge)	✅ PixTransferPage (aba copia e cola)	—
Pix Out dados bancários (/pix/transfers/manual)	✅ 🔌	✅ PixTransferPage (aba "Dados bancários" → review → PIN → comprovante)	—
Histórico de envios + comprovante (GET /pix/transfers[/{id}], GET /pix/transfers/{id}/receipt — JSON e ?format=pdf)	✅	✅ PixHistoryPage	ligar à API
Contas favoritas / destinatários — CRUD (/pix/recipients, pix_keys multi-chave)	✅	✅ PixPage (favoritos) / PixKeysPage	—
Minhas chaves Pix — CRUD (GET/POST/DELETE /pix/keys, pix_account_keys)	✅ 🔌 (mock Teste: createPixKey/deletePixKey; limite 5, 1× cpf/cnpj)	✅ PixKeysPage (pix.keys list/register/remove)	—

Detalhe: Fluxo de Pix.

3.4 Pagamento de boleto

Capacidade	Backend	Frontend	Lacuna para o MVP
Consultar linha digitável (POST /payments/boletos/inspect)	✅ 🔌 (getBoletoDetails — gateway Teste)	✅ BoletoPaymentPage	—
Pagar agora (POST /payments/boletos/{id}/pay) — PIN + ledger + BoletoPaidNotification	✅ 🔌	✅ BoletoPaymentPage (com input de PIN)	—
Agendar (/schedule) · Cancelar (/cancel)	✅ 🔌	✅ BoletoPaymentPage (toggle "Pagar agora / Agendar" + PIN; botão "Cancelar" nos pendentes/agendados)	—
Comprovante (/receipt)	✅ 🔌	✅ BoletoPaymentPage (modal "Comprovante Bancário": situação + data junto ao banco liquidante)	—
DDA (/dda)	✅ 🔌 (mock Teste devolve lista vazia)	⛔	tela opcional no MVP (bloqueada pelo mock)
Histórico de pagamentos (GET /payments/boletos)	✅	✅ BoletoPaymentPage (payments.boletos.list)	ligar à API

Detalhe: Fluxo de Pagamento de Boleto.

3.5 Fora do MVP (Fase 2)

Capacidade	Backend	Frontend
Emissão de boleto / Bolepix (/quickpay/boletos)	🟡	⛔
Cobranças / faturas (/invoices, /billing/*, /clients)	🟡	⛔ (portal de cobrança)
Transferência interna entre contas (POST /transfers/internal)	🟡	⛔
Backoffice administrativo (/backoffice/*)	🟡 (read-only)	app fastgivr-backoffice (separado)
2FA Google Authenticator (google2fa_* em accounts)	🟡 (colunas existem)	⛔
Multi-conta (usuário com N contas)	✅ (user_accounts + SetActiveAccountMiddleware)	⛔ (troca de conta na UI)

---

4. Estruturas já montadas

4.1 API — roteamento

Arquivo	Prefixo	Domínio
routes/api.php	vários	/auth, /enums, /webhook, raiz (billing), /quickpay, /backoffice
routes/access.php	/access	onboarding, notificações, preferências, conta + PIN, manager
routes/consolidation.php	/consolidation	saldo, extrato, estatísticas, exportação
routes/pix.php	/pix	Pix in/out, DICT, PIN, favoritos
routes/payments.php	/payments	pagamento de boletos de terceiros

Todos carregados por bootstrap/app.php (Route::group([], base_path(...))), sem prefixo /api.

4.2 API — camadas de serviço

Serviço	Papel	Status
App\Services\PinValidator	valida PIN + bloqueio por tentativas (RateLimiter)	✅
App\Services\Pix\BrCodeDecoder	decodifica BR Code EMV + CRC16	✅
App\Services\Pix\PixService	ledger do Pix Out, tarifas, destinatário, guessKeyType, notif. pix_debit	✅
App\Services\Pix\PixInSettlementService	liquidação de Pix recebido (idempotente): ledger + Charge + notif. + webhook	✅
App\Services\Payments\BoletoPaymentService	inspect / pay / schedule / cancel / receipt / DDA + notif. bill_payment	✅
App\Services\AccountNotificationService	entrega notificação in-app aos usuários da conta (pref-aware, nunca lança)	✅
App\Services\PixEstatico	gera payload EMV estático	✅
App\Services\StricService	consulta DICT — mock determinístico ou HTTP real (config('services.stric.enabled'))	✅
App\Services\{Charge,Invoice,WebhookNotification,Comtele,EvolutionApi}Service	cobrança, faturas, notificações, SMS/WhatsApp	🟡 Fase 2

4.3 API — controllers do MVP

Access\{AccountController, NotificationController, NotificationPreferenceController} · Access\Auth\{AuthController, AuthRegisterController, AccountVerificationController, TrustedDeviceController} · Consolidation\TransactionController · Pix\{PixInController, PixOutController, PixKeyController, PixPinController, PixRecipientController} · Payments\BoletoPaymentController · Webhooks\{TesteGatewayWebhookController, ProcessWebhookStripe}

4.4 API — modelos centrais

Account · User ⇄ UserAccount · Client · Transaction (+ TransactionType) · Balance / vw_balance · Pix · PixWithdraw · PixRecipient · BoletoWithdraw · Boleto · Charge · TrustedDevice · BankInstitution · Webhook / WebhookNotifications · Notification (+ NotificationTemplate) · PixAccountKey (minhas chaves Pix)

TransactionType: os slugs canônicos usados no ledger (pix-in, pix-out, fee-pix-in, fee-pix-out, boleto-payment) são definidos pelo TransactionTypeSeeder e não são mais sobrescritos pelo boot do model (antes ele forçava Str::slug(name), quebrando TransactionType::get('pix-in')). get() agora é ?self — os fallbacks ?? get('taxa-…') funcionam.

Migrações incrementais recentes: 2026_09_01_000005_add_favorite_fields_to_pix_recipients, 2026_09_01_000006_align_boleto_withdraws_for_payments, 2026_09_02_000001_create_pix_account_keys.

4.5 Integração bancária (App\Models\Banks\*)

Ambiente sandbox: existe um único gateway, App\Models\Banks\Teste, com respostas mockadas determinísticas. Os adaptadores reais (Sicoob, Sicredi, BB, Ioniq) foram removidos — o histórico fica no git. Para produção: adicionar a classe do provedor real e incluir seu nome em config('banks.gateways').

Adaptador	Pix In	Pix Out (chave / dados bancários / copia e cola)	DICT (/pix/keys*)	Boleto (consultar / pagar / agendar / DDA)
Teste (sandbox)	✅ mock	✅ mock	✅ mock (StricService) · real via STRIC_ENABLED	✅ mock

config/banks.php → gateways: ['Teste']. accounts.bank_gateway é sempre "Teste" (seeders + factory). Account::getBank() lança RuntimeException para qualquer outro valor.

4.6 Frontend — infraestrutura

src/services/{api,http,auth,access,consolidation,pix,payments,quickpay,billing,enums}.ts · src/config/nav.ts (fonte única do menu) · src/components/layout/AppLayout.tsx (shell + <Outlet/>) · src/components/pix/PinDialog.tsx (aprovação por PIN — trata 403/409/422/429) · src/lib/apiError.ts (normalizeApiError — status + mensagem + erros de campo + reason) · src/lib/format.ts (brl, dateValue — datas vêm string OU {full,formatted,human}) · src/components/ErrorBoundary.tsx + páginas errors/{ForbiddenPage,ServerErrorPage} (403/500) · interceptor api.ts (Bearer + X-Device-Id, 401 → /login?session=expired).

4.7 Frontend — telas

Tela	Rota	Integrada?
Login / Verificar dispositivo	/login · /verificar-dispositivo	✅
Cadastro / Onboarding	/cadastro · /cadastro/continuar	✅
Esqueci / Redefinir senha	/esqueci-senha · /redefinir-senha	✅
Dashboard	/dashboard	✅ cards + evolução de saldo + atividade recente
Saldo e Extrato	/extrato · /saldo	✅
Relatórios	/relatorios	✅ período rápido/personalizado · KPIs + tendência · evolução de saldo · fluxo diário · composição por tipo · indicadores · exportar PDF/XLSX/CSV
Minha Conta	/minha-conta	✅ perfil/endereço, troca de senha, PIN, preferências
Notificações	/notificacoes	✅
Área Pix	/pix	✅ saldo + favoritos (recipients) + histórico
Pix — Transferir	/pix/transferir	✅ chave · copia e cola · dados bancários → review → PIN → comprovante
Pix — Cobrar (QR)	/pix/cobrar	✅ cria cobrança + QR real + status + simular pgto + histórico de cobranças
Pix — Histórico	/pix/extrato	✅ enviados + recebidos + comprovante PDF
Pix — Chaves	/pix/chaves	✅ pix.keys list/register/remove
Pagar Boleto	/pagamentos/boleto	✅ inspect + pagar/agendar (PIN) + histórico + cancelar + comprovante

---

5. Checklist de bloqueadores do MVP

Backend e frontend do caminho de ouro: prontos e testados (gateway Teste). Backend com testes automatizados; frontend verificado ponta a ponta no navegador (criar cobrança → simular pagamento → transferir com PIN → comprovante).

1. [x] Dashboard (DashboardPage): cards (consolidation.statisticCards), evolução de saldo (transactions.statistics.daily_evolution), atividade recente. Backend: getIdByName('PIX IN') resolve por slug.
2. [x] PIN — 1º cadastro: seção em MyAccountPage (aba Segurança) — GET /pix/pin/status + POST /access/account/pin. PinDialog navega para /minha-conta?pin=1 quando o PIN não existe.
3. [x] Pix Out — Transferir (PixTransferPage): previewByKey → sendByKey e previewCopyPaste → sendCopyPaste, review + PinDialog (trata 403/409/422/429), tela de comprovante.
4. [x] Pix In — Cobrar (PixQrCodePage): pix.in.create → QR real + copia e cola, polling de status via pix.in.getByTxid, botão "Simular pagamento" (pix.in.simulatePayment).
5. [x] Pix — Histórico (PixHistoryPage): merge de pix.transfers.list (enviados) + consolidation.transactions filtrado por pix-in (recebidos); comprovante PDF via pix.transfers.receiptPdf.
6. [x] Favoritos / Área Pix (PixPage, PixKeysPage): pix.recipients (listar/criar/remover) e pix.keys (list/register/remove); PixPage com saldo, favoritos e histórico reais.
7. [x] DICT (MVP): StricService::getPixInfo devolve titular determinístico (mock); bloco HTTP real comentado.
8. [x] Recebimento de Pix: PixInSettlementService (idempotente) — Pix→PAID + pix-in/fee-pix-in + Charge→paga + PixReceivedNotification + webhook do lojista. Gateway Teste: POST /webhook/teste/pix-in e POST /pix/charges/{txid}/simulate-payment. Testado (PixInSettlementTest).
9. [x] Notificações in-app de todos os eventos do caminho de ouro: PixReceivedNotification, PixSentNotification, BoletoPaidNotification — via AccountNotificationService (respeita pix_credit / pix_debit / bill_payment, nunca quebra a liquidação). Toggles na aba Notificações de MyAccountPage. Testado.
10. [x] Comprovantes: GET /pix/transfers/{id}/receipt (JSON + ?format=pdf); boleto via GET /payments/boletos/{id}/receipt + GET /consolidation/transactions/{id}/pdf.
11. [x] Minha Conta (MyAccountPage): perfil + endereço via PUT /access/account; troca de senha via PUT /auth/profile; carrega dados de GET /access/account.
12. [x] Boleto — histórico (BoletoPaymentPage): payments.boletos.list no lugar do histórico local; badges por status; comprovante via payments.boletos.receipt.
13. [x] Doc do fluxo /consolidation — Fluxo de Saldo & Extrato.
14. [x] route:cache — colisão de nome (billing/clients) resolvida com nomes explícitos billing.*. php artisan route:cache funciona.
15. [x] DICT real — StricService é env-driven (STRIC_ENABLED + credenciais); mock é o fallback. config('services.stric').

Infra: para a demo do caminho de ouro no navegador, a conta precisa de bank_gateway = "Teste". As Notifications in-app são ShouldQueue — exigem QUEUE_CONNECTION=sync ou um worker (php artisan queue:work) ativo.

Opcionais (podem ficar para logo depois do MVP)

• Boleto DDA na UI (o mock do gateway Teste sempre devolve lista vazia — só faz sentido com provedor real).
• Download direto (não assíncrono) de extrato.
• Troca de conta ativa (multi-conta) na UI.
• 2FA Google Authenticator.

---

6. Definição de pronto (MVP)

O MVP está pronto quando, no gateway Teste (sandbox):

• ✅ um cliente abre a conta (cadastro aprovado automaticamente no sandbox — conta + vínculo criados na hora), faz login (com verificação de dispositivo) e define o PIN;
• ✅ vê saldo e extrato com valores reais;
• ✅ cria uma cobrança Pix e a recebe (webhook Teste / "simular pagamento" → saldo atualizado + notificação);
• ✅ envia Pix por chave e por copia e cola, confirmando com PIN, e vê o comprovante;
• ✅ paga um boleto pela linha digitável, confirmando com PIN, e vê o comprovante;
• ✅ recebe notificações in-app dos eventos acima e controla suas preferências.

Todo o caminho de ouro está implementado (backend + frontend) e verificado no gateway Teste — testes automatizados (RegistrationApprovalFlowTest, AuthFlowTest, PixKeyControllerTest, PixInSettlementTest, PixOutNotificationTest, BoletoPaymentNotificationTest, DashboardReportTest; 90 passando) e verificação ponta a ponta no navegador. O DICT real (PrismaPay/STRIC) já está integrado no código — basta STRIC_ENABLED=true + credenciais em produção.

---

7. Checklist completo — cobertura da collection do parceiro bancário real

Checklist exaustivo dos 164 endpoints da collection Postman "API de Contas — Integração" (fastgivr-docs-bank/Coleções Postman/, contrato de referência de um parceiro bancário real), organizados nas etapas de implementação abaixo. Cada linha diz se já existe um equivalente funcional simulado no gateway Teste/produto, se é uma lacuna real a construir, ou se está fora de escopo (com o motivo).

Legenda: ✅ implementado e simulado · 🔲 lacuna real, ainda não implementado · ⛔ fora de escopo (motivo na própria linha)

Etapa 1 — Conta e acesso (self-service do titular)

#	Endpoint da collection	Status	Equivalente no produto
1	POST /login (PF/PJ)	✅	POST /auth/login (unificado PF/PJ)
2	PUT /acesso/senhas (1º cadastro de senha)	✅	senha definida no POST /access/register/start
3	PUT /acesso/senhas/esquecer	✅	POST /auth/forgot-password
4	PATCH /acesso/senhas/transacional (alterar PIN)	✅	PATCH /access/account/pin (AccountController::change_pin)
5	DELETE /logout	✅	POST /auth/logout
6	GET /conta	✅	GET /access/account
7	GET /conta/limites	🔲	os limites (min_pix_in, max_pix_out, ...) só aparecem embutidos no payload geral da conta — sem endpoint dedicado
8	GET /conta/grades-horarias	⛔	janelas de horário de operação são regra do banco liquidante real (TED/DOC); sem sentido no gateway Teste, que não tem corte de horário
9	GET /conta/dashboard	✅	GET /consolidation/dashboard
10	GET /conta/dashboard/indicadores	✅	GET /consolidation/dashboard?start_date&end_date
11	DELETE /conta/emergencia	✅	POST /access/account/emergency-lock
12	DELETE /conta (encerramento)	✅	DELETE /access/account
13	POST /acesso, GET /acesso, GET /acesso/:id, PUT /acesso/:id, DELETE /acesso/:id (gestão de acessos da conta)	✅	/access/manager/users (usuários da conta) — modelo equivalente (papel + convite), nomes de endpoint diferentes
14	GET /conta/documento (documentos enviados)	✅	GET /access/account/documents
15	GET /conta/aceite/:token (aceite de termos)	✅	PATCH /access/register/accept-terms — captura o consentimento (timestamp), sem entrar na máquina de etapas obrigatórias do onboarding
16	GET /conta/vinculadas/escrow, GET /conta/vinculadas/consignados/:id	⛔	contas Escrow/Consignada — fluxo B2B, fora do escopo do portal do cliente (decisão já registrada em sessões anteriores)
17	POST /conta (Onboarding PJ/PF)	✅	POST /access/register/start + etapas — ver Fluxo de Cadastro
18	POST /conta/solicitar (Escrow/Consignada)	⛔	mesma razão do item 16
19–47	Importar documentos · listar/aprovar/reprovar abertura de conta · reenvio de credenciais · editar/bloquear/encerrar "conta terceira" · listar por status/legado/auditoria · fila de alteração (29 endpoints)	⛔	esta é a API que o parceiro expõe para o backoffice do próprio parceiro administrar as contas dos clientes de um reseller — no nosso caso, o equivalente já existe do nosso lado (Backoffice\RegistrationController, Backoffice\AccountController), não replicamos o contrato do parceiro 1:1

Etapa 1b — Credenciais sistêmicas e regras de IP

#	Endpoint	Status	Equivalente
1	POST /auth/token (token de credencial sistêmica)	✅	POST /auth/token (AuthController::authAPI)
2–5	Listar/solicitar/ativar/excluir credencial de acesso	✅	/access/manager/api-tokens
6–9	Regras de IP por acesso (listar/adicionar/ativar/excluir)	⛔	não há requisito de negócio para allowlist de IP por credencial hoje; reavaliar se surgir a necessidade

Etapa 2 — Saldo e extrato

#	Endpoint	Status	Equivalente
1–2	Consultar saldo (geral / por período)	✅	GET /consolidation/balance
3–4	Extrato (simples / paginado)	✅	GET /consolidation/transactions
5–6	Débitos pendentes (própria conta / conta terceira)	✅ / ⛔	própria conta: extrato filtrado por status; conta terceira: fora de escopo (item da Etapa 1)
7	Consultar um lançamento específico	✅	GET /consolidation/transactions/{id}
8–10	Extrato/saldo de conta terceira ou vinculada	⛔	mesma razão da Etapa 1 (administração de conta terceira/escrow)
11	Extrair informe de rendimentos	✅	GET /access/account/statement-of-earnings

Etapa 3 — Pix

#	Endpoint	Status	Equivalente
1–4	Gestão de chaves (incluir/listar/excluir/consultar)	✅	/pix/keys (createPixKey/deletePixKey/listPixKeys)
5–10	Gestão de reivindicação (incluir/listar/consultar/concluir/confirmar/cancelar)	✅	/pix/keys/claims (claimPixKey/confirmPixKeyClaim/cancelPixKeyClaim/listPixKeyClaims)
11	Decodificar QR Code	✅	BrCodeDecoder (copia e cola)
12	Gerar QR estático	✅	PixEstatico
13–14	QR dinâmico imediato (gerar/atualizar)	✅	POST/PUT /pix/charges
15–16	QR dinâmico com vencimento (gerar/atualizar)	✅	createPixComVencimento
17–19	Listar/buscar/inativar QR dinâmico	✅	GET/DELETE /pix/charges
20	Extrato Pix (SPI)	✅	GET /consolidation/transactions filtrado por pix-in/pix-out
21	Transferir Pix	✅	/pix/transfers/*
22–24	Devolução (motivos/devolver)	✅	PixRefundService, GET /pix/refunds/reasons
25	Consultar transferência Pix	✅	GET /pix/transfers/{id}
26	Listar notificações Pix	✅	/access/notifications (in-app, evento pix_credit/pix_debit)
27–31	Pix recorrente (gerar/simular/listar/consultar/consultar agendados/cancelar)	✅	/pix/recurrences/*
32–35	Pix agendado (agendar/listar/consultar/cancelar)	✅	/pix/transfers/key/schedule, /pix/schedules/*

Etapa 4 — Transferência bancária (TED/DOC)

#	Endpoint	Status	Equivalente
1	Listar bancos	✅	GET /transfers/banks
2	Listar finalidades (STR0008)	✅	GET /transfers/purposes
3	Transferência	✅	POST /transfers
4–5	Listar/consultar/cancelar transferência agendada	✅	POST /transfers/schedule, GET/DELETE /transfers/{id}
6–8	Favorecidos (listar/consultar por documento/apagar)	✅	bank_transfer_recipients + GET/POST /transfers/recipients, GET/DELETE /transfers/recipients/{id}
9–11	Fila de pendentes + lote (efetuar/cancelar)	🔲	específico de TED — a Etapa 6 implementada cobre só pagamento de boleto (evidência confirmada na collection: o payload de "Pagamentos" usa digitable/barcode, não campos de transferência); mesmo padrão poderia ser replicado aqui depois
12	Movimentar conta (lançamento manual de ajuste)	⛔	operação de back-office do parceiro sobre a conta, não uma ação do cliente final

Etapa 5 — Boletos

#	Endpoint	Status	Equivalente
1–2	Gerar/consultar boleto de cobrança	✅	QuickPay\BoletoController
3–4	Gerar/consultar boleto de depósito	✅	makeBoletoDeposito
5	Listar boletos	✅	GET /quickpay/boletos
6	Listar boletos liquidados	✅	filtro de status na listagem
7–9	Favorecidos de boletos (listar/consultar/apagar)	✅	boleto_recipients + GET /payments/boletos/recipients[/{id}], DELETE /payments/boletos/recipients/{id}
10–12	Carnê (gerar/listar/consultar boletos do carnê)	✅	boleto_booklets

Etapa 6 — Pagamentos com aprovação em duas etapas ✅

A collection modela o pagamento de boleto de terceiro com um fluxo de dupla checagem (maker-checker): um usuário "autoriza" (prepara) o pagamento, e outro "efetiva" — ou aprova/rejeita a partir de uma fila de pendentes, inclusive em lote.

#	Endpoint	Status	Equivalente
1	Autorizar pagamento (prepara, sem executar)	✅	POST /payments/boletos/{id}/request-approval — PENDING → AWAITING_APPROVAL
2	Efetivar pagamento (executa direto, sem fila)	✅	POST /payments/boletos/{id}/pay (já existia)
3	Listar pagamentos pendentes (fila de aprovação)	✅	GET /payments/boletos/pending-approval
4–5	Aprovar / rejeitar pagamento pendente (PIN)	✅	PUT /payments/boletos/{id}/approve (efetiva de fato, reaproveita pay()), DELETE /payments/boletos/{id}/reject
6–7	Aprovar / rejeitar pagamentos pendentes em lote	✅	PUT /payments/boletos/approve-batch, DELETE /payments/boletos/reject-batch — best-effort por item
8–9	Listar pagamentos / consultar pagamento específico	✅	GET /payments/boletos, GET /payments/boletos/{id}

⚠️ Achado durante a implementação — a "alçada maior" não é aplicada.request-approval/approve/reject exigem PIN da conta, igual a pay(), mas não há checagem de papel/permissão distinguindo quem pode só "autorizar" de quem pode "aprovar" — confirmado por grep que nenhuma rota da API inteira usa o middleware permission/role (o spatie/laravel-permission está seedado, mas puramente declarativo — nada no backend hoje consulta hasPermissionTo()/can() para decidir acesso). Adicionar essa checagem só para este fluxo seria inconsistente com o resto da API, que não impõe essa régua em nenhum outro lugar (nem em saques, que também deveriam ser restritos por papel segundo a descrição dos perfis). Fica registrado como um achado de arquitetura, não resolvido aqui — resolver exigiria decidir a estratégia de enforcement (middleware permission: vs. checagem no controller) para a API inteira, não só um endpoint.

Etapa 7 — Logs, históricos e informativos

#	Endpoint	Status	Nota
1–2	Listar logs (geral / por usuário)	✅	GET /access/account/logs (channel audit)
3–4	Adicionar/listar histórico (nota interna por conta)	🔲 (baixa prioridade)	recurso de CRM interno do backoffice — nenhuma tela ou fluxo do produto depende disso hoje
5–6	Criar/consultar informativo (aviso com validade)	🔲 (baixa prioridade)	mural de avisos administrativos — distinto do sistema de notificações in-app por evento que já existe

Fora de escopo (decisão de produto já tomada)

Pasta da collection	Motivo
Cripto (10 endpoints, inclui cartões)	Cotação/negociação de cripto não tem relação com o negócio (conta transacional/Pix/boleto); cartões foram explicitamente removidos a pedido do usuário em sessão anterior — não reintroduzir sem novo pedido explícito
Remessas (CNAB, 9 endpoints)	Envio de arquivo em lote (transferências/boletos) é fluxo B2B/backoffice, não uma ação do portal do cliente final
Contas Escrow/Consignada e administração de "conta terceira" (dentro de "Contas e acessos")	API do parceiro para o backoffice do parceiro administrar contas de revenda — o equivalente do nosso lado já existe via Backoffice\*
Regras de IP por credencial	Sem requisito de negócio hoje