Learn about the differences between pending and posted transactions
Pending and posted transactions
There are two types of transactions: pending and posted. A transaction begins its life as a pending transaction, then becomes posted once the funds have actually been transferred. It typically takes about one to five business days for a transaction to move from pending to posted, although it can take up to fourteen days in rare situations.
The pending and posted versions of a transaction may not necessarily share the same details: their name and amount may change. For example, the pending charge for a meal at a restaurant may not include a tip, but the posted version will include the final amount spent, including the tip. In some cases, a pending transaction may not convert to a posted transaction at all and will simply disappear; this can happen, for example, if the pending transaction was used as an "authorization hold," which is a sort of a deposit for a potential future transaction, frequently used by gas stations, hotels, and rental-car companies. Pending transactions are short-lived and frequently altered or removed by the institution before finally settling as a posted transaction.
Note that while transactions will rarely change once they have posted, a posted transaction cannot necessarily be considered immutable. For example, a refund or a recategorization of a transaction by the institution could cause a previously posted transaction to change.
/transactions/get returns both pending and posted transactions; however, some institutions do not provide pending transaction data and will only supply posted transactions. The
pending boolean field in the transaction indicates whether the transaction is pending or posted.
Plaid does not model the transition of a pending to posted transaction as a state change for an existing transaction; instead, the posted transaction is a new transaction with a
pending_transaction_id field that matches it to a corresponding pending transaction. When a pending transaction is converted to a posted transaction, Plaid removes the pending transaction, sends a
TRANSACTIONS_REMOVED webhook, and returns the new, posted transaction. The posted transaction will have a
pending_transaction_id field whose value is the
transaction_id of the now-removed pending transaction. The posted transaction’s date will reflect the date the transaction was posted, which may differ from the date on which the transaction actually occurred.
In some rare cases, Plaid will fail to match a posted transaction to its pending counterpart. On such occasions, the posted transaction will be returned without a
pending_transaction_id field, and its pending transaction is removed.
Handling pending and posted transactions
To manage the movement of a transaction from pending to posted state, you will need to handle the
TRANSACTIONS_REMOVED webhook to identify the removed transactions, then delete them from your records. For detailed instructions, see Transactions webhooks.
Example code in Plaid Pattern
For a real-life example of reconciling pending and posted transactions via the
TRANSACTIONS_REMOVED webhook, see handleTransactionsWebhook.js. This file demonstrates code for handling transaction states in the Node-based Plaid Pattern sample app.