Citizen-to-Government (C2G) Payments: Examples, Apps, and Implementation

When people pay a tax bill, a fine, or a government service fee, they expect a clear result: the money reaches the right authority, the obligation is marked as paid, and they can move on. A payment that leaves them checking bank statements or contacting support creates more work for citizens and public employees alike. Building effective citizen-to-government (C2G) payments means connecting the act of paying with the public service it completes.

This guide explains how C2G payments work, compares government apps across countries, and sets out the practical requirements for building a reliable payment service. It also looks at SDK.finance, a FinTech software provider that offers a software foundation for building citizen-to-government payment solutions.

What are citizen-to-government payments?

Citizen-to-government payments are payments made by individuals to government bodies to meet an obligation or pay for a public service. Examples include personal taxes, traffic fines, passport fees, and charges for permits.

C2G describes who pays whom. It does not describe a particular technology. The same obligation could be paid at a counter, through a bank transfer, on a website, or in a mobile app. Digital C2G payments make that interaction available through electronic channels.

Payment-system research also uses the term person-to-government (P2G). It is useful when discussing payments by individuals more broadly, including residents who are not citizens. The World Bank includes P2G flows in its guidance on digitising government payments.

C2G vs G2C, G2P, and B2G payments

G2C and G2P overlap: G2P is the broader term because the recipient need not be a citizen. Eligibility depends on the programme.

These flows may share infrastructure, but their user journeys and controls differ. Collecting a permit fee requires matching a payment to an application. Distributing benefits requires identifying eligible recipients and delivering the correct amount. A service supporting both should keep those processes distinct.

Common C2G payment use cases

C2G collections cover several obligations, each with its own reference and completion rules.

Across these examples, connect the money received to the right person, public recipient, and obligation. Payment confirmation alone does not establish that a permit or application has been approved.

How a digital C2G payment works

Consider an illustrative example: a driver pays $3 for a session in a municipal car park. The payment goes to the city government through six connected steps.

1. Create the payment reference

The city’s service identifies the vehicle, parking location, session, and $3 charge. The driver checks the registration number and selected duration before continuing. A payment reference links the charge to this specific session, so two drivers paying the same amount are still recorded separately.

2. Choose the payment method

The driver chooses an accepted payment method, such as a card or bank payment. The checkout shows the municipal parking charge, any additional fee, and the total to authorise. For this example, assume the total is $3, with no extra charge to the driver.

3. Process the payment

The service sends the payment request to its provider. For a card payment, the request passes through the relevant payment infrastructure to the card issuer for authorisation. The driver completes any required authentication, and the provider returns the result. Other payment methods follow their own processing steps.

4. Confirm the payment status

The parking service uses the provider’s response to update the session’s payment status. In this example, a successful result marks the selected session as paid and produces a receipt showing the vehicle, location, amount, and parking period. The driver can then check exactly which session the payment covers.

5. Record the transaction

The system records the session reference, amount, status, and timestamps. The operational record shows which parking session was paid for; the accounting record captures the financial event under the municipality’s accounting policies. Keeping this detail allows staff to retrieve an individual receipt and report parking revenue for a chosen period.

6. Reconcile settlement

The finance team can compare internal records with provider reports and bank settlement records to check the parking revenue received. The $3 payment may appear within a payout containing many parking transactions, rather than as a separate bank credit. GOV.UK Pay’s technical documentation provides a broader example of the payment lifecycle. The reconciliation requirements below explain how to handle differences between these records.

Examples of C2G payment apps across countries

Government payment apps can bring obligations, reminders, and payment options into one place. Their coverage varies by participating authority, user eligibility, and service. The following examples show different approaches rather than a ranking of providers.

DubaiNow: UAE

DubaiNow brings services from multiple organisations into one app. Its C2G functions include paying traffic fines and renewing vehicle registration. Users sign in with UAE PASS to access these services alongside other everyday tasks.

This illustrates a shared entry point for services delivered by different public bodies. DubaiNow also includes private-sector services, so the recipient determines whether a particular transaction qualifies as a citizen-to-government payment.

HMRC app: United Kingdom

The HMRC app focuses on personal tax payments in the United Kingdom. Users can pay Self Assessment and Simple Assessment bills, check how much tax they owe, find their Unique Taxpayer Reference, and set payment reminders.

Its strength is the connection between tax information and payment. People can review their obligations before paying, making the app a useful example of C2G services built around one authority and a clearly defined purpose.

Diia: Ukraine

Diia combines digital documents with public services in Ukraine. Citizens can pay eligible traffic fines and fines for administrative offences through the app, bringing payment into the same place where they access official information.

For administrative offences, users can receive an electronic court decision and pay the associated fine without collecting paper payment details from the court. This shows how C2G payments can connect directly to a legal obligation.

Benefits of digital C2G payments

• Easier access: online and mobile channels let people start payments outside office hours.
• Less manual matching: stable references help staff connect payments to the correct obligation.
• Clearer support: visible payment statuses give residents and staff a starting point for resolving problems.
• More inclusive service: accessible screens and assisted channels help people with different needs.

These benefits depend on the controls and integrations described below. Processing costs and charges to residents also affect whether a service is practical to use.

US federal tax payments in numbers

A March 2026 GAO report records 101.6 million electronic payments and 16.2 million paper payments received by the IRS during the 2025 filing season, through 18 April. Electronic payments represented 86% of the total.

These figures include payments from individuals and businesses. They describe US tax collections during that period, not the global C2G market. The remaining paper payments show why digital services still need processes for other channels.

Key requirements for a C2G payment platform

Payment references and government system integrations

Agree which system owns the amount due and which system decides that an obligation has been paid. These may be different systems, but their responsibilities must be explicit.

A useful payment record connects the government-service reference with the provider’s transaction reference, amount, currency, recipient, and timestamps. Avoid relying on a person’s name alone to match payments.

Integrations should also handle changes, such as an application being cancelled or a payment arriving after an obligation has changed. An API connection is only useful when both sides agree on the meaning of the data.

Payment methods and accessible user journeys

A payment method determines how money moves; a channel is where the person starts the payment. A mobile app is a channel, while a card or bank payment is a method. Offering both a website and an app does not necessarily give users more ways to fund a payment.

• Cards: useful where the service’s provider accepts them. Plan for processing charges, failed authorisations, refunds, and disputes.
• Bank payments: options can include ACH in the US or local bank-transfer services elsewhere. Confirm how references, processing times, returns, and settlement information reach the government system.
• Digital wallets and mobile money: assess these where residents use them and the provider supports the integration. A wallet button may use a linked card rather than a stored balance.
• Assisted channels: counters, kiosks, or supported telephone journeys can help people who cannot complete the online process. Their payments should reach the same obligation and reporting records.

Choose the combination around users and services. Show charges before payment, explain errors plainly, and make receipts retrievable. Do not assume that an app, a bank account, or reliable connectivity is available to everyone.

Reconciliation and settlement visibility

Compare the government-service record, payment-provider record, and bank settlement record. Payment confirmation and settlement are different events: the city may receive the funds later. An internally balanced ledger alone does not prove receipt.

Matching should account for provider fees, refunds, settlement batches, and timing differences. For the parking example, a payment with no usable session reference needs an owner to investigate it before the city can mark the session as paid.

Refunds, duplicate payments, and exceptions

Plan for a driver pressing “Pay” twice, a delayed update, and a provider timeout. A timeout does not prove failure; check the original result before retrying. Where supported, duplicate protection should prevent one request from creating multiple charges.

Distinguish a refund from cancelling an application or reversing an accounting entry. These actions have different effects. Staff should be able to see the original transaction, the reason for a correction, and what remains unresolved.

Security, access controls, and audit trails

Give staff access according to their responsibilities. Someone who checks payment status may not need permission to approve refunds or change accounting rules.

Keep records of sensitive actions and protect personal and payment data throughout the journey. Security, privacy, retention, and payment requirements depend on the jurisdiction and implementation. Provider certifications can support an assessment, but they do not automatically establish compliance for the entire government service.

How to plan a C2G payment implementation

1. Select a pilot service. Choose one with a clear owner, stable payment rules, sufficient demand, and manageable integrations. Record today’s completion rate, support workload, and unmatched payments so the pilot has a baseline.
2. Map the money and data. Identify who calculates the amount, processes the payment, receives the funds, and updates the obligation. Agree the references required for support and reconciliation.
3. Assign responsibilities and budget. Name the government, integration, software, payment-provider, and bank owners. Compare setup and integration costs, transaction charges, support, refunds, and ongoing operation. Decide who bears each cost before procurement.
4. Test failures and accessibility. Include an approved payment during a screen timeout, delayed updates, duplicate requests, pending refunds, and incorrect settlement amounts. Test smaller screens, assistive technologies, and assisted payment routes.
5. Prepare citizen communication. Put the official payment route on bills, notices, and service pages. Explain available methods, charges, deadlines, receipts, and support contacts. Help people recognise the legitimate service before asking them to pay.
6. Measure and expand. Track completion, unmatched transactions, unresolved-case age, manual interventions, and the delay before a service records payment. Use the results to fix the journey before adding departments.

Expansion works best when references, status handling, reporting, and support procedures are consistent. A shared checkout still needs a named owner for exceptions in every participating service.

SDK.finance as a software foundation for Citizen-to-government payment solutions

SDK.finance provides a ready-made software foundation for building services that let individuals pay taxes, fines, licence fees, and other government charges. Its Transaction Platform gives government teams, software development companies, and systems integrators an existing financial backend to build on, so they can focus on the public service, citizen experience, and connections their project needs.

Start with the core payment components

The Platform brings together components that can support a C2G payment service:

• Payment operations and status tracking to manage transactions and help support teams investigate pending, declined, or completed payments.
• Account and wallet management to maintain accounts and balances where the service uses an account-based model.
• Backoffice tools to review payment records, manage staff permissions, and investigate discrepancies.
• 650+ APIs to build citizen-facing applications and connect the payment backend with government systems and financial providers.
• An accounting layer through SDK.finance General Ledger to turn payment events into balanced debit and credit entries under configured accounting rules.

In the parking example, SDK.finance would provide transaction-management components. The city’s system would own the session and charge, and an integration would return the payment result to it. The selected payment provider would execute the external payment.

Connect payments to government services

The implementation team connects the Platform’s payment records to government-service references and builds the required citizen journey. For municipal parking, this means linking each transaction to a session, returning its status to the city, and making receipts available to drivers.

Available integrations provide a starting point. APIs, supported webhooks, and middleware can support additional connections, with development and testing scoped to each system. The government authority defines the charges and service rules; SDK.finance supplies software, while the relevant financial partners provide regulated payment services.

Retain control through source code licensing

Source code licensing suits C2G projects that need control over deployment and long-term development. It enables the government organisation or its appointed technical team to:

• Deploy the licensed software in its chosen infrastructure and control the deployment environment.
• Modify payment workflows to meet the requirements of different public services.
• Build additional integrations with government systems and financial providers.
• Develop citizen interfaces and manage maintenance internally or through a selected delivery partner.

This gives the technical team a foundation it can extend as services change. Modification rights, support arrangements, and ownership of custom deliverables are defined in the licence and implementation agreements.

Reduce the work between concept and launch

An existing backend lets the delivery team focus on service-specific integrations, citizen journeys, and testing instead of rebuilding core payment components. This can shorten development compared with starting from scratch; the advantage depends on functional fit, integration complexity, and provider readiness.

Explore the Transaction Platform to identify which building blocks fit your payment infrastructure and which integrations your project would require.