The two rails

In Tonder's own books, an "acquirer" is a downstream processor it receives funds from (kushki, unlimit, stp, …). In Vecnet's books, the acquirers are the rails Vecnet settles against: tonder and menta. That is the clean mapping — and it is exactly what acquirer-as-plugin means here.

How finances sees each rail

Vecnet ACQUIRER	Rail	Capture model	Notifies Vecnet via
tonder	Online / CNP	Hosted Checkout + Tonder Lite SDK v2.0 → Tonder API	Tonder Backend → Transaction Notification → Listener
menta	In-person / CP	Terminal POS → Menta API	Menta Backend → Transaction Notification → Listener
(future)	any	plugin	new notification adapter

Vecnet itself is the PLATFORM entity (the equivalent of Tonder's T1). Use V1 as the platform entity id throughout Vecnet.

Acquirer-as-plugin

One abstraction, many rails. The finances core never names a specific rail; it operates on the ACQUIRER entity and the per-rail config in the rails registry.

Adding a third rail

A new rail is: one rails row + its fee rules + a Listener adapter. No schema change, no core-flow change. The dashed path above is all that a new rail adds.

Rail-specific data richness

The tonder rail is card/CNP-rich — it populates card_brand, bin, 3ds_outcome, and guardian_decision. The menta POS rail is card-present and will not populate every fraud field. Status / acceptance / volume metrics span both rails; card-network and 3DS metrics are mostly the tonder rail. This shapes the Dashboard metric catalog.