Government payments start with a bill, not a transfer

An account number is not a revenue obligation

A generic transfer proves that funds moved to an account. It does not, by itself, prove which tax, permit, fee, ministry, service, or citizen obligation was settled. Those meanings are often reconstructed later through brittle references and manual matching.

The Government Payments gateway takes the opposite position. The obligation exists first. A revenue authority records a bill with an external invoice identity, revenue classification, amount, currency, and destination. The payment rail then verifies and discharges that specific object.

Operating principleThe bill supplies meaning; the payment supplies finality.

Verification becomes a control point

Verification is not a cosmetic name lookup. It confirms that the bill exists, remains payable, matches an active revenue-account configuration, and can return normalized fields to the sending bank before the citizen approves payment.

Confirmation then checks the financial instruction against the recorded obligation: amount, currency, creditor account, identifiers, and category purpose. A mismatch is rejected before the platform records success.

• Bill creation is idempotent by authority and external invoice ID.
• Payment confirmation is idempotent by transaction ID.
• Voided or already-paid obligations cannot silently become payable again.
• Revenue-account configuration binds service, MDA, currency, and destination.

The integration contract crosses institutions

The public implementation shows the contract extending into SIPS Connect: invoice ID, UPR, bill reference, MDA metadata, and payable amount move through verification and payment payloads.

That is the architectural point. P2G cannot be solved inside one gateway. The semantic contract must survive the revenue authority, participant CoreBank, integration layer, national switch, and reconciliation feed.