CBK Payment Service Provider Rules Developers Should Know

This article is not legal advice. It provides general information about the regulatory environment for payment systems in Kenya to help developers understand the landscape. The Central Bank of Kenya regulations are complex, subject to change, and depend on the specific details of your product and business.

Before making decisions about licensing, compliance, or regulatory obligations:

• Consult a qualified lawyer with experience in Kenyan financial regulation.
• Review the current regulations on the Central Bank of Kenya website.
• Check with your payment gateway provider (Paystack, in this context) about what their license covers and what remains your responsibility.

The regulatory details in this article are based on publicly available information and may have changed since publication.

Most developers building payment features do not think about regulation. They integrate an API, test it, ship it, and move on. That works until it does not.

Here is why this matters:

• Your product could be shut down. If your product handles money in ways that require a license you do not have, CBK can order it shut down. This has happened to Kenyan fintech products.
• Your payment provider could cut you off. Paystack, like all licensed PSPs, has compliance obligations. If your use of their API violates regulations, they will terminate your account to protect their own license.
• You could face personal liability. Depending on your business structure, regulatory violations can create personal liability for directors and founders.
• Investor due diligence catches this. If you are building a fintech startup and seeking investment, every serious investor will ask about your regulatory compliance. Not having answers kills deals.

The good news: for most developers using Paystack to accept payments in a straightforward e-commerce or SaaS product, the regulatory burden is light. Paystack carries the heavy compliance load. But you need to know where the boundaries are.

The Central Bank of Kenya regulates payment service providers under the National Payment System Act and the National Payment System Regulations. A PSP license is required for businesses that provide payment services, which generally includes processing, transmitting, or switching payment instructions.

What requires a license:

• Operating a payment gateway that directly processes transactions between customers and banks or mobile money providers.
• Holding customer funds in any form (wallets, escrow, float).
• Operating a payment switch that routes transactions between financial institutions.
• Issuing electronic money or operating a mobile money service.

What does not require a license (in the context of using Paystack):

• Accepting payments through a licensed PSP like Paystack. You are a merchant using their service, not a payment processor yourself.
• Selling goods or services online and receiving settlement from your PSP.
• Building a website or app that has a "Pay Now" button connected to Paystack.

The distinction is straightforward: if you are building the payment rails, you need a license. If you are using someone else's licensed payment rails to accept money for your business, you do not.

The grey area: Some products blur this line. If you build a platform where money sits in your system before being disbursed to sellers (like a marketplace with a holding period), you might be holding funds. If you build a wallet feature where users deposit money that they spend later, you might be issuing electronic money. These activities may require a license or at minimum a formal arrangement with a licensed entity.

If your product does anything more than straightforward "accept payment, deliver product," get legal advice before launch.

Paystack operates in Kenya as a licensed payment aggregator. Their license covers the core payment processing activities:

• Transaction processing. When a customer pays through your Paystack integration, Paystack handles the actual movement of money. They interact with Safaricom (for M-Pesa), banks (for cards and Pesalink), and other payment providers.
• Settlement. Paystack collects money from various payment channels and settles it to your bank account or M-Pesa wallet according to their settlement schedule.
• PCI DSS compliance. For card payments, Paystack handles the card data and is PCI DSS compliant. You never see or store card numbers if you use Paystack correctly.
• Regulatory reporting. Paystack files the required reports with CBK about transaction volumes, suspicious activities, and other regulatory matters.

What Paystack's license does not cover for you:

• Your own business registration. You still need a registered business in Kenya to operate commercially.
• Your tax obligations. DST, VAT, income tax. See Kenya Digital Service Tax and Online Payment Products.
• Your data protection obligations. You are responsible for the personal data in your database (phone numbers, emails, transaction histories). Paystack handles card data, but everything else in your system is your responsibility under Kenya's Data Protection Act.
• Any money-holding or wallet features you build yourself. If your product holds user funds outside of Paystack, that is your own regulatory concern.

Kenya's Proceeds of Crime and Anti-Money Laundering Act sets obligations for businesses that handle financial transactions. While Paystack has its own AML program, you may have obligations depending on what your product does.

What Paystack handles:

• Screening transactions against sanctions lists.
• Reporting suspicious transactions to the Financial Reporting Centre (FRC).
• KYC on merchants (that is you) during onboarding.

What may be your responsibility:

• Knowing your customers. If your product involves high-value transactions, recurring large payments, or services that could be used for money laundering (remittances, high-value trading, peer-to-peer money transfers), you may need your own customer due diligence processes.
• Monitoring for unusual patterns. If a customer on your platform suddenly starts making transactions that are inconsistent with their normal behavior, you should have mechanisms to detect and investigate this.
• Record-keeping. Maintain records of transactions and customer identities for the period required by law.
• Reporting. If you suspect money laundering or terrorist financing through your platform, you have a legal obligation to report it. The fact that you use Paystack does not transfer this obligation to them.

For a standard e-commerce store or SaaS product, your AML obligations are minimal. You know who your customers are (they sign up with an email and name), and the transaction patterns are predictable (subscription payments, product purchases).

For a marketplace, a lending platform, a remittance service, or any product where money flows between users, the obligations are more significant. Get legal advice early.

Know Your Customer (KYC) in the Paystack context works at two levels.

Level 1: Paystack KYC on you (the merchant). When you sign up for a Paystack account, they verify your identity, your business registration, and your bank details. This is Paystack doing its regulatory duty. You provide documents, Paystack verifies them, and you get approved to receive payments. This is done once during onboarding.

Level 2: Your KYC on your customers. Whether you need to verify your customers' identities depends on your product. For most products, you do not need formal KYC beyond what is normal for your business (email verification, phone number confirmation). But some products require more:

• Financial services. If your product provides loans, insurance, investment, or savings services, you likely need formal KYC with government-issued ID verification.
• High-value transactions. If individual transactions on your platform exceed certain thresholds, enhanced due diligence may be required.
• Peer-to-peer transfers. If your platform enables users to send money to each other, you need to verify both parties.

For a typical Paystack integration (e-commerce, SaaS, event ticketing, service booking), you collect the customer's name, email, and phone number. Paystack handles the payment processing KYC. That is usually sufficient.

If you collect government ID numbers, copies of IDs, or other sensitive identity documents as part of your own KYC process, you have additional data protection obligations under Kenya's Data Protection Act. Store these securely, limit access, and have a retention and deletion policy.

Transaction limits in Kenya come from multiple sources, and they interact in ways that affect your application design.

M-Pesa limits (set by Safaricom):

• Per-transaction limits for payments (currently KES 150,000 for most individual accounts, but check current Safaricom documentation).
• Daily transaction limits.
• Monthly transaction limits.
• These apply to the customer, not to you. But if your product regularly handles amounts above these limits, your customers will fail to pay via M-Pesa.

Paystack limits:

• Paystack may impose its own per-transaction and daily limits on your account, especially if your account is new or unverified.
• Transfer limits (when sending money out) are separate from payment limits (receiving money).
• These limits can be increased by contacting Paystack support and providing additional documentation.

CBK regulatory limits:

• CBK sets rules on mobile money transaction limits that Safaricom and other providers must follow.
• Large-value transactions may trigger additional reporting requirements.

What this means for your code:

// Handle transaction limit errors gracefully
async function initiatePayment(amount, phone, email) {
  try {
    const response = await fetch('https://api.paystack.co/charge', {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${process.env.PAYSTACK_SECRET_KEY}`,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        email,
        amount: amount * 100,
        currency: 'KES',
        mobile_money: { phone, provider: 'mpesa' },
      }),
    });

    const data = await response.json();

    if (!data.status) {
      // Check if the error is related to limits
      const msg = data.message?.toLowerCase() || '';
      if (msg.includes('limit') || msg.includes('maximum')) {
        return {
          success: false,
          userMessage: 'This amount exceeds mobile money limits. '
            + 'Try paying with a card or Pesalink for larger amounts.',
          suggestAlternative: true,
        };
      }
      return { success: false, userMessage: 'Payment could not be initiated. Please try again.' };
    }

    return { success: true, data: data.data };
  } catch (error) {
    return { success: false, userMessage: 'Network error. Please try again.' };
  }
}

When a customer hits a limit, do not just show a generic error. Tell them what happened and suggest an alternative. "This amount exceeds M-Pesa limits. Try paying with a card or Pesalink" is far more useful than "Payment failed."

For high-value products (rent payments, school fees, vehicle purchases), design your checkout to suggest Pesalink or card payments for amounts that approach M-Pesa limits. See Pay with Pesalink on Paystack: Developer Guide for integrating Pesalink as an alternative for large transactions.

Kenyan law requires businesses handling financial transactions to maintain records for a specified period. The exact retention period depends on the regulation (tax law, AML law, and company law may each specify different periods).

For developers, this translates to practical requirements:

• Store transaction records in your own database. Do not rely solely on Paystack's dashboard. Paystack provides excellent reporting, but your records need to be under your control. If your Paystack account is ever suspended or closed, you lose access to that data.
• Record enough detail. For each transaction, store: the Paystack reference, the amount, the currency, the payment method, the customer identifier, the date and time, and the status (success, failed, reversed).
• Store webhook payloads. Save the raw JSON from every Paystack webhook you receive. These are your primary evidence of what happened in each transaction. They are invaluable for dispute resolution and audit.
• Implement data retention policies. You need to keep records for the legally required period, but you also need to comply with data protection rules that say you should not keep personal data longer than necessary. These two requirements can conflict. Get legal guidance on your specific retention schedule.
• Backup your records. Database backups are not optional for a system that handles money. If your database crashes and you lose transaction records, you have a compliance problem on top of a business problem.

// Store raw webhook payloads for audit trail
async function storeWebhookPayload(event) {
  await db.collection('webhook_audit_log').insertOne({
    eventType: event.event,
    reference: event.data?.reference,
    payload: JSON.stringify(event), // Store the full raw payload
    receivedAt: new Date(),
    processedAt: null,
    processingResult: null,
  });
}

This is a pattern you should have from day one, not something you bolt on after an audit request. It costs almost nothing in storage and saves you when you need to prove what happened six months ago.

Kenya's Data Protection Act (2019) governs how you collect, process, and store personal data. Payment-related data is personal data. Phone numbers, email addresses, names, transaction histories, and purchase records all fall under the Act.

What this means for your payment integration:

• Privacy policy. Your product needs a privacy policy that explains what data you collect, why you collect it, how you store it, and who you share it with (including Paystack as a processor).
• Consent. Collect consent for data processing. At minimum, make your privacy policy available and get the user to agree to it during signup or before their first transaction.
• Data minimization. Only collect what you need. If you do not need the customer's physical address to process a digital subscription payment, do not ask for it.
• Security. Store personal data securely. Use encrypted connections (HTTPS everywhere), hash sensitive data where possible, restrict database access, and follow standard security practices.
• Data subject rights. Customers have the right to request access to their data, correction of incorrect data, and deletion of their data (with some exceptions for legal and accounting requirements).

Paystack handles card data and is PCI DSS compliant. If you use Paystack correctly (through their API, not by collecting card numbers yourself), card data never touches your servers. But every other piece of customer data in your database is your responsibility.

Before launching a payment-enabled product in Kenya, have a conversation with a lawyer or compliance advisor about these specific questions:

1. Does our product require any license beyond what Paystack provides? Describe exactly what your product does, how money flows through it, and whether funds are ever held in your system.
2. Do we have AML obligations specific to our product type? This depends on the nature of your business, the transaction volumes, and the customer profiles.
3. What is our customer data retention period? Reconcile the retention requirements from different regulations (tax, AML, data protection).
4. Do we need to register with any regulatory body? Beyond KRA for tax, there may be sector-specific regulators depending on what your product does.
5. What disclosures do we need to make to customers? Terms of service, privacy policy, refund policy, and any other required disclosures.
6. How should we handle disputes and complaints? CBK has rules about customer complaint handling for payment services.

Do not treat this as a one-time conversation. Have it before launch, then revisit it annually or whenever you add significant new features that change how money flows through your product.

For related regulatory and compliance topics:

• Kenya Digital Service Tax and Online Payment Products covers the tax implications of building digital products.
• KRA eTIMS and Payment Receipt Integration Considerations covers electronic tax invoice requirements.
• Paystack in Kenya: M-Pesa, Pesalink, and the Daraja Question is the hub article for all Kenya-specific Paystack topics.

For building payment integrations with the technical and business skills to do it right, the McTaba 26-week Full-Stack Software and AI Engineering bootcamp covers payment systems, security, and deployment for the African market.