# How do you minimize access to customer data inherited from a third-party Merchant of Record? **URL:** https://discuss.privacyguides.net/t/how-do-you-minimize-access-to-customer-data-inherited-from-a-third-party-merchant-of-record/39732 **Category:** Questions **Created:** 2026-08-08T20:33:18Z **Posts:** 9 ## Post 1 by @khaga — 2026-08-08T20:33:18Z My website (a privacy-focused, web-based app suite) is built so the service itself never knows who’s using it — no accounts, no email, access runs on credit codes that can’t be traced back to a person. Payment still goes through a third-party Merchant of Record, which necessarily holds real customer data to process the transaction — email, billing info. Technically this is a subprocessor relationship: GDPR’s data minimization principle (Article 5(1)(c)) is satisfied on my own system, but the same can’t be said with the same rigor at the subprocessor’s level — and as admin, I still have access to a dashboard containing other people’s personal data. Is there an established, documented practice for minimizing or governing this kind of access inherited from a subprocessor — logging every admin login, least-privilege roles, periodic access review? Or is there a more obvious, accepted approach I’m missing? --- ## Post 2 by @Expert4870 — 2026-08-08T20:48:47Z Did you use AI to write your post? If so that’s against the rules. --- ## Post 3 by @khaga — 2026-08-08T20:57:48Z No, but I’m very curious what made you ask? --- ## Post 4 by @Labfox — 2026-08-09T10:30:04Z em dashes, If I had to guess --- ## Post 5 by @khaga — 2026-08-09T10:59:57Z Dear Labfox, Thank you for your comment and for making an effort to ensure that the site’s rules are followed. This is in everyone’s interest. In my post, I raised an issue that is real and specific in my case, and one that perhaps other visitors to the site may have encountered as well. I would be grateful for any suggestions or ideas regarding the problem described in the post. If there are none, that is of course not a problem. We will try to resolve the issue based on our previous ideas. --- ## Post 6 by @pershopai — 2026-08-09T16:23:57Z In an ideal commercial system, business transactions operate on **a strict “need-to-know” basis** across _decoupled channels_: - **The Commercial Relation:** The buyer and seller exchange only the information strictly required to execute the underlying agreement. - **The Payment Channel:** The payment processor acts as a secure, blind ledger. It verifies that Person A owes Person B a specific value and executes the transfer without knowing what product or service was exchanged, where it is being shipped, or why the debt exists. - **The Fulfillment Channel:** The carrier handles physical delivery using only the necessary destination address. It operates with zero visibility into the payment amount, payment method, or underlying commercial terms. Unfortunately, today’s world is far from ideal. When a stolen credit card is used for a transaction and the rightful owner files a fraud report, the credit card company issues a chargeback, clawing the funds back directly from the merchant. The financial loss is shifted to the seller, the burden of proof falls entirely on the merchant to investigate the fraudulent activity and supply law enforcement with detailed identifying information about the perpetrator. Consequently, merchants are forced to collect personal data across every channel simply to protect themselves against system fraud – in your case, the third-party merchant is trying to help you by providing as much information as they can. To resolve this dilemma, we need a practical, secure protocol that maintains strict privacy boundaries without leaving merchants vulnerable to risk—and I am eager to hear some ideas to achieve this balance. Last but not least, cryptocurrency, to some extent, is addressing the payment channel privacy concerns. --- ## Post 7 by @pershopai — 2026-08-09T16:28:28Z maybe AI auto-generated question ? --- ## Post 8 by @khaga — 2026-08-09T17:34:18Z Thank you pershopai for your answer, and let me confirm once again that the question was not posted by an AI. I sincerely hope that I will not have to respond to this point again. …Getting back to the essential elements. If I want to simplify the question as much as possible, I would put it something like this: imagine a website with a number of applications. Some of them are paid, while the majority are free. There is no registration and no account that users need to create in order to access the applications. Keeping the need-to-know principle you mentioned in mind, the website was specifically designed to minimize the amount of information we have about the user. This is pretty much straightforward in the case of the free applications. Access to the paid applications is provided through credit pack codes that can be purchased. This is where the questions arise. The website itself is anonymous: it does not store or retain any user data, and the goal is to ensure that we have no information about the user at all. This is indeed how our own website operates. However, when someone purchases a credit pack code, data is obviously stored by the reseller. Our goal, as the operators of the website, is to establish a protocol that ensures that we do not „look around” among customers’ data on the reseller’s platform. Let me give you a seemingly simple example — this is essentially where we have arrived so far. When we log into our reseller account, we log those logins. Every time we access the account (which contains customer data), we document why we needed to log in, what we accessed, and why. At the moment, this seems to be the most viable approach. The ultimate goal is to minimize access to personal data, and in principle, we should be able to demonstrate this based on the records and access logs I mentioned. My question at this point is whether there is another solution to the above. If you are interrested in architectural info, I would be happy to provide any details you may need. I believe that we have addressed the privacy issues on our own website quite comprehensively so far, but at this point I am primarily trying to find a way to formalize access to the data stored by the reseller. --- ## Post 9 by @pershopai — 2026-08-09T21:50:31Z Thanks for explaining, Krisztian. Though I’m still not sure about the mechanism and merit of accepting _credit pack codes_ as online payments. Because these transactions are irreversible and heavily targeted by fraud, third-party processors don’t offer real protection. The processor (such as Green Dot) does not share customer information with merchants, but if anything goes bad, 100% of any financial loss stays with the merchant who accepts the code.