Not quite; it’s only an issue if it’s personal information that you store.
Not quite; it's personally identifiable information that you request from the user, and they provide to you in response. It doesn't include unsolicited data such as if someone emails you their personal details without you asking for that information. I've read the +30k word document on the UK Governments guidance on GDPR. It's not a small task, but we're getting off topic, I suppose.
App receipts do not include personally-identifying information.
True, however, if you've ever read the tech news in the last decade you'll know that companies that used to publish anonymised data for research purposes have stopped doing it, because it was quite quickly discovered that even anonymised data can be cross-referenced with other data (anonymised, or otherwise) to eventually render that data no longer anonymous. Suggesting getting lawyer involved is missing the context of my original post.
But still, you need to be extremely careful with how you handle other people's financial data. I've worked as a backend engineer for over a decade in commercial banking, investment banking, publishing, startups etc. I'm well aware of the team of people required to engineer and maintain a backend solution. If you think it's a one-person job, you are already way out of your depth.
The whole point of my post is to get feedback from Apple regarding a simpler mechanism of receipt validation for those who can't afford to setup and maintain a backend receipt validation service, in the hopes of reducing app piracy and given indy developers more of chance of financial success. Bug accusations aside, I'd be happy to hear your thoughts and criticisms on this mechanism, and why, perhaps it hasn't been implemented up until now.
Also, I couldn't get AutoPairs to work on Sonoma. No matter how many times I granted it permission in Accessibility Settings, the user interface never reflected that permission, even after restarting the app. And it never did auto-complete my text.