COIN operated digital payments hub

A hub system for securely managing an exchange of data between external systems of record about a payment event, such that changes in status are propagated to each system of record, comprising:

• one or more first communications servers configured to securely receive a request, via an application programming interface (API) using native semantics of a payee or an external payment system, to initiate or update the payment event by providing data about the payment event including one or more of:
• participant identifying data of a payer, one or more financial account numbers of the payer, one or more monetary amounts from the payee, or a requested status of the payment event within a destination system of record;
• wherein the destination system of record is an external billing, external payment, or other external system of record used by the payee to determine amounts of money owed to the payee from the payer for various commercial activities;
• the one or more first communications servers configured to translate, via the API, the data about the payment event from the native semantics of the request into a predetermined structure with common semantics;
• a secure vault, including one or more first processing servers, operatively coupled to the one or more first communications servers configured to securely store said data about the payment event within a database, wherein the secure vault is cryptographically secured;
• one or more connectors, including one or more second communication servers, operatively coupled to the secure vault, configured to:
• connect to the external systems of record, wherein each of the one or more connectors translates at least a first portion of the data about the payment event to a formatting and native semantics of the respective external system of record from common transaction semantics and formatting of the hub system, and translates at least of portion of a response from the respective external system of record, and
• securely communicate at least a subset of the data about the payment event to the external systems of record using the formatting and native semantics of the external systems of record, and
• record at least a subset of the response from the external systems of record in the common transaction semantics and formatting of the hub system;
• a transaction server, including one or more second processing servers, operatively coupled to the one or more first communications servers, to the secure vault and to the one or more connectors, configured to:
• store a representation of one or more statuses of each external system of record participating in the payment event,
• create and maintain accounting ledgers representing values sent or received with each system of record,
• store one or more statuses of each transaction during the payment event,
• perform accounting of money movement during the payment event using an assigned accounting,
• evaluate the transactions required to conform each accounting ledger, and associated connected system of record, to corresponding one or more statuses for the payment event, and
• initiate the transactions to propagate changes to the one or more statuses of each external system of record participating in the payment event via their respective associated connectors;
• and
• the secure vault, the one or more connectors, the transaction server, and the one or more first communications servers are configured to:
• process said data about the payment event, wherein processing comprises:
• assigning a complete transaction identifier to the payment event which enables a single reference to each of:
• the payment event, the one or more associated accounting ledgers, the one or more statuses of each external system of record participating in the payment event, and the status of the payment event;
• determining the number of accounting ledgers involved in the payment event based on the external systems of record participating in the payment event and a nature of the payment event;
• creating one or more accounts, associated with the external systems of record participating in the payment event, within the one or more accounting ledgers;
• making ledger entries in the one or more accounts within the one or more accounting ledgers from one or more monetary amounts identified in the data about the payment event received from either an API request or a connected system of record;
• and
• determining whether the one or more accounts in the one or more accounting ledgers balance using one or more of flow path or double entry accounting;
• determine a flow path of funds amongst the determined accounting ledgers in order to complete the payment event, wherein the flow path comprises a directed acyclic graph (DAG), the DAG comprising a plurality of vertices and a plurality of edges, with each of the plurality of edges directed from one of the plurality of vertices to another, such that there is no way to start at a vertex and follow a consistently-directed sequence of the plurality of edges that eventually loops back to the vertex;
• maintain the status of the payment event as reflected by a status of at least the destination system of record, a source system of record, each associated account, and associated ledger entries, including whether each such associated account and associated ledger entries are balanced when using one or more of flow path or double entry accounting;
• wherein the source system of record is an external payment system of record;
• encrypt a second portion of said data about the payment event on a condition that the second portion of said data about the payment event is determined to be sensitive;
• translate at least a subset of the data about the payment event from the common transaction semantics of the hub system to native semantics used by each external system of record via a respective API of the respective external system of record;
• monitor an updated status of the payment event in the source system of record, via a source connector, and the destination system of record, via a destination connector;
• initiate transactions with the source system of record and the destination system of record based on the status, or changes in status, of the payment event as maintained by the transaction server;
• and
• translate, after processing by the rest of the hub system, the common transaction semantics of the hub system into native semantics of the payee by way of the API, and upon the conclusion of operations of the rest of the hub system, to return a response using the native semantics of the payee and a format of the payee.