Collecting payments for the public sector. 7 chapters and a final quiz.

Chapter 1. Classifying the flow and finding the rule that mandates it.

A public-sector collection project starts with reading, not with integration. The question is not which provider offers the best API. It is whether the channel is open, and for a large share of public payment flows it is not. The applicable rule then designates a platform that payments must go through, a standard notice format, and sometimes a mandatory debt identifier. The provider complies or it does not operate.

The first hour of the project therefore goes to four questions. The first two establish the direction of the flow and the party facing the agency. The next two identify the rule that governs the channel and the proof you must produce once the transaction is complete. A project lead who answers all four already knows what they can promise the public-sector client. One who starts with the provider’s technical documentation will discover the constraint during acceptance testing, a quarter later.

Three overlapping regimes that half of all projects confuse

• Accepting means being authorized to offer a payment instrument to the public on behalf of an agency. It depends on the provider’s license and its membership in the national program.
• Certifying means producing proof that the revenue was received: a timestamped receipt, a serial number, legally binding archiving. It often falls under a separate tax law, with its own authorization.
• Collecting means receiving the funds, holding them, and paying them over to the public accounting officer. It depends on payment institution or e-money institution status, and on the local safeguarding regime.
• A project that has covered only two of these three regimes is not compliant. It passes technical acceptance testing and fails the compliance review.

That leaves finding the rule, and three sources cover almost every case. The country’s official gazette publishes the decrees and budget acts that create the program. The central bank’s website collects the circulars, fee caps, and membership requirements imposed on providers. The tax authority publishes its notices, rollout schedules, and payment notice specifications. These documents are free, dated, and legally binding. Reading them takes a few hours per market; skipping them costs a quarter of project time.

Chapter 2. Connecting: mandatory hub or biller network.

Two architectures dominate connections to public-sector debts. The first places a government platform between the agency and the industry, and pagoPA, operated since 2016 by PagoPA S.p.A., is its most mature form. The second publishes the debt on a biller network open to every channel, such as Bharat Connect in India, JomPAY in Malaysia, or CBILL in Italy. The integration work differs, but the reconciliation principle stays the same.

Reconciliation is designed at project kickoff

{
  "debt_id": "IUV-302001234567890123",
  "ente_creditore": "0000123456",
  "status": "settled",
  "amount_due": 12450,
  "amount_received": 12450,
  "currency": "EUR",
  "channel": "public_app",
  "receipt": { "type": "ricevuta_telematica", "received_at": "2026-08-03T09:41:07Z" },
  "idempotency_key": "IUV-302001234567890123:attempt-2",
  "rail_reference": "TRN-8841-AC",
  "remitted_on": "2026-08-05"
}

The business model deserves a separate note, because it surprises teams coming from merchant acquiring. On a mandatory hub, every certified member can access the debt, with no negotiation and no exclusivity. Competition therefore shifts entirely to the fee shown to the payer and the quality of the channel. A business plan built on exclusive access does not exist; one built on volume and unit cost holds up.

Chapter 3. Collecting taxes and fines: building a payable notice.

In public-sector collection, the product is the notice; the checkout flow merely pays it. A payable notice carries four non-negotiable elements: a unique reference, a legally binding amount, an identifiable payee, and a due date. The channel comes second. The agencies that got collection right standardized the notice first, then let the market connect as many channels to it as it wanted.

Anatomy of an EMVCo merchant QR code

ID  Len Value                  Field
00  02  01                     Payload Format Indicator
01  02  12                     Point of Initiation Method (11 static / 12 dynamic)
26  ..  ....                   Merchant Account Information — national rail
52  04  9311                   Merchant Category Code — 9311 Tax Payments
53  03  978                    Currency, ISO 4217 numeric
54  06  124.50                 Amount due
58  02  XX                     Country code
59  21  CITY TREASURER OFFICE  Payee name
60  07  ANYTOWN                Payee city
62  ..                         Additional Data Field Template
    01  14  2026-AV-004821     Bill Number — the notice reference
    05  09  LEVY-2026          Reference Label
63  04  A13F                   CRC

The declared length counts the characters of the value, not of the header:
“59 21” is indeed followed by 21 characters. A one-byte discrepancy invalidates the rest
of the string, because the reader decodes every following field at the wrong offset.

Source of the field identifiers: EMVCo, “EMV QR Code Specification
for Payment Systems — Merchant-Presented Mode,” v1.1, November 27, 2020.

Two mistakes recur with this template, and both come back to bite at reconciliation. The first is generating a static QR code for an individual debt. There is no amount, so the payer types it in, and every discrepancy becomes a manual investigation. The second is putting the notice reference in the payee name, a field many apps truncate on screen. The sub-field designed for it is the Bill Number, inside the Additional Data Field Template.

Choose the code together with the creditor agency, not on your own. It determines the interchange category, how issuers assess risk, and whether a convenience fee can be charged to the payer. The EMVCo specification handles that fee in fields 55, 56, and 57: a tip or convenience indicator, a fixed amount, and a percentage. A notice that shows the fee only after confirmation exposes the agency to a challenge.

Chapter 4. Paying out benefits: channel, rejects, and the last mile.

Sending a payout file is the easy part; the hard part comes after. You have to reach hundreds of thousands of unbanked beneficiaries, on a fixed date, with a usable audit trail. Here the technical success rate measures only whether the credit was executed, not whether the beneficiary actually received it. A credit posted to a dormant wallet, in a village where no agent has cash, has paid out no aid and triggered no reject. Choose the channel based on that constraint, never on cost per transaction.

Budget the reject rate up front instead of discovering it

• Unregistered alias. The beneficiary never linked their identifier to an account. Rejected at resolution, before any funds move.
• Dormant account or wallet. The credit goes through, but the beneficiary never sees it. There is no reject: it is a silent payout, detectable only by tracking withdrawals.
• ID tier limit. An account opened with simplified KYC declines any amount above its tier’s limit. AfricaNenda’s SIIPS 2025 report identifies this as a direct obstacle to scaling up government payments.
• Recycled number. A mobile number reassigned by the carrier sends the benefit to someone else. Check the date of last activity, not whether the format is valid.
• Death or exit from the program. The eligibility file and the payment database drift apart. Reconcile the two before each cycle, never after.

cycle:
  value_date: 2026-09-05           # date funds are promised to the beneficiary
  issue_window: 2026-09-03         # D-2, to absorb a full rerun
  expected_volume: 1_840_000
  est_withdrawal_peak: 0.62        # share withdrawn within 48 h of the credit

resolution:
  every_cycle: true                # never cache the ID-to-account mapping
  keep_response: true              # timestamped, for the audit trail and disputes

rejects:
  budget: 0.035                    # 3.5% provisioned, measured on the previous cycle
  retry: D+2                       # a single retry, then switch to the fallback channel
  fallback_channel: licensed_counter

last_mile:
  min_agents_per_municipality: 2
  min_agent_liquidity: 4x_average_amount
  max_withdrawal_fee_pct: 1.0      # above this, the benefit is cut and the goal is missed

One last reflex prevents projects that are dead on arrival. A country’s dominant channel cannot simply be copied into another. Vodacom shut down M-Pesa in South Africa in June 2016, with about 76,000 active users against an initial target of 10 million (Vodacom, 2016). The model came from an underbanked market and landed in one where people already had bank accounts. Every benefit payout program is exposed to the same mismatch between the rail chosen and what the target population actually uses. Choose the channel based on the measured target population, not on the rail’s international reputation.

Chapter 5. Wiring up national ID addressing.

Several countries have dropped the bank-details database from their benefit payments. The payment instruction goes to a public identifier, and the rail finds the account mapped to it. The agency no longer has to keep bank details up to date for each beneficiary, but in exchange it no longer knows which account gets credited. That transfer of control is the subject of this chapter, and it is solved by design, never by customer support.

Four design rules that prevent litigation

• Resolve on every cycle; never cache the mapping. The mapping is declarative and can move without the beneficiary asking for it.
• Archive the resolution response with a timestamp. It is the only record that shows where the money was sent, and why.
• Show the resolved name to the originator before sending, where the rail allows it, and keep a record of the confirmation.
• Set up a dedicated dispute procedure for payments that land in an unwanted account, separate from regular payment support.

Where no identity registry can be queried online, alias-based addressing is out of the program’s reach, and accounts opened with simplified KYC stay stuck at the lowest tier of regulatory limits. AfricaNenda’s SIIPS 2025 report, published on November 13, 2025, with the World Bank and UNECA, calls this a direct obstacle to scaling up government payments. Identity is not a peripheral component of the system. It is what makes the system possible.

Chapter 6. Selling to government: proper invoices and the cost of delay.

A government contractor does not face non-payment risk comparable to ordinary B2B. The government pays. It pays late, on a schedule set by law rather than by the supplier’s terms of sale. Working capital needs must therefore be calculated from the applicable law and the buyer’s observed behavior. Two parameters drive everything: whether the invoice is proper, and the payment period that runs from it.

The most operational difference between regimes is not the number of days. It is who has to act. In the US, the Prompt Payment rules pay the interest penalty automatically, without any claim from the supplier (FAR 52.232-25; 5 CFR Part 1315). In the EU, Directive 2011/7/EU creates a right that the creditor must exercise: interest at the reference rate plus at least eight percentage points, and a flat recovery fee of at least €40 (Articles 4 and 6). Few suppliers exercise it against a public client whose next contract they hope to win.

Costing the delay in two calculations

ASSUMPTIONS (replace with your actual data)
  invoice amount               F  = EUR 250,000
  statutory payment term       Dl = 30 days
  actual payment time          Dr = 74 days           # measured over 12 months of history
  annual cost of financing     t  = 6.5%              # your credit line
  reference rate + 8 pts       i  = 11.15%            # reference rate assumed
                                                      # at 3.15%; Directive 2011/7/EU

1. CARRYING COST OF THE DELAY (what the delay costs you)
   Cp = F x t x (Dr - Dl) / 365
   Cp = 250,000 x 0.065 x 44 / 365            = EUR 1,958.90

2. STATUTORY INTEREST OWED (what the delay is worth, if you claim it)
   Il = F x i x (Dr - Dl) / 365  +  flat fee
   Il = 250,000 x 0.1115 x 44 / 365  +  40    = EUR 3,400.27

3. TAKEAWAY
   The law covers the carrying cost, and more. The difference is not a windfall:
   it is the price of claiming, which most suppliers choose to forgo.
   Model it in the bid, line by line, before you submit your price.

One distinction closes the chapter, and it regularly gets lost in scoping meetings. The semantic standard describes what the invoice contains; the transport network describes how it reaches the buyer. Directive 2014/55/EU requires contracting authorities in the EU to receive and process invoices that comply with the European standard. It does not designate any network. Peppol, launched as an EU pilot project in 2008 and governed by OpenPeppol AISBL since 2012, is one; Italy mandates its own, the Sistema di Interscambio. An invoice that is fully compliant semantically still goes nowhere on a channel the receiving government does not accept.

Chapter 7. Accessibility and inclusion: the duty to serve everyone.

A merchant that loses 2% of its visitors loses 2% of its revenue. A government agency that loses 2% of its users misses its policy objective and leaves a debt unpaid. The other party can neither go elsewhere nor walk away from the transaction. Accessibility is therefore not a finishing touch on the public payment journey. It is a compliance requirement, backed by dated legal texts and enforceable deadlines.

Five criteria that payment journeys fail

• 2.2.1 Timing Adjustable (Level A). The payment session expires with no option to extend it. A slow user loses their input and their notice reference.
• 3.3.8 Accessible Authentication (Minimum) (Level AA). The one-time code field blocks paste, forcing users to transcribe the code.
• 3.3.7 Redundant Entry (Level A). The next step asks again for the notice reference the user has already entered.
• 2.5.8 Target Size (Minimum) (Level AA). The button that confirms the amount is too small to be a reliable touch target.
• 3.2.6 Consistent Help (Level A). The help link moves between the notice page and the payment page.