PCI DSS Compliance
2 comments
The "other API" likely provides a better unique identifier for users or charges. Name + last 4 is mostly unique, but what are you going to do if a user changes credit card number because it was stolen so the old one doesn't work? Can't renew or refund them.
Various POS API. ex: Square, Toast, and Clover. They briefly mention tokenizing CC numbers but nothing publicly available afaik.
I'd hate to have to support all three of that at launch so I'll just like to Clover's. Clover's tokenization docs are https://docs.clover.com/dev/docs/create-a-card-token but you don't want to touch the cc number/PAN so as to avoid PCI, so the flow I imagine is you charge the customers card on the POS device, then use their API to retrieve the charge https://docs.clover.com/dev/reference/getorders which includes the charge and customer id, and store that.
As of my knowledge: no.
If I'm just storing name + last 4 cc digits, do I have to comply by PCI DSS?
This thread sounds promising: https://stackoverflow.com/questions/44630367/is-last-4-digits-of-credit-card-and-expiry-date-storage-allowed-in-pci-dss but not sure how accurate or dated the info is.