Every POST /webhooks/hyperswitch delivery now writes a row to
`hyperswitch_webhook_log` regardless of signature-valid or
processing outcome. Captures both legitimate deliveries and attack
probes — a forensics query now has the actual bytes to read, not
just a "webhook rejected" log line. Disputes (axis-1 P1.6) ride
along: the log captures dispute.* events alongside payment and
refund events, ready for when disputes get a handler.
Table shape (migration 984):
* payload TEXT — readable in psql, invalid UTF-8 replaced with
empty (forensics value is in headers + ip + timing for those
attacks, not the binary body).
* signature_valid BOOLEAN + partial index for "show me attack
attempts" being instantaneous.
* processing_result TEXT — 'ok' / 'error: <msg>' /
'signature_invalid' / 'skipped'. Matches the P1.5 action
semantic exactly.
* source_ip, user_agent, request_id — forensics essentials.
request_id is captured from Hyperswitch's X-Request-Id header
when present, else a server-side UUID so every row correlates
to VEZA's structured logs.
* event_type — best-effort extract from the JSON payload, NULL
on malformed input.
Hardening:
* 64KB body cap via io.LimitReader rejects oversize with 413
before any INSERT — prevents log-spam DoS.
* Single INSERT per delivery with final state; no two-phase
update race on signature-failure path. signature_invalid and
processing-error rows both land.
* DB persistence failures are logged but swallowed — the
endpoint's contract is to ack Hyperswitch, not perfect audit.
Retention sweep:
* CleanupHyperswitchWebhookLog in internal/jobs, daily tick,
batched DELETE (10k rows + 100ms pause) so a large backlog
doesn't lock the table.
* HYPERSWITCH_WEBHOOK_LOG_RETENTION_DAYS (default 90).
* Same goroutine-ticker pattern as ScheduleOrphanTracksCleanup.
* Wired in cmd/api/main.go alongside the existing cleanup jobs.
Tests: 5 in webhook_log_test.go (persistence, request_id auto-gen,
invalid-JSON leaves event_type empty, invalid-signature capture,
extractEventType 5 sub-cases) + 4 in cleanup_hyperswitch_webhook_
log_test.go (deletes-older-than, noop, default-on-zero,
context-cancel). Migration 984 applied cleanly to local Postgres;
all indexes present.
Also (v107-plan.md):
* Item G acceptance gains an explicit Idempotency-Key threading
requirement with an empty-key loud-fail test — "literally
copy-paste D's 4-line test skeleton". Closes the risk that
item G silently reopens the HTTP-retry duplicate-charge
exposure D closed.
Out of scope for E (noted in CHANGELOG):
* Rate limit on the endpoint — pre-existing middleware covers
it at the router level; adding a per-endpoint limit is
separate scope.
* Readable-payload SQL view — deferred, the TEXT column is
already human-readable; a convenience view is a nice-to-have
not a ship-blocker.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| adr | ||
| archive | ||
| audit-2026-04 | ||
| audits | ||
| runbooks | ||
| API_REFERENCE.md | ||
| API_VERSIONING_POLICY.md | ||
| ASVS_CHECKLIST_v0.12.6.md | ||
| BOOT_MODE_STATUS.md | ||
| BUDGETS.md | ||
| BUG_BASH_V0981.md | ||
| CHAT_FEATURE_PARITY.md | ||
| DB_MIGRATIONS_AUDIT_V1.md | ||
| DB_MIGRATIONS_ORIGIN_DIFF.md | ||
| DB_MIGRATIONS_STRATEGY_FINAL.md | ||
| DB_MIGRATIONS_V1_VALIDATION.md | ||
| DB_TRANSACTION_PLAN.md | ||
| DISCOVERY_ALGORITHM.md | ||
| ENV_CONFIG.md | ||
| ENV_VARIABLES.md | ||
| ENVIRONMENT_REAL_SETUP.md | ||
| FEATURE_STATUS.md | ||
| FRONTEND_AUDIT_VISUAL.md | ||
| FRONTEND_DEEP_DIVE_AUDIT.md | ||
| FRONTEND_ROADMAP_SPOTIFY_DISCORD_QUALITY.md | ||
| FRONTEND_SETUP.md | ||
| FRUGALITY.md | ||
| GLOBAL_PROJECT_STATE_2026.md | ||
| GO_NO_GO_CHECKLIST_v1.0.0.md | ||
| MIGRATION_CONSOLIDATION.md | ||
| MIGRATIONS.md | ||
| MINIMAL_WEB.md | ||
| MONITORING_SETUP.md | ||
| MONOREPO_ORCHESTRATION.md | ||
| ONBOARDING.md | ||
| PAYMENTS_SETUP.md | ||
| PAYOUT_MANUAL.md | ||
| PENTEST_REPORT_VEZA_v0.12.6.md | ||
| PERFORMANCE_BASELINE.md | ||
| PR_READY_CHECKLIST.md | ||
| PRIVACY_POLICY.md | ||
| PRODUCTION_DEPLOYMENT.md | ||
| PROJECT_STATE.md | ||
| PWA_OFFLINE_VERIFICATION.md | ||
| README.md | ||
| REMEDIATION_MATRIX_v0.12.6.md | ||
| REMOTE_DEV_R720.md | ||
| REPORT_FRONTEND_PHASE1.md | ||
| RGPD_CCPA_VERIFICATION.md | ||
| ROADMAP_V09XX_TO_V1.md | ||
| SCOPE_CONTROL.md | ||
| SECRET_ROTATION.md | ||
| SECRETS_AUDIT.md | ||
| SECRETS_VERIFICATION.md | ||
| SECURITY_SCAN_RC1.md | ||
| STAGING_DEPLOYMENT.md | ||
| STORYBOOK_CONTRACT.md | ||
| STRATEGIE_COUVERTURE_ET_TMT_2025_02.md | ||
| TEST_PROTOCOL_BOOT.md | ||
| TODO_TRIAGE_VEZA.md | ||
| TRANSACTION_TESTS_PHASE3.md | ||
| TRIAGE_REPORT.md | ||
| UUID_DB_CARTOGRAPHY.md | ||
| UUID_DB_MIGRATION_PLAN.md | ||
| V1_LIMITATIONS.md | ||
| V1_MVP_SCOPE.md | ||
| V1_SIGNOFF.md | ||
| VEZA_PROJECT_DOCUMENTATION.md | ||
| VISUAL_TESTING_STRATEGY.md | ||
Documentation Veza
Index de la documentation principale du monorepo.
Démarrage
- Onboarding — Setup, architecture, conventions, troubleshooting
- Frontend Setup — Configuration du frontend React
- Environment Config — Variables d'environnement et connexion Docker
Architecture & Déploiement
- Production Deployment — Déploiement en production
- Monorepo Orchestration — Organisation du monorepo
- Monitoring Setup — Configuration du monitoring
Développement
- Remote Dev R720 — Développement sur serveur R720 via Cursor Remote-SSH
- Scope v0.201 — Périmètre de la version courante (référence prioritaire)
- État du projet — Où en sommes-nous, prochaines étapes
- Contrôle du scope — Processus anti-scope-creep
- Feature Status — Statut des fonctionnalités
- Storybook Contract — Conventions Storybook
- Visual Testing Strategy — Stratégie des tests visuels
- PR Ready Checklist — Checklist avant merge
Base de données & Migrations
- DB Migrations Strategy — Stratégie des migrations
- UUID Migration Plan — Plan de migration UUID
Sécurité & Opérations
- Secrets Verification — Vérification des secrets
- Secret Rotation — Rotation des secrets
- Payments Setup — Configuration des paiements
Remédiation & Progression
- Remediation Progress — Suivi de la remédiation
- Global Project State — État global du projet
Archives
Les audits et rapports historiques sont dans docs/archive/.
Documentation par composant
- Frontend :
apps/web/docs/(FULL_LAYOUT_PAGE, DESIGN_TOKENS, etc.) - Backend :
veza-backend-api/docs/