Architecture at a glance

Vecnet consolidates two payment rails. The authoritative reference is vecnet_citizen_flow.mmd and the architecture PDF; the themed diagram below is rebuilt from it.

System flow

In words:

• Online payers go Web/App → Vecnet Hosted Checkout (which embeds the Tonder Lite SDK v2.0) → Tonder API → Tonder Backend, which sends a Transaction Notification back to the Vecnet Listener.
• In-person payers go Terminal POS → Menta API → Menta Backend, which also notifies the Listener.
• The Listener writes to the Vecnet DB (Postgres) and hands off to the Webhook Manager, which notifies the portal/merchant.
• The Vecnet Backend runs Finanzas (the finances module) and Liquidaciones (settlements). The Frontend exposes the Hosted Checkout, Dashboard, Admin Panel, and System Control Panel.

Two load-bearing principles

Carry these through every design decision.

1 · Acquirer-as-plugin

Tonder and Menta are two rails behind one abstraction. The finances engine treats each rail as an ACQUIRER entity. Adding a third rail later must not require schema or core-flow changes — only a new acquirer record + fee rules + a notification adapter. See The two rails.

2 · One correlation ID per transaction

Every payment — CNP or CP — carries a single correlation ID from the rail notification, through the Listener, into the journal, the ledger entries, and the settlement record. This is the thread that makes reconciliation tractable. Design every table and event around it.

Where each piece is documented

Architecture box	Documented in
Hosted Checkout	Hosted Checkout
Dashboard	Merchant Dashboard
Admin Panel + System Control Panel	Vecnet Admin platform
Listener + Webhook Manager	Rails integration
Finanzas	Finances flows
Liquidaciones	Settlements · Cycle engine
Vecnet DB	Data model