Skip to main content
A core transaction is a single ledger entry that changed a core balance. Lead creates them: when a payment posts, when interest or a fee is applied, when funds sweep. You read them. There is nothing to create and nothing to reverse. Corrections are new, offsetting entries with their own IDs. A core transaction has one state, posted. It exists only once it has affected the balance. There is no pending state and no status field.

​
Types at a glance

type names the rail or mechanism that created the entry. ACH, checks, wires, instant payments, blockchain payments, internal transfers, fundings, and receivable sales each have a matching payment object on the Lead platform. Interest, fees, sweeps, Lead-generated entries, and legacy banking activity are posted by Lead and have no payment object. The Core Transaction Object lists every value.

​
From a payment to its ledger entries, and back

The join works in both directions.
  • Payment to ledger. Once a payment posts, the payment object carries the IDs of the core transactions it produced, in a shape that fits the rail.
  • Ledger to payment. Read type, then call that rail’s list endpoint with core_transaction_id={id}. One core transaction can map to many payments, for example one settlement entry covering a batch of ACH entries.
A core transaction can exist before the object it links to is visible on its own endpoint. This is expected. If your workflow needs both, wait for the payment object’s posted webhook rather than polling the core transaction list.

​
Reading core transactions

List entries for one balance, filtered by type and a created_at window, or retrieve one by ID. Core transactions do not emit webhooks today, so poll the list with a created_at window at whatever cadence your reconciliation runs. A suite of core transaction webhooks is planned; see Banking Infrastructure.

​
In this section