The big overarching limitation for this effort will be that we need to store all of this information locally (not just locally, but local to the current install of the app), i.e. with no syncing of this information to the backend, and no additional infrastructure planned.
This has the following implications (not limited to):

• The app cannot know whether the user has made donations in the past, or what amounts they were.
• If the user signs up for a recurring donation through the app, and then later cancels it (which is done outside of the app), the app won't be able to know about it.
• If the user uninstalls and reinstalls the app, or clears the app's data, their local contribution history will be lost.
• If the user logs in on another device, their contribution history will be empty.

With these limitations out of the way, here are the types of data we could make use of for the Contributions dashboard:

• Native payments (Google Pay)
  • Since this payment workflow is native inside the app, we have visibility into the entire workflow, and can persist most of the relevant details that come from it (short of the actual payment method information, which we wouldn't want to persist anyway).
• Web payments
  • If a user completes a donation in their web browser, the browser will direct them to a "thank you" page hosted on thankyou.wikipedia.org. This will actually get intercepted by the app (assuming the user has the app installed and hasn't disallowed the app from opening Wikipedia links).
  • This way, the app can know that a donation was just made. It can also examine the URL for any additional parameters, which do in fact include the amount and currency code.
  • The app should also make sure to examine the REFERRER of the intercepted URL, as well as the other expected URL parameters, to make sure it's a genuine request from the donation workflow, and not a random navigation to the thankyou domain.

I've updated our deck with this info thanks Dmitry