Does it work with the system we already have?
GovtPortal integrates payment acceptance into the municipal systems a city already runs. Connections are built through an API and a backend-as-a-service layer, or through file exchange when a full API is not available. The goal is posting payments back to the system of record so clerks are not reconciling a second spreadsheet.
Payment gateways and processors
GovtPortal connects municipal portals to card and ACH processing, including EMV chip, magstripe, ACH, and hosted online checkout. Processing paths include Fiserv and TSYS. The merchant agreement for a city names which path that city is underwritten for.
Departments clerks ask about
These are the department types GovtPortal is asked to connect. A category is not a claim that every software brand in that category already has a live interface.
- Court and citation systems
- Utility billing
- Property tax
- Permitting and licensing (GovtPermits or a partner system)
- Parks and recreation registration
What “integrated” means for a clerk
Citizen or account details are searchable in the portal. After payment, the transaction is available for deposit reporting, refund, or void from the clerk admin tools. Standalone payment forms are used when there is no system of record to post into.
What a live integration is
A payment is integrated when the clerk can find the person or the account in the portal and, after the card or ACH payment succeeds, see that payment in the system that already owns the balance. Deposit, refund, and void stay in the clerk’s admin tools. If the city has no system of record for that fee, GovtPortal uses a standalone form. Standalone is honest. Calling a standalone form an integration is not.
Connections are built in one of two ways. An API or backend service lets the portal look up a balance and post a payment as it happens. A file exchange is used when the other system can only import a settlement file. Both can be the right design. The proposal should say which one you are buying.
Systems GovtPortal will name
GovtPortal names a third-party system when there is a live install or a written interface for that system. Ask for the reference that matches your software: the product name, the city or county, and whether posting is API or file.
Products on the same relationship are GovtPermits, GovtSites, GovtPayroll, GovtParks, and ParkPay. Processing paths include Fiserv and TSYS. The merchant agreement names the path you will use.
What to verify
- The system of record, the version you are on, and who at that vendor must approve a connection.
- Whether partial payments, convenience fees, and overpayments are accepted by that system.
- How often a file posts, if the design is a file, and what happens to a row the system rejects.
- Who reconciles the processor deposit to the city’s bank account each day.
- What is in scope for launch, and what is a later phase.
Timing
Hosted payments with no foreign system are often live in 3 to 6 business days. An integration waits on credentials, a test account, and the other vendor’s queue. Put that dependency in the project plan so a clerk is not told the portal is late when the billing vendor has not opened the interface.