First, a disclaimer. Your question is partially a legal one, and I am not a lawyer. I did, however, work as a penetration tester for a registered PCI ASV for nearly 6 years, and have done quite a bit of PCI-DSS compliance validation testing. I last worked on PCI stuff when PCI 3.2 was the latest release, and it seems PCI 3.2.1 is now the latest, so there may be some changes since I last looked at it. I do not expect that changes in the new release affect the validity of my answer, though.
PCI-DSS compliance is not required by law in any jurisdiction I know of (although according to comments on the other answer by phyrfox, it is now part of state legislature in some jurisdictions in the US). It is, however, generally a requirement of your contract with your payment provider.
PCI-DSS is generally required whenever your infrastructure handles card data in any way. This can be storage or just transmission, and the card details do not even have to be textual - I have personally been involved in a situation where a company tried to argue that acting as a live video streaming service where customers showed their credit card to an agent for identity verification purposes did not fall under PCI-DSS because they "only" routed video data and never "handled" card data. Let's just say that their payment provider was less than convinced.
Before considering implementing PCI-DSS and all the headaches that come with it, you should try to avoid needing PCI-DSS compliance at all. You can do this by not having any card data hit your server. There are usually a few ways to implement this, and most payment providers use one of these models:
- When you go to check out, your web application sends the basket data (or at least a total cost) along with some information about your store (merchant ID, etc.) to the payment provider as a POST request. The user then enters their card information on their payment page, and a payment confirmation is then sent back to your web application. No card information is ever sent to your site, nor is it ever entered into one of your site's pages. This allows you to avoid the requirement of PCI-DSS compliance entirely.
- Same as the above, except the provider's payment page is embedded in an
iframe in your checkout page. This gives a more seamless experience to the user without requiring your site to directly take in card data - the
iframe is considered a separate origin, and SOP should prevent your page from gaining access to data within it. This is marginally more risky than option 1, partly because of potential browser exploits, but also because a user familiar with the site expects to see the page asking for card details, and an attacker might be able to use UI redressing attacks if they compromise the page (e.g. via XSS) in order to steal card data. This is still considered sufficient to avoid PCI-DSS compliance requirements though.
- Have card information entered into your web page, but have the form post the data to the payment provider. This means that payment card information is entered into your web page, but it never reaches your server. This is currently a bit of a grey area in terms of whether it triggers PCI-DSS compliance requirements, and whether or not this is acceptable is dependent on your provider and ASV (in the case of needing an audit). The reason that this is risky is that an XSS vulnerability in your page allows an attacker to directly read card data. I would generally avoid this option entirely.
The most common examples of the first approach are PayPal and Google Pay, where the merchant website (you in this case) hands off information to the payment provider and the rest of the process happens on their website, which is PCI-DSS compliant. This means you don't need to worry about card information at all.
These approaches are more completely detailed in the Best Practices for Securing eCommerce paper released by the PCI council. The most relevant parts of that paper here are sections 2 and 6.
Critically, PCI-DSS does not have to be mandated by law in order for you to see consequences by not being compliant. If you are contractually obliged to be compliant as part of your contract with your payment provider, and you are later found not to be compliant, they can force you to very quickly become compliant (which may be very expensive for you) or simply sue you for breach of contract. Additionally, in the event of a breach that reveals payment card information, you may find that a lack of compliance where compliance should have been required will count negatively against you in any subsequent legal or regulatory action. The Information Commissioner's Office (ICO) in the UK has previously fined companies large sums for breaching data protection laws, and the magnitude of those fines was often tied to whether or not the company was compliant with industry security standards, and whether they were knowingly negligent in their duty of protecting data.
I would strongly suggest option 1 or 2 wherever possible. Otherwise you're probably in for a difficult and expensive experience with PCI compliance.