Emit a per-transfer signal so incoming transactions can be reacted to (in-game chat notifications, websocket feeds, etc.).
Grounded: Treasury fires no per-transfer event — only TaxCycleEvent (see tasks/TaxCycleTask). TreasuryApi.transfer(...) completes silently, so nothing can react to a firm/player receiving money.
Add a Bukkit event (e.g. TransferEvent carrying from/to account ids + amount + reason) fired after a successful ledger transfer, and/or a websocket feed for external consumers. Unblocks PAR-56 (notify online firm employees in chat on incoming transfer) and the event-driven path for PAR-57.
Cancelled. The external-consumer half (a feed/webhooks for reacting to ledger transactions out-of-process) shipped as PAR-151 — cursor pull endpoint + HMAC-signed webhooks, with self-service config (PAR-153), Discord embeds (PAR-155), and admin management (PAR-160). The remaining in-game TransferEvent idea isn't being pursued: its main consumer, in-game transaction chat notifications (PAR-56), already shipped via a direct call from the pay handlers (on the PAR-94 firm-notification service), so a cross-plugin Bukkit event isn't needed.
Correction to the note above: the actual ask was an HTTP websocket feed for external consumers. That's redundant now that webhooks (PAR-151) exist — webhooks are the right way to push ledger transaction events out-of-process. Cancelled as superseded; no websocket needed.
Code context — There's no websocket / transaction streaming in business or treasury today; transfers go synchronously through
TreasuryApi.transfer, and the only async hook isTaxCycleEvent.This belongs at the Treasury /
treasury-rest-apilayer, not business (the ledger is Treasury's system of record). Realistic shape: an SSE/WebSocket intreasury-rest-apitailing the transaction table, or a new Treasury per-transfer event with an outbound publisher; business-rian would only be a consumer. Confirm scope/owner — pairs with PAR-56 (both want a transfer event that doesn't exist yet).