Middleware service that routes ATM and POS transactions between terminals and core banking systems, with API-key auth, per-IP rate limiting, and structured logging.
Terminals shouldn't talk to a core banking system directly: every device would need credentials, and one misbehaving terminal could flood the core. This gateway is the layer in between: an ASP.NET Core API that authenticates each terminal, applies rate limits, routes transactions to the core banking system, and logs every request with its timing. The walkthrough below shows the service handling three request types.
The service boots as a standard ASP.NET Core API and exposes a test endpoint that monitoring can hit to confirm the gateway and its core banking connection are alive, answering in milliseconds.
A withdrawal arrives with the terminal's API key. The gateway validates the key, identifies the terminal, routes the transaction to the core banking system, and returns the result with the whole round trip logged and timed.
Balance inquiries, withdrawals, and the rest of the ATM operations flow through the same authenticate-route-log pipeline, so adding a transaction type means adding an endpoint, not re-solving auth and logging.
Requests without a valid API key are rejected with a 401 before they ever reach the core. Per-IP rate limiting caps how fast any single source can send, so a runaway or abusive terminal is throttled instead of degrading the system for everyone.
The gateway ships as a container: one docker compose command brings it up listening for terminals, with the health endpoint confirming the service and its core banking connection before traffic hits it.