Feature request: match Amazon gift cards and allow recording gift card txns

[duncanka]

First off, thanks so much for this fantastic tool!

I've noticed that transactions often fail to match if a gift card was used to pay part of the price. It seems like it should be possible to handle this case with the following procedure:

1. Notice when the "Payment Instrument Type" column in the orders CSV includes "Gift Certificate."
2. If any rows do match, scrape the gift card activity page for gift card transactions between the dates specified by the user.
3. Add the amount from the gift card to the order amount when looking for a match.

It would be extra-cool to add a flag/option to add the gift card transactions to Mint as cash transactions. Unfortunately, Mint won't allow this to be a split on the same transaction, but even a separate cash transaction would be useful. If there's only one item in the order, the tagger could copy the description and category from the order transaction; otherwise, it could just set the description to the order number and the category to "Shopping." If the entire payment was on a gift card, the process would be exactly the same, but using a $0 cash transaction.

Alternatively, gift cards could be added as two splits within the same transaction, one going to either of the above categories and the second negating the first split and hidden from budgets and trends.

What do you think?

[jprouty]

Thanks Jesse! Glad it's been a useful tool!

I know exactly what you're talking about. As you've already figured out, it's a bit nuanced to get right, and would require creating mint transactions (sometimes) to represent the transaction.

I never gave this too much attention, since for me the majority of purchases are non-gift card. However, I understand different users may have a large influx of gift cards (think wedding/baby shower) OR use gift cards anyway as their primary means (remember 5 years ago when you could get cashback on your CC by buying amazon gift cards at the grocery store...).

I'll take a closer look at the existing logic and see if there's anything that might be amiss. It used to work for me with gift cards a while back (basically similar logic to how promotions work), but something could have changed.

Thanks for flagging this!

[felciano]

I'm running into this fairly frequently as well @jprouty. One possible near-term workaround--or at least way to alleviate the pain--would be to allow export of the unmatched transactions to a CSV. That would allow us to go in and manually categorize/split the Mint transactions by hand, but e.g. use the same naming conventions and extracted metadata as you do for the automatically processed ones. What do you think?

[duncanka]

I would second the request above! Although the unmatched orders/refunds pane is pretty useful and allows you to link straight to the order, so maybe not totally necessary. But that popup is ephemeral.

[griddle-corn]

Just flagging that this would still be a useful feature. The predicament for me is that last year I returned a couple of large items (fairly common I would think) and so they put the balance on my AMZ account. Then I purchased a lot of smaller items using the gift card balance. So a significant portion of my transactions are not caught by the tagger. Thanks.

[griddle-corn]

And huge thanks for sharing the project! I just found it and it is a huge help.

[jprouty]

Thanks for flagging. To distill a bit, there are two cases relating to gift cards: 1) Order is completely paid for via gift card(s). No mint transactions exist, and therefore there is no "matching" to be done. Instead, a Mint "cash transaction" could be created (and itemized/split if necessary). 2) Order is partially covered via gift card(s). There exists a mint transaction, however, given the incomplete information in the order reports, it's impossibly to match without additional information.

Question to the group: which case is more relevant?

I believe it will be difficult/unable to detect between cases (1) and (2) without an additional data join (ie: scraping individual order invoice pages for unmatched orders).

[griddle-corn]

Hmm, interesting question. I would have to say, unfortunately, that I have a number of both types. If I had to prioritize one over the other, I'd say type 1 (fully paid by gift card) is the priority and more common.

I also recognize that using actual amz gift cards is very rare for us. But using return/refund balance is very common. So when we return things going forward, we will be asking Amazon to return the balance "to the original payment method" rather than "to an amazon credit" (which we previously were doing), as that would also help to avoid this problem.

[jprouty]

Thanks for your input; that's a good work around @griddle-corn. I personally always refund to the original payment instrument and recharge, which can sometimes optimize the cashback (I use the amazon visa, which gets 5% back on certain amazon purchases, but not others). It also simplifies my financial life a touch by having one less balance hanging around (which can instead be in my bank earning interest/etc).

[duncanka]

For me, unfortunately, the half-paid-by-gift-card case is probably the more common one. We often end up getting some Amazon credit purely as a means of generating debit card transactions or from some sort of small reward (e.g., an experiment or a blood donation), so we end up with a small balance going toward the order total.

It does appear that gift card info doesn't show up in the downloaded reports. But couldn't you scrape https://www.amazon.com/gc/balance/?

[jprouty]

Yes, exactly. I will look into our options. Adding additional data source(s) incur additional complexity / potential for things to break due to changes in auth/page layout/data modeling/etc.

Specifically, for users with a high number of gift cards care must be taken to avoid getting rate limited when scraping the gift card history page.

The other, more generalized option would be to scrape the amazon order invoice pages for all unmatched orders (which also contains GC activity, as well as other information that isn't present in the order reports).