%402x.svg)
No results.
Teller Government Cashiering extends through three interfaces layered on a single shared code base: .NET plugins for deep in-process behavior, a REST API for external system-to-system exchange, and a SQL Query API for read access to Teller data. Because every agency runs the same core product and configures behavior through these interfaces, Teller supports 96+ third-party integrations in production without forking the software for individual customers.
Teller is multi-tenant SaaS. Every government client runs the same version of the same code, hosted on AWS. Customization happens through configuration and the three extension interfaces rather than through custom branches of the source.
That distinction matters more than it sounds. Many legacy government systems accumulate one-off code forks: a custom build for County A, a slightly different build for City B. Over years, those forks drift apart, and upgrading any one of them becomes its own project. A single code base avoids that trap. When Teller ships an improvement, every agency gets it, and no customer is stranded on an unmaintainable variant.
The integrations are the moat, but the single code base is what keeps that moat maintainable. Extensibility that forks the product is a liability, not an asset.
The plugin model is the deepest form of extension. Plugins are .NET components that run inside Teller and hook into the receipting workflow at defined points. They handle the logic that has to happen in-process, during a live transaction at the counter.
A typical plugin does one of two things:
Each integration to an ERP, tax system, utility billing platform, or permitting system like Accela is generally implemented as a plugin (or a small set of them). Because plugins are discrete components that attach to the shared core rather than modifying it, adding a new integration does not touch other customers' behavior. That is the mechanism behind supporting a broad catalog of integrations without a version explosion.
The REST API is for system-to-system communication where an external application needs to initiate or read a Teller transaction over the network. Where a plugin runs inside Teller reaching out, the REST API is the front door for other systems reaching in.
Common uses include:
REST is the widely understood standard for this kind of exchange, which keeps integration work predictable for the teams on both ends. It is also how Teller's own modules and partner systems talk to the core over standard web protocols rather than proprietary connectors.
The SQL Query API provides structured read access to Teller data. It exists for reporting, reconciliation, and analytics work that needs to query transaction, receipt, and deposit records directly rather than through a screen or a fixed report.
Finance and audit teams tend to be the beneficiaries here. An auditor may want to pull every receipt for a date range against a particular fund. A finance office may want to feed cashiering data into a separate data warehouse or a general ledger reconciliation routine. The SQL Query API supports those read-oriented needs without requiring anyone to write into the core tables directly, which keeps the transactional record clean.
The three interfaces are not interchangeable. Each is built for a different kind of interaction, and choosing the right one keeps integrations simple and stable.
A single payment often uses more than one at once. Picture a resident paying a utility bill at the counter: a plugin pulls the balance from the utility billing system, the payment is taken, a plugin posts the receipt back to A/R, and later a finance analyst uses the SQL Query API to reconcile the day's deposits against the general ledger. Same transaction, three interfaces, each doing the job it is designed for.
Integration breadth is easy to claim and hard to maintain. The reason Teller can run 96+ integrations in production, including all major government ERPs such as Workday, Oracle, JD Edwards, NetSuite, PeopleSoft, and SAP, is that none of them requires a custom fork of the product.
This is part of the benefits of an IT-light solution like Teller for the agencies that adopt it. The heavy engineering, the plugin development and integration work, sits with Teller's implementation team rather than landing on a government IT department. Local staff configure and operate; they do not have to build and maintain the connective tissue.
For a technical evaluator, the takeaway is straightforward. Extensibility here is a design choice with a clear boundary: extend at the edges through defined interfaces, never by modifying the core. That boundary is what lets a purpose-built government cashiering layer grow its integration footprint over time without turning into a maintenance problem.
