Payments

Card & Alternative Payments Integration

Guide to card and alternative payment integration in Kenya, including Visa, Mastercard, Airtel Money, T-Kash, PesaLink, webhooks, and reconciliation.

Card payments (Visa, Mastercard, American Express, and UnionPay) sit alongside local options such as Airtel Money, T-Kash, Equity Bank Transfer, and PesaLink. Each provider has its own onboarding, callback, settlement, and security requirements, so the integration should start with the payment methods the business actually needs.

A payment service provider or aggregator can handle much of the payment-facing infrastructure. Statum helps connect that provider to the checkout, order, and reconciliation flows in your application.

Supported Payment Gateways in Kenya

The table is a starting point for comparing providers and channels. Confirm current availability, commercial terms, and regional support with each provider before selecting one:

Gateway Best Suited For Key Channels Supported Integration Type
PesaPal SMEs & E-commerce Visa, Mastercard, M-Pesa, Airtel Money, T-Kash Redirect, Iframe, REST API
DPO Group Travel, Hospitality & Enterprise Visa, Mastercard, AMEX, Mobile Money (East & Pan-Africa) Hosted Page, API Direct
iPay Africa Hybrid Retail & Billing Visa, Mastercard, M-Pesa, Airtel Money, Pesalink, Equity Custom Checkout, REST API
Paystack SaaS, Startups & Developers Visa, Mastercard, M-Pesa, Apple Pay Popup, Inline, Custom SDKs
Flutterwave Cross-border Commerce Visa, Mastercard, M-Pesa, Airtel Money, Card Acquiring Hosted Checkout, Custom API

Integration Flow & Security

Payment details should be handled by a flow that matches the provider's security model and your PCI-DSS responsibilities. Common patterns include:

  • Redirect / hosted checkout: The customer completes payment on a provider-hosted page and returns to your application. Confirm the provider's redirect and webhook rules before marking an order paid.
  • Embedded iframe / modal: The provider's checkout is embedded in your page. The exact compliance scope depends on the provider and implementation.
  • Direct API: A custom interface uses the provider's approved tokenization or client-side SDK. Do not send raw card data through your own servers unless your compliance and security design explicitly supports it.

Sample Checkout Session Initiation

The following example is illustrative only. Replace the placeholder provider URL, fields, and signature rules with the contract for the gateway you selected.

Initiate Payment Session
curl -X POST https://api.gateway-provider.com/v1/checkout \
  -H "Authorization: Bearer secret_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 5000,
    "currency": "KES",
    "email": "[email protected]",
    "reference": "TXN-789012",
    "callback_url": "https://yourwebsite.co.ke/payment/callback",
    "description": "Consulting Fee Payment"
  }'
$client = new \GuzzleHttp\Client();

$response = $client->post('https://api.gateway-provider.com/v1/checkout', [
    'headers' => [
        'Authorization' => 'Bearer secret_key_here',
        'Content-Type'  => 'application/json',
    ],
    'json' => [
        'amount'       => 5000,
        'currency'     => 'KES',
        'email'        => '[email protected]',
        'reference'    => 'TXN-789012',
        'callback_url' => 'https://yourwebsite.co.ke/payment/callback',
        'description'  => 'Consulting Fee Payment'
    ]
]);

$paymentDetails = json_decode($response->getBody()->getContents(), true);
$redirectUrl = $paymentDetails['redirect_url'];
const axios = require('axios');

axios.post('https://api.gateway-provider.com/v1/checkout', {
    amount: 5000,
    currency: 'KES',
    email: '[email protected]',
    reference: 'TXN-789012',
    callback_url: 'https://yourwebsite.co.ke/payment/callback',
    description: 'Consulting Fee Payment'
}, {
    headers: {
        'Authorization': 'Bearer secret_key_here',
        'Content-Type': 'application/json'
    }
})
.then(response => {
    const redirectUrl = response.data.redirect_url;
    window.location.href = redirectUrl;
})
.catch(error => console.error(error));

Payment notifications (IPN)

Do not rely only on the browser redirect to decide that an order is paid. The provider's IPN or webhook should be verified and used to update the order state on your server.

Sample IPN Webhook Payload
{
    "event": "charge.success",
    "data": {
        "id": 9876543,
        "domain": "live",
        "status": "success",
        "reference": "TXN-789012",
        "amount": 5000,
        "currency": "KES",
        "gateway_response": "Successful",
        "paid_at": "2026-06-20T09:14:12Z",
        "channel": "card",
        "card": {
            "last4": "1234",
            "exp_month": "12",
            "exp_year": "2028",
            "card_type": "visa"
        }
    }
}

Making the payment flow dependable

Once the basic checkout works, the important work is making failures and reconciliation predictable:

  • Failure handling: Make timeout, declined, and duplicate-payment states explicit.
  • Reconciliation: Compare provider settlement reports with the internal order and ledger records.
  • Currency handling: Record the currency and settlement amount rather than assuming every provider settles in KES.
  • Fraud controls: Use the checks and 3-D Secure capabilities supported by the selected provider.

Partner with Us for Payment Integrations

If you are adding card payments or several local payment methods, contact the Statum team with the provider and checkout flow you are considering.