Skip to content

Accepting Card Payments Online in Kenya: PCI-DSS, 3D Secure and Liability

Cards reach customers M-Pesa cannot - diaspora, corporate and international buyers. But card acceptance brings PCI-DSS, 3D Secure and chargebacks. Here is what you take on and how to keep it light.

By Karani Geoffrey, Founder & CEO, Upeosoft
In short

To accept Visa and Mastercard online in Kenya you need a way to process cards - usually a gateway or acquiring bank - plus PCI-DSS compliance for handling card data, 3D Secure for authenticating the cardholder, and a process for chargebacks. Using a hosted or tokenized checkout keeps card data off your servers and reduces your PCI burden to the simplest level.

Key takeaways
  • Cards reach customers M-Pesa often cannot: diaspora, corporate cardholders and international buyers.
  • Handling card data makes you subject to PCI-DSS - but a hosted checkout shrinks that burden dramatically.
  • 3D Secure adds cardholder authentication and shifts fraud liability, so keep it on.
  • Tokenization lets you charge repeat and recurring payments without ever storing the real card number.
  • Chargebacks are a cost of cards that M-Pesa does not have - budget process and evidence for disputes.
  • The safest design keeps sensitive card data with your provider and never lets it touch your servers.

Why cards still matter in an M-Pesa country

In Kenya it is tempting to think M-Pesa is enough. For a lot of local retail, it is. But cards reach people and money that M-Pesa struggles to: the diaspora paying for family services or property, corporate customers who settle by card, international buyers, and larger-ticket purchases above comfortable mobile-money limits.

For businesses selling to any of those, not accepting cards means quietly turning away revenue. The question is not M-Pesa versus cards - it is whether your customer base includes people who will only, or prefer to, pay by card.

PCI-DSS: the rule that scares people, explained

The moment you accept cards, PCI-DSS - the card industry's security standard - is in the picture. Its reputation for being heavy is earned, but only if you handle card data yourself.

The secret most businesses miss is that you can design your way out of most of it. If card details are entered into a hosted page or a secure field controlled by your payment provider, and go straight to them without ever touching your servers, your compliance obligation drops to the lightest self-assessment category. Build your own form that captures and transmits raw card numbers, and you inherit the full, audited, expensive version. The architecture you choose decides which world you live in.

3D Secure: authentication that shifts liability

3D Secure is the step where the cardholder proves it is really them - typically an OTP from their bank or an approval in a banking app - before the payment completes. It does two things for you. It cuts fraud, because a stolen card number alone is not enough to pay. And when it is used, it shifts liability for fraudulent chargebacks from your business to the card issuer.

That liability shift is the part owners underappreciate. Without 3D Secure, a fraudulent card payment that later gets disputed is your loss. With it, that risk largely moves off your books. In Kenya it is effectively expected on online card payments, so there is no good reason to disable it.

Tokenization: charging again without holding the card

If you ever want a customer to pay a second time without re-entering their card - a repeat purchase, a saved card, a subscription - you need tokenization.

Your provider stores the real card securely and hands you a token: a stand-in you can use to charge that card again, but which is worthless to a thief and carries no PCI weight. Your system stores tokens, never card numbers. This is what makes saved cards and recurring billing possible while keeping you out of scope. It is also a simple audit test: if any part of your system stores actual card numbers, something is wrong.

Chargebacks: the cost cards carry that M-Pesa doesn't

M-Pesa payments are effectively final. Cards are not - a cardholder can dispute a charge with their bank and have the money reversed, sometimes with a fee on top. This is the chargeback, and it is a genuine cost of accepting cards.

You cannot eliminate chargebacks, but you can keep them low and win the ones you should. Use 3D Secure. Describe charges on statements so customers recognise them and do not dispute out of confusion. Keep records - what was bought, when, delivery or usage evidence. And respond to disputes quickly with that evidence. A business that ignores chargebacks bleeds money and risks penalties; one that manages them treats them as a manageable line item.

The design that keeps card acceptance light

Pulling it together, the safe pattern is consistent: let your provider handle the sensitive parts, and keep your own systems clear of card data.

Use a hosted checkout or tokenized fields so raw card numbers never reach your servers. Keep 3D Secure on. Store tokens, not cards, for anything recurring. Reconcile card settlements - which arrive net of fees and on a delay - against your orders, and have a defined chargeback process. Done this way, cards become a manageable channel rather than a compliance and fraud liability. Done the naive way - your own form, raw card storage, no 3D Secure - they become the biggest risk on your platform.

How Upeosoft builds card acceptance

We implement card payments the light way: hosted or tokenized checkout so card data never touches your servers, 3D Secure enabled, tokenization for saved and recurring charges, and settlement reconciliation that accounts for fees and timing. We keep you in the simplest PCI category by design and set up a clear process for handling chargebacks.

Whether you are adding cards alongside M-Pesa or building a checkout from scratch, talk to Upeosoft and we will make card acceptance secure, compliant and low-maintenance.

Frequently asked questions

Do I have to be PCI-DSS compliant to accept cards?

If your business touches card data in any way, yes - PCI-DSS applies. But the level of effort depends entirely on how you handle the data. If you use a hosted payment page or a tokenized field where the card details go straight to your provider and never hit your servers, you fall into the simplest compliance category. If you build your own form that captures raw card numbers, you take on the full, heavy compliance burden. Almost every business should choose the former.

What is 3D Secure and do I need it?

3D Secure (the 'Verified by Visa' / Mastercard authentication step) asks the cardholder to confirm the payment with their bank, often via an OTP or app approval. It reduces fraud and, importantly, shifts liability for fraudulent transactions from you to the card issuer when it is used. In Kenya it is effectively standard for online card payments. You should keep it on - it protects you from a whole category of chargebacks.

What is tokenization and why does it matter?

Tokenization replaces the real card number with a meaningless token your provider gives you. You store the token, not the card, so you can charge the customer again - for a repeat purchase or a subscription - without ever holding sensitive data. It is how you enable saved cards and recurring billing while staying out of PCI scope. If a system stores actual card numbers itself, that is a red flag.

What are chargebacks and how do they affect me?

A chargeback is when a cardholder disputes a payment with their bank and the money is pulled back from you, often with a fee. Reasons range from genuine fraud to 'I don't recognise this charge.' Cards carry this risk; M-Pesa largely does not. You manage chargebacks by using 3D Secure, keeping clear records and delivery evidence, describing charges recognisably on statements, and responding to disputes promptly with proof.

Should I add cards if I already accept M-Pesa?

It depends on your customers. If you serve diaspora buyers, corporates paying by card, international customers, or higher-value purchases, cards open revenue M-Pesa cannot reach. If you are purely local retail with small tickets, M-Pesa may cover almost everyone and cards add cost and complexity for little gain. Add cards when there is real demand you are currently turning away, not by default.

Karani Geoffrey
Karani Geoffrey
Founder & CEO, Upeosoft

Karani Geoffrey is the Founder & CEO of Upeosoft, a software and automation company rooted in Kenya. He builds custom software, AI systems, and production-grade ERPNext for businesses across East Africa, and writes about the Kenyan realities - eTIMS, M-Pesa, SHIF, unreliable internet and power - that make or break real systems.

Next step

Want this working in your business?

Upeosoft builds and hardens the systems behind this article - for real Kenyan operations, with eTIMS, M-Pesa and offline realities handled.

Keep reading

Kenyan Compliance and Integrations

Payment Gateway or Direct Integration? When Each One Makes Sense

A gateway lets you accept M-Pesa, cards and banks through one integration - for a cut of every transaction. Going direct costs less per shilling but more to build. Here is how to choose.

6 min readRead article →
Kenyan Compliance and Integrations

Securing Your Payment Integration: Webhooks, Secrets and Fraud

A payment integration is a door to your money. Attackers forge callbacks, replay requests and hunt for leaked keys. Here are the controls that keep the door shut.

7 min readRead article →
Kenyan Compliance and Integrations

Recurring Payments and Subscriptions in Kenya: Billing That Actually Works

Subscriptions are easy on cards and hard on M-Pesa, because M-Pesa needs the customer's PIN every time. Here is how recurring billing really works in Kenya - and how to make it collect.

6 min readRead article →