PCI DSS when you take card payments online
Whether a South African business taking card payments on its website must meet PCI DSS, what hosted payment pages change, and the checks that still matter.
By Achekam · · 5 min read · For Running a business businesses in South Africa
A small South African business adds a "Pay now" button to its website and its invoices, and customers start paying by card. It feels like a technical change, made in an afternoon with the payment provider's plugin. It is also the moment the business takes on obligations around cardholder data that many owners have never heard of.
Those obligations are set by PCI DSS, the card industry's security standard. This article explains what it is and why it reaches South African businesses, what using a hosted payment page does and does not change, the checks on payment notifications that protect you from fake payments, and how Achekam fits into the picture.
PCI DSS and PASA
PCI DSS is the Payment Card Industry Data Security Standard: the security standard for businesses that store, process or transmit cardholder data. Its official home is the PCI Security Standards Council's PCI DSS page, which publishes the current version of the standard and its supporting documents.
In South Africa the standard has local force. Payfast's developer documentation says PCI DSS is a PASA regulation in South Africa, so any company accepting credit card payments on its website must comply in some way. PASA is the Payments Association of South Africa. The same documentation describes Payfast itself as PCI DSS level 1 compliant.
"In some way" is the important phrase. What PCI DSS asks of a particular business depends on how it takes card payments: whether card details ever pass through its own systems, how its website is built, and what its acquiring bank requires. The provider's certification covers the provider; it does not answer the question for the merchant. Ask your payment provider and your bank what applies to your set-up, and keep their answer on file.
Hosted payment pages instead of collecting card details yourself
Payment providers offer ways for a business to take card payments without building its own card form. Peach Payments, for example, says its Payment Links product lets merchants send customers links to a secure hosted payment page by e-mail, SMS or WhatsApp, instead of sending bank details and a PDF invoice.
A hosted page is run by the provider: the customer follows a link or is redirected to the provider's page to pay. For many small businesses that is a sensible design, because it keeps the payment form in the hands of a business whose job is payments. It does not, however, end the merchant's interest in PCI DSS. The website that sends customers to the hosted page, the people with access to the payment provider's dashboard, and the way refunds and notifications are handled are all still the business's responsibility. Confirm with your provider and bank what your obligations are when you use their hosted page.
Signatures and notification checks
The other half of online card security is making sure the payments you record are real. When a customer pays, the provider sends the business a notification. A notification that has not been checked is just a message, and messages can be forged.
Payfast's documentation is explicit about this. It says payment requests carry an MD5 signature built from the payment fields and an optional passphrase. It also says a merchant must run four security checks on each payment notification (Payfast calls it an ITN), including that the notification came from a valid Payfast domain, and must not continue if any check fails. And it says integrations should be tested against Payfast's sandbox before going live.
Whatever provider you use, apply the same principles:
- Verify the sender. Confirm each notification really came from the provider.
- Verify the content. Check the signature and that the amount matches what was asked for.
- Stop on failure. If any check fails, do not mark anything paid or release any goods.
- Test first. Use the provider's test environment before taking real payments.
- Guard the keys. Limit who can see the integration keys and passphrase, and change them if someone with access leaves.
Achekam does not save cards or charge them again
In Achekam, a business can e-mail an invoice with a pay link through which its customer pays by a gateway the business has configured with its own keys, such as PayFast, Ozow, Peach Payments, Stripe, Paystack, Flutterwave, M-Pesa or Pesapal, or by EFT. The gateways are set up under SETTINGS, in Integrations & Webhooks, under Payment Gateways & Checkout. Without a gateway there is no pay link.
Payment is recorded only from the gateway's verified notification, a status query, or a person's capture. For PayFast specifically, a South African business can take payments in rand, with each notification checked by signature, source address, amount and PayFast's own validation. A payment recorded this way lands in the same books as the invoice it settles, so sales, receipts and what customers still owe stay in one ledger.
Two limits are worth stating plainly. First, Achekam does not save cards or charge them again. The settings text mentions that Peach offers card tokenisation for retainers, but that is not something Achekam uses: no card is stored for a later charge, so each card payment is one the customer makes. Second, Achekam is not the merchant of record. The merchant relationship, and the PCI DSS questions that come with it, sit between your business, your payment provider and your bank. How pay links work on invoices from start to finish is covered in online payments on your invoices, and connecting a provider is explained in setting up your payment gateway.
Achekam is not the merchant of record
That second limit deserves its own emphasis, because it decides who you talk to. If a customer disputes a card payment, if your bank asks about PCI DSS, or if you need to change how cards are accepted, the conversation is with your payment provider and bank. Achekam's part is to show the customer a pay link, record the payment once it has been verified, and keep it in your books.
Three questions for your provider
Before you switch card payments on, ask your provider: what does PCI DSS require of us with the set-up we are using, what must we check on each notification, and how do we test before going live? Write the answers down, check them against the PCI Security Standards Council's material, and revisit them whenever you change how you take payments.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
