Is there a way to throw an error on transaction commit, if a specific stored procedure was not called as part of the transaction? I want a transaction commit to fail if this special stored procedure was not executed before the commit.

I have achieved this in the past using SQL Server (I forget how), and it this special stored procedure wrote various meta data about the transaction commit (eg, the commit time) to an audit table. This was enforced at the database level so that if a user or an application did not call this special stored procedure before the transaction commit, an error was thrown.

We added an additional control to enforce that changes to specific tables could not be made outside of a transaction.

This allowed us to track changes to data even if applications did not behave as intended. 

I want to achieve the same thing with PostgreSQL.
There are several ways to approach this.

The first way is to just use triggers -- which operate inside the same transaction. When the transaction commits, the changes across all tables will be visible to others.

If you really don't want to use triggers, then you could use LISTEN / NOTIFY. You need one process that runs all the time that executes a LISTEN.

Then inside your transaction (maybe from a trigger) you call NOTIFY. The listning party won't be notified until after the transaction commits. It can receive a payload (maybe the IDs of the changed records?) and if it queries for that data it will have been committed and therefore be visible. Yes, the syncing that you want to be done will be done asynchronously so there will be a slight delay before everything is in sync again -- how long this takes depends on the complexity of your logic.