A new PCI Compliance Standard—PCI DSS 4—has come into effect over the previous year. If your website has e-commerce you should be aware of the changes that are coming.

PCI DSS stands for "Payment Card Industry Data Security Standard". The e-commerce world has been operating under version 3 of that standard since 2014. Version 4 is the latest version of the standard. It came into effect on March 2024, but its more serious requirements take effect in March 2025. E-commerce websites should have a plan to ensure they remain compliant after that date. Websites that are non-compliant may fail security scans or self-assessment questionnaires, and be subject to fines or suspension of their e-commerce capabilities.

What is the purpose of PCI DSS?

Credit card fraud is a huge problem, especially in e-commerce where card-not-present transactions are the norm. PCI DSS is a set of best practices for ensuring that credit card data is handled safely, and website security breaches do not cause a cascade of additional problems as stolen cardholder data becomes exploitable by cyber criminals.

The single most important issue in PCI compliance is whether you handle sensitive cardholder data (credit card numbers, cardholder names, expiry dates, or CVV numbers). If you do handle such data, you have a large set of obligations in securing your IT environment to ensure that the cardholder data is processed and stored safely.

These obligations can result in a time-consuming and expensive burden for you. Fortunately there are ways to mitigate these requirements, so that you never need to handle cardholder data directly. If you want to reduce your costs and risks, your e-commerce processes can be designed to off-load card handling from your website entirely.

What is new in PCI DSS Version 4?

There are many new changes in version 4. The parts that are mostly likely to affect small- to medium-sized website owners relate to the checkout and payment screens of your e-commerce flow.

Payment providers have been offering newer, slicker methods for integrating their payment methods into websites. To reduce the need to handle cardholder data directly, many now offer tokenized card handling. This lets you store a credit card without actually holding any of the cardholder data. Instead you keep a token, which represents the card, but cannot be used on any other website. This makes it easy to accept payments on previously-used cards, without requiring the buyer to type in their card information each time, and without requiring the merchant to store any of the card details.

Payment providers have also been developing slicker ways to integrate payment forms into websites, so that buyers never leave your web pages in order to pay. The credit card forms are embedded using technologies like Javascript and iframes. They appear to reside on your web pages, but they only talk to the payment provider, so the credit card information never actually passes through your webserver.

Unfortunately, that is no longer considered to be a safe practice, as of DSS 4. The essential problem is that if the payment form appears to be part of your web page, then a hacker could simply replace the form with a different form that looks the same, and the customer would not be able to tell that something was amiss.

PCI DSS 4 now treats anything that could potentially alter the payment page as if it were handling sensitive cardholder data, even if is isn't. As long as there is a risk that a hacker could imperceptibly alter your payment forms, the form is considered insecure. Since your CMS has the power to alter your pages, that means your CMS will henceforth be treated as if it were handling sensitive credit card data, even if it does not.

Is my website affected?

When you reach the credit card payment form of your checkout process, whose domain name is in the browser address bar? If it is your payment provider (for example moneris.com, stripe.com, or authorize.net) then the customer has completely left your website to complete the payment, and you are in the clear.

If you see your own domain name in the browser address bar, then you have an integrated payment form, and your website now falls under the PCI DSS 4 requirements. You should expect to be subjected to much stricter security and IT policies going forward.

If you don't want the added hassle and expense of PCI DSS 4 compliance, then the simplest option is to de-integrate your payment form. Switching to a hosted payment form under your payment provider's URL will move the PCI DSS 4 compliance problem to them instead of you. And since credit card payments are their specialty, you should be able to trust them to live up to their obligations if they are one of the larger, reputable vendors.

The tokenization of credit cards is still considered a safe practice. Many payment providers allow you to continue to utilize tokenization even if you choose to stop using integrated payment forms. Some, however, do not. Since everyone will be reviewing and updating their services in the wake of PCI DSS 4, we can expect payment providers to update their APIs in the coming months. Stay tuned!

• do you use cookies to track the movements of your visitors and collect that data for later analysis? (If you use Google Analytics, Google Adwords, or other online advertising services, then the answer is yes.)
• do you do business in the E.U., Quebec, or any other jurisdiction that requires consent to track peoples' online movements or otherwise collect personal information about how they use your online services?

Anyone sending bulk email can be flagged as a spammer. Bulk email is sending an email to a group of recipients. The more emails you send and the larger your recipient lists, the greater the risk of being flagged, but there is no such thing as a safe limit that you can stay under. Any bulk emails you send could potentially land you in trouble.

Everyone is coming down hard on email spam, from governments with anti-spam legislation like CASL, to Internet Service Providers (ISPs), who are doing more and more to detect and block bulk email.

ISPs, as well as companies that provide spam-filtering services, process a lot of email. This gives them the ability to collect large amounts of aggregate data with which to identify spam, and potentially blacklist the sender. Once you are blacklisted, it takes time and money to fix.

Services such as MailChimp, Constant Contact, and Campaign Monitor protect you from getting blacklisted. However, even when using these services, you must follow good email practices, because the industry looks at your "email reputation".

What is Email Reputation?

Your email reputation is how ISPs and anti-spam systems track and score the desirability of the bulk email your organization sends. If you have a good reputation, then there's a good chance your emails will end up in recipient inboxes. But if your reputation is low, then your emails are more likely to end up in spam folders or be blocked entirely.

Many factors can go into determining your email reputation, and every ISP does it differently. Common things they look at include:

• how many different people you send to.
• the total volume of email you send.
• whether you send to "spam trap" addresses - these are made-up addresses to which no emails should ever go.
• what percentage of emails you send, end up bouncing.
• how much user engagement your emails generate. If people delete your emails unopened, that's bad.
• how many recipients mark your emails as spam.
• how many recipients click "unsubscribe".

How can I protect my Email Reputation?

1. You want to keep your email lists clean. This means removing bounce back addresses from your email lists, and correcting typos. Repeatedly sending emails to addresses that bounce can really hurt your email reputation, as it's the mark of an indiscriminate spammer.
2. Follow CASL rules.
3. Be mindful of what you send and how often, people don't want to be bombarded. Even if they consent to email, they may still indicate to their ISP that your emails are "spam".

If you have a bad email reputation, third party email services may drop you as well.

How does the Exware AMS help?

• The Exware AMS has built-in CASL rules.
• The Exware AMS filters out repeated bounce backs until fixed by admin
• The Exware AMS integrates with third party email services so your domain/IP doesn't get blacklisted

In summary, organizations used to get away with anything when sending out email blasts. However, the industry and government legislation has changed that, and it's probably only going to get tougher.

I read a great article on web content writing tips

The key tip was write for "scanners". The article points out that only 16% of people read web pages word-for-word. Most people just scan.

When people scan a page, the four things they notice most are:

• Headings / headlines
• Sub-headings
• Image captions
• Lists of bullet points

These are things you should pay special attention to. In particular:

• Headings and sub-headings should focus on your key points.
• Captions on images should connect back to your main talking points.
• Bullet points are a good replacement for lengthy sentences and paragraphs. They should be short and concise.

These methods can help get your ideas across quickly, and perhaps entice people to read a little more.

A writer's most important tool is the delete key, so shorten your text and make your copy easy to read:

• Use short sentences and paragraphs
• Skip unnecessary words
• Avoid repetition
• Avoid jargon
• Avoid the passive tense
• Address your readers directly, using the word you

In a nutshell, write in plain English and keep it simple – visitors don't want to have to work to understand what you're trying to say.

Many organizations want to track detailed statistics about how their users consume their content, such as:

• who read the bulk email or newsletter we just sent out?
• did webinar attendees actually watch the full webinar video?
• how many people have read a PDF document?
• how much time do visitors spend on our website?

Many web service organizations will provide engagement stats that attempt to satisfy this desire to look over users' shoulders and keep track of what they are doing. But you should treat these numbers with a bit of skepticism.

Generally speaking, you cannot look over your users' s shoulders to determine exactly what they are doing. If your users have decided that they don't want to be spied on, then it would be a privacy violation for you to do so, assuming you even had that capability. (And, realistically, you don't have that capability.)

Most engagement stats use simple tricks to guess what the user is doing. They are not actually monitoring the user. Instead they are looking at your web server's traffic stats to see what content is delivered to the user's computer. To track individual users, the URLs that are used to request that content might be tagged with personalized tracking codes.

So you can look at your web stats to see that a video was accessed, and if you are using tracking codes, you can even infer who it was accessed by (assuming that user did not share the link with someone else). Your web stats can report exactly how much data was sent back, and from that you can infer whether that adds up to the complete video or not. But none of that means the user actually watched the video. Video players will preload (buffer) their content, so the fact that your web server (or video service) delivered the full video doesn't mean the video was actually played, or that it wasn't paused or closed before it got to the end. Because things like pausing happen on the user's personal computer, and not on your web server, they are much harder to track, require more invasive spyware tricks to monitor on the user, and are unreliable even with all that extra effort. (There are many popular browser plugins that block tracking software.)

Monitoring who reads your emails is similarly problematic. As with videos, there is no way to tell that an email was actually read. Because email is not on your website, you cannot even say if it was delivered. But there is a trick you can do to determine if an email was opened. This is done by embedding an image with a tracking code into the email. When that image is downloaded from your web server, you can detect that tracking code, and guess that the email was displayed somewhere. But even in that ideal case, that doesn't tell you if the user actually looked at the email, or were just whipping through their inbox, deleting unwanted messages. Most email programs also provide easy ways to disable automatic image loading, since it can also result in slow performance and unwanted data charges on mobile devices. Without image loading, your tracker simply won't work, and your open stats are not going to be reliable. Either way, many emails that show as opened were not read, and many that show as unopened were read.

Analytics packages like Google Analytics are pretty good for tracking your website usage. It won't track anyone who has disabled Javascript for your website, but that is normally a very small number of visitors, so the stats are still fairly reliable. Once you want to start tracking views of things like PDF documents, however, they don't work. This is simply because Google Analytics can only track web page usage, and PDF documents are not web pages. To get a measure of how popular your PDF is, you have to consult your web server stats again. This will tell you how many hits the PDF got, and how much data was downloaded in total, and even how many unique visitors viewed it. But treat these numbers with caution. Many of those visitors will be bots who are snooping through your website. If you have multiple visitors from a single company accessing the PDF, they may all look like a single visitor to your web logs. And some users may hit the PDF once and save it to their computer for further consultation, while others may leave the PDF on your website and hit it over and over again as they consult it repeatedly. Ultimately, your web stats cannot tell you how people are using the document.

Many web analytics packages like to report how much time visitors spent at your website. Again, these are just wild guesses, based on tracking codes, cookies, or click patterns. Even if the user doesn't block cookies, it is very difficult to say how long someone is at your site. How long should an analytics package report that someone is on your site, if your site is left open in a background tab all day long? Who is more engaged with your website, someone who visits the same page three times in one hour, or someone who opens the same page in a tab once but leaves it there all week? There is no clear answer, and analytics tools can only make guesses based on their own assumptions.

Once you start trying to gather detailed engagement stats to see what individual users are doing, there are additional privacy concerns that come into play. Gathering data about specific users may impact your privacy policy, as well fall under privacy regulations like PIPA, PIPEDA, and the GDPR. Given the legal burden of this data gathering, and the questionable accuracy of these statistics, you should consider how important they are to your operations before investing much effort in collecting and analyzing them.