What is a parent transaction?
Parent transaction
A parent transaction is the earlier record that a later record points to. Ledgers that do not edit history create a new row for each new state. The parent field is the link. Follow it and you get the lineage of a transfer.
How does a parent transaction work?
The first record you create has no parent. Each later state stores the id of the record that produced it. A queued transfer is the parent of the applied one. An inflight transfer is the parent of the commit or the void. A refund points at the original applied transfer.
Bulk, split, and scheduled work use the same link. The batch or the schedule is the parent. Each child is a real transaction you can query on its own.
Why not update the same row?
If you overwrite status on one row, you lose the history of how the transfer got there. A parent chain keeps every state. You can answer “what was queued,” “what was held,” and “what was applied” without a separate audit table.
Parent transaction vs reference
A reference is your idempotency key. A parent is the ledger’s link between states. You choose the reference. The ledger writes the parent. You need both. The reference stops a double submit. The parent reconstructs the path.
In Blnk every new state stores parent_transaction. Search by that field to find the next record after a queued or inflight id. Refunds, splits, and schedules use the same chain. See parent transactions.