Username and password doesn’t inherently have an HMAC+timestamp, so it has to be kept alongside payments. A certificate could be a one-time transaction, so the

Username and password doesn’t inherently have an HMAC+timestamp, so it has to be kept alongside payments. A certificate could be a one-time transaction, so the payment could be logged while the certificate is issued, the only worry after is if timestamps are present in the transaction method and timestamps are present (obviously) in the certificate, then correlation is still possible. Perhaps a workaround would be to take orders at any time but process orders in batches, where payment for all customers and certificate issuance for all customers happen at the same time/date. Or decouple certificate issuance from payment such that payment can occur any time and what is provided is a certificate that was previously generated/allocated at the start of the month or year. The downside to the preallocation is that the certificate private key would also have to be known in advance, it weakens security, but is perhaps an acceptable trade off for privacy. If transaction proof is possible, perhaps again with an hmac secret, you could provide proof of transaction at the start of the next month to keep the certificate issuance secure by presenting and issuing key material at a later date from when the transaction occurred. Actually, an hmac probably isn’t tamper-resistant enough given its value, unless you include a timestamp and correlate to transaction dates, or use a really long secret, or both and rotate the secret, perhaps. So you’d exchange payment for tokens, and tokens for certificates, decoupling the two. If your tokens are trusted, you could sell multi-year certificates or multiple tokens at the same time at the cost of reduced privacy if different features or timestamps are present in the tokens or transaction cost.