Accepting online payments: merchant services, gateways, and PCI scope

Reference article · 5 min read

Almost every agency that collects money eventually collects some of it by card. Utility bills, property taxes, permit fees, and parking citations all move through the same chain: a payment page, a gateway, a merchant account, and a bank deposit that someone in finance ties back to a receivable.

The point worth understanding early is that the vendor's integration design, more than agency policy, sets the agency's PCI DSS scope. A flow where card numbers never touch agency systems produces a short annual self assessment. A flow where agency controlled code renders the card entry form produces a much longer one, with secure development and penetration testing attached.

The pieces behind an online payment

Merchant account. An account at an acquiring bank where card funds settle, obtained through the agency's banking contract, a cooperative contract, or the payment vendor.
Acquirer and processor. The institutions that carry authorizations to the networks, settle funds, produce the merchant statement, and handle disputes.
Payment gateway. The layer that captures the payment instrument, routes it to the processor, returns an approval or decline, issues tokens, and supports refunds and recurring schedules.
Merchant of record. Some vendors place the agency on its own merchant account; others aggregate many agencies under their own as a payment facilitator. That changes who holds funds before deposit, how transparent pricing is, and how public funds deposit rules apply.

How the integration sets PCI scope

PCI DSS applies to any organization that stores, processes, or transmits account data or can affect its security. It is enforced through card brand and acquirer contracts rather than by a single federal statute, though some states reference it in law or treasury policy. Most agencies validate with an annual self assessment questionnaire, an attestation of compliance, and quarterly external scans by an approved scanning vendor.

Common patterns, least to most scope:

Full redirect. The payer leaves for a page served entirely by the provider. Smallest footprint and the usual path to SAQ A.
Provider served iframe. The agency page embeds an inline frame delivered by the provider. Also commonly SAQ A.
Hosted fields. Card fields belong to the provider but sit inside an agency page. Eligibility is fact specific.
Direct post from an agency form. Agency code renders the card field and posts to the gateway, which is SAQ A-EP territory and many more requirements.
Card data through agency servers. Server to server calls carrying the card number bring SAQ D and the full standard.

Scope does not stay inside the website. Counter terminals, clerk virtual terminals, telephone and IVR payments, call recording, and card numbers arriving by paper or email all pull requirements in. Tokenization shrinks what is left, because a token replaces the stored card number. Requirements change between versions of the standard, so confirm the current questionnaire with the acquirer.

Who pays the processing cost

Absorbed by the agency. Fees are budgeted as a cost of collection. Ask the acquirer whether transactions qualify for the card brands' government, tax, or utility interchange programs.
Convenience or service fee. The payer covers the cost, within limits set by card brand rules and state law. The brands run programs for government and education merchants that require registration and clear disclosure before the payer commits. A surcharge is a different practice: tighter limits, restricted in some states, and not permitted on debit.
Vendor collected fee. The vendor charges and keeps the fee, so the agency pays little directly. It is still a contract of real value: keep audit rights, fee change approval, and disclosure language under agency control.
ACH and e-check. Bank debits usually cost far less per item. NACHA rules require account validation for first use consumer internet debits, and returns arrive days after the payment appeared to succeed.

Reconciliation with the finance system

Decide early whether the processor deposits gross and bills fees monthly or nets fees from each deposit. The two post differently. Require a daily settlement file that ties each deposit to individual transactions, and carry one reference identifier through the payment record, receipt, and ledger posting. Map each payment type to the correct fund and revenue account, including partial payments and reversals. Keep refund authority separate from cash receipting, and export transaction history into agency custody so retention does not depend on a vendor portal.

Refunds and chargebacks

Define who may issue a refund, up to what amount, and whether the convenience fee returns with the principal. Card refunds go back to the original card, so the agency still needs a check process for closed accounts. A chargeback is different: the cardholder disputes the charge with the issuer, the acquirer debits the merchant account, and the agency has a limited window to respond with evidence, so keep timestamps, authorization results, and delivery proof.

What to ask before signing

Which questionnaire will our integration support, and may we see your attestation of compliance and responsibility matrix?
Who is the merchant of record, and where do funds sit between authorization and deposit?
What is the full price, including gateway, statement, tokenization, and chargeback fees?
If we leave, do we get tokens, payment schedules, and transaction history in a usable format?
Does the payment page meet current accessibility standards, with a conformance report?
What liability do you accept for a payment page compromise, and how fast will you notify us?
What is settlement timing by payment method, and what reporting supports reconciliation?

Put the answers in the contract rather than the proposal. The terms that matter most later are fee change limits, token portability, audit access, and an exit that leaves recurring payers enrolled somewhere.

HQT works with state and local agencies on payment integrations, finance system interfaces, and the surrounding compliance work.

Frequently asked questions

Which PCI self-assessment questionnaire does an agency need for online payments?

It depends on how card data is captured, not on the size of the agency. A page that redirects the payer to the provider, or embeds a provider served iframe, generally points to SAQ A. A page where agency code renders the card field and posts it to the gateway generally points to SAQ A-EP, and card data passing through agency servers points to SAQ D. Other channels such as counter terminals and phone payments can change the answer, so confirm the correct questionnaire and the current version of the standard with your acquirer or a qualified security assessor.

Is PCI DSS a legal requirement for government agencies?

PCI DSS is a card industry standard enforced through contracts with the card brands and the acquiring bank, rather than a single federal law that applies to public agencies. Some states nonetheless reference it in statute, administrative rule, or treasury and banking policy, and merchant agreements almost always require it. Agencies should read their merchant services agreement and confirm state obligations with counsel.

Can a public agency charge a convenience fee for card payments?

Often yes, but the practice is limited by both card brand rules and state law. The card brands operate specific programs for government and education merchants that typically require registration, clear disclosure before the payer commits, and consistent application across qualifying transactions. Surcharging is a different practice with tighter restrictions and is not permitted on debit transactions. Confirm the current brand rules with your acquirer and the statutory authority with counsel before adopting a fee.

Should we use our bank's merchant services or the payment module from our software vendor?

The deciding factors are usually PCI scope, pricing transparency, and reconciliation. A vendor module that keeps card data entirely on its own hosted pages can reduce compliance work and post cleanly into the finance system, while a direct merchant account with the agency's bank often gives clearer pricing and direct control of settlement. Ask who is the merchant of record, how fees are disclosed, and what the daily settlement file looks like before deciding.