News for hackers. Stuff that matters.
Re:Black Hat: GDPR privacy law exploited to reveal personal ... by pbhjpbhj on Friday August 09, 2019 @02:18PM (#20656974)
>you don't need any details about the transcaction beyond the amount and ID. //

That's a lot of trust in the merchant services. "What transaction?", then if all you had was a transaction ID what do you do?

Also, to process refunds you need to have payment details.

In your second case only store the details if people explicitly want you to. You can do repeat customer discounts by sending vouchers for a later order with the present order confirmation. (You can't restrict discounts to those who give up their PII if I'm reading things right.)

Re:Black Hat: GDPR privacy law exploited to reveal personal ... by PeterisP on Friday August 09, 2019 @03:02PM (#20657357)
What do you mean by ""What transaction?", then if all you had was a transaction ID what do you do?" - that's a common process in online stores, you make a contract with an acquiring bank with the default scenario that you won't be processing transactions yourself (as most smallish customers can't or don't want to handle full PCI DSS compliance), then you (or the bank) contracts with one of the merchant gateway providers, and whenever you forward them a customer order session and get back a confirmation token, then you verify it afterwards (usually next morning after closing of business day) with your bank that you've got each transaction. Or something similar, details may vary - but it's an established process that works for thousands and thousands of companies without any significant trust issues. Yes, the gateway has to be trustworthy - in part that's the service they provide, to handle card data in a trustworthy manner because you don't want to be required to be trustworthy because doing things in a trustworthy manner is complicated and expensive - secure facilities, regular audits, four-eyes principle, separation of duties that's infeasible for smallish companies, etc, etc. You also have to trust your acquiring bank, and Visa/Mastercard network, that's also part of the deal.

"Also, to process refunds you need to have payment details." this is false, merchant gateways (in general, not all of them) can also execute refunds (or recurring payments) without you having any sensitive details but just that same transaction confirmation token they give you when the initial transaction was made, I've written code relating to these processes.

Re:Black Hat: GDPR privacy law exploited to reveal personal ... by pbhjpbhj on Saturday August 10, 2019 @11:10AM (#20662469)
Well, in our shop [no longer open, was a micro-business] someone comes in for a refund, but doesn't have the receipt, there's no way to process a refund except to open the safe and get the receipt because you need to refund the same card and you don't know the card without keeping some record of it.

We've had transactions that failed to upload but were processed normally on the [mobile] card terminal, and we had to give the merchant services details to complete the processing of the transaction. Sometimes a transaction would fail during processing [cardholder not present (CNP), via phone] but we wouldn't realise until the phone was down, so in some cases we contacted the customer (our business required contact details, it couldn't run without them; this was pre-GDPR anyway). Other times the bank network would be out, so we'd be unable to process transactions without keeping customer data (temporarily).

>as most smallish customers can't or don't want to handle full PCI DSS compliance //

The banks were real bastards for this. Despite providing us mobile card terminals that don't connect to local network they required us to pay for PCI compliance audits of local equipment or pay a penalty amount [you could audit it yourself, took me about 8 hours of reading documentation to establish the protocol as they apparently didn't want us to do it but wanted us to pay instead]. The PCI stuff was basically a hidden-cost scam AFAICT.