"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.
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.
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.)