Transaction Importing

This page details some of the functional requirements for handling imported transactions.

When we receive a webhook with transactions from Plaid, we should store each one as a Plaid.Transaction that belongs to the appropriate Plaid.Account. From there, we'll figure out which Account the Plaid.Account is linked to, and if there is one, we'd create a new Transaction with a foreign-key to that Plaid.Transaction.

Initially with this re-write I was planning on cloning Plaid.Transaction to Transaction, but we'd lose any future updates to that transaction (like when a restaurant pre-charge settles with the tip a few days later, Plaid will update the amount on that transaction).

New transactions

Transaction importing from Plaid requires some processing. There's two layers of processing I think we want to start with:

1. Duplicate transaction detection

Sometimes Plaid will send duplicate transactions. We want to weed them out if the transaction has the exact same title, date, and amount, but separate IDs. By "weed them out" I think we want to simply not link the Plaid.Transaction with a Transaction. This will occasionally result in a few false-positive detections, but in my year of monitoring Plaid imports, I don't think a false-positive happened once for me.

2. Automatic historical renaming

When a transaction comes in with a name of AMAZ_0000, we should check for any older Plaid.Transactions where the user gave the transaction a custom name (like Amazon). If we find one, we should automatically rename the Transaction's name from AMAZ_0000 -> Amazon, and we should note the original_name so the UI can indicate it was renamed. Sometimes renames go haywire and it's nice to see the original name to fall back to if necessary.

Transaction updates

Plaid will send updates to existing transactions that reflect changes in amounts and/or pending status (and maybe other fields). We should make sure to update the Plaid.Transaction with those changes so they're reflected in the linked Transaction.