Pay with Pesalink on Paystack: Developer Guide

Pesalink is Kenya's real-time interbank payment network. It is operated by Integrated Payment Services Limited (IPSL), a company owned by the Kenya Bankers Association. When a customer pays via Pesalink, the money moves directly from their bank account to the merchant's bank account in real time. No cards, no mobile money, no float.

For most Kenyan developers, M-Pesa is the default payment method. And for good reason. More Kenyans have M-Pesa than have bank accounts. But there are transactions where M-Pesa is not the right fit:

• High-value payments. M-Pesa has a per-transaction limit (currently around KES 150,000 for most users). School fees, rent, wholesale orders, and equipment purchases often exceed that. Pesalink handles larger amounts.
• Corporate buyers. Businesses and institutions often prefer to pay from their bank account. Their finance departments work in bank statements and ERP systems, not M-Pesa statements.
• Float constraints. M-Pesa agents and users can run into float limits. Bank accounts do not have the same constraint. The money is in the account or it is not.
• Real-time settlement. Pesalink transfers settle in real time, 24 hours a day, 7 days a week. This includes weekends and holidays. For time-sensitive transactions, this matters.

Pesalink is not going to replace M-Pesa for everyday transactions. But for the use cases listed above, it fills a gap that M-Pesa cannot. And through Paystack, you get it as part of the same integration you already have. No separate API to learn.

Pesalink is available at most major banks in Kenya. The network currently includes over 40 banks and microfinance institutions. The banks your customers are most likely to use include:

• KCB Bank
• Equity Bank
• Co-operative Bank
• NCBA (formerly CBA and NIC)
• Absa Bank Kenya (formerly Barclays)
• Standard Chartered
• Stanbic Bank
• Diamond Trust Bank (DTB)
• I&M Bank
• Family Bank
• Bank of Africa
• KWFT (Kenya Women Finance Trust)

The full list of participating banks is maintained by IPSL and can change as new institutions join the network. When a customer selects Pesalink at Paystack's checkout, Paystack presents the list of available banks. The customer picks their bank and is redirected to authorize the payment.

In practice, KCB, Equity, and Co-op Bank cover the majority of banked Kenyans. If Pesalink works with those three, you are reaching most of the addressable audience for bank transfer payments.

Here is what the customer sees when they choose Pesalink at a Paystack-powered checkout:

1. Payment method selection. The Paystack checkout popup or inline form shows available payment methods. If you have enabled bank_transfer, the customer sees a bank transfer option alongside M-Pesa and card.
2. Bank selection. The customer selects their bank from a list of supported institutions.
3. Authorization. Depending on the bank, the customer is either redirected to their bank's online banking portal, prompted via their banking app, or given a USSD code to dial. They review the payment details (amount, merchant name) and authorize it.
4. Confirmation. Once the bank processes the transfer, Paystack receives confirmation and redirects the customer back to your callback URL. The payment is complete.

The entire flow takes a minute or two. It is not as fast as M-Pesa STK push (which takes seconds), but it is significantly faster than manual bank transfers where the customer has to type account numbers and references.

One thing to communicate clearly to your users: Pesalink requires the customer to have an account at a participating bank and access to their banking app or USSD banking. This is obvious to developers but not always obvious to end users. A brief note like "Pay directly from your bank account" in your checkout UI helps set expectations.

On the Paystack side, Pesalink is part of the bank_transfer channel. You enable it by including bank_transfer in the channels array when you initialize a transaction.

Option 1: Transaction Initialize (server-side redirect)

const initializeWithPesalink = async (email, amountKes) => {
  const response = await fetch('https://api.paystack.co/transaction/initialize', {
    method: 'POST',
    headers: {
      Authorization: 'Bearer sk_live_YOUR_SECRET_KEY',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      email: email,
      amount: amountKes * 100, // Convert to cents
      currency: 'KES',
      channels: ['bank_transfer', 'mobile_money', 'card'],
      callback_url: 'https://yourapp.com/payment/callback',
    }),
  });

  const data = await response.json();
  // Redirect the customer to data.data.authorization_url
  return data.data.authorization_url;
};

// Accept a KES 250,000 school fees payment
const checkoutUrl = await initializeWithPesalink(
  'parent@example.com',
  250000
);
// Redirect the user to checkoutUrl

Option 2: Paystack Inline (client-side popup)

// In your frontend JavaScript
const handler = PaystackPop.setup({
  key: 'pk_live_YOUR_PUBLIC_KEY',
  email: 'parent@example.com',
  amount: 25000000, // KES 250,000 in kobo/cents
  currency: 'KES',
  channels: ['bank_transfer', 'mobile_money', 'card'],
  callback: function (response) {
    // Verify the transaction on your server
    verifyTransaction(response.reference);
  },
  onClose: function () {
    console.log('Checkout closed');
  },
});
handler.openIframe();

The key line is channels: ['bank_transfer', 'mobile_money', 'card']. This tells Paystack to show all three payment method options at checkout. If you want to offer only Pesalink (for example, on a page specifically for high-value payments), you can pass channels: ['bank_transfer'] alone.

Your backend does not need to know which channel the customer chose. When the payment completes, you receive the same charge.success webhook regardless of the method. The webhook payload includes a channel field that tells you how the customer paid, which is useful for analytics and reconciliation but does not change your processing logic.

Verification works the same way as any other Paystack payment. You verify using the transaction reference, either through the webhook or by calling the verify endpoint directly.

const verifyTransaction = async (reference) => {
  const response = await fetch(
    `https://api.paystack.co/transaction/verify/${reference}`,
    {
      headers: {
        Authorization: 'Bearer sk_live_YOUR_SECRET_KEY',
      },
    }
  );

  const data = await response.json();

  if (data.data.status === 'success') {
    const { amount, currency, channel } = data.data;
    console.log(`Payment of ${amount / 100} ${currency} via ${channel}`);
    // channel will be 'bank_transfer' for Pesalink payments
    return true;
  }

  return false;
};

The channel field in the response will be bank_transfer for Pesalink payments. You can use this information for reporting (e.g., "45% of our payments over KES 100,000 come through Pesalink") but your fulfillment logic should not branch on it. A successful payment is a successful payment regardless of the channel.

Always verify on your server. Never rely on the client-side callback alone. This applies to Pesalink just as it applies to M-Pesa and card payments. The webhooks guide covers the full verification and webhook handling pattern.

One of the main reasons to offer Pesalink is its higher transaction limits compared to M-Pesa. Here is how the limits compare at a high level:

Factor	M-Pesa	Pesalink
Per-transaction limit	Varies by user tier, generally up to KES 150,000	Higher limits, varies by bank
Daily limit	KES 300,000 for most users	Depends on bank account type
Availability	24/7	24/7
Settlement to merchant	Through Paystack settlement cycle	Through Paystack settlement cycle

Important caveats:

• These limits are approximate and change. Safaricom adjusts M-Pesa limits periodically. Banks set their own Pesalink limits based on account type and customer profile. Do not hard-code limits into your application. Instead, handle limit-related failures gracefully.
• Paystack may impose its own limits on top of the underlying payment method limits. Check the Paystack documentation and dashboard for the maximum transaction amount they support for bank_transfer in Kenya.
• The customer's bank account balance is the real limit. Unlike M-Pesa where float can be an issue, bank transfers just need the funds to be in the account. For high-value B2B transactions, this is usually not a problem.

If your product regularly handles payments above KES 100,000, Pesalink should be a prominent option in your checkout. For school fees portals, rent collection platforms, and wholesale order systems, it is often the most practical payment method. See Building a School Fees Portal for a Kenyan School for a concrete example.

Not every checkout needs Pesalink prominently featured. Here is when it matters and when it does not.

Prioritize Pesalink when:

• Your average transaction value exceeds KES 50,000. At these amounts, M-Pesa limits become a friction point.
• Your customers are businesses or institutions that operate through bank accounts.
• You need payment confirmation for high-value transactions before releasing goods or services.
• You are building for sectors like education, real estate, healthcare, or wholesale where large payments are the norm.

Pesalink is less important when:

• Your typical transaction is under KES 5,000. At small amounts, M-Pesa is faster and more convenient for most Kenyans.
• Your users are primarily mobile-first consumers who may not have active bank accounts or banking apps.
• Speed of checkout matters more than payment flexibility. M-Pesa STK push completes in seconds. Pesalink takes a minute or two.

The smart approach is to offer all available methods and let the customer choose. Use the channels array to include ['mobile_money', 'bank_transfer', 'card']. Paystack's checkout will present them in a sensible order. If you know your audience leans toward bank transfers (e.g., a B2B platform), you can adjust the UI to feature Pesalink more prominently. For guidance on payment method placement, see Why Kenyan Checkout Conversion Depends on Mobile Money Placement.

Cards (Visa, Mastercard) are another option for payments above M-Pesa limits. So when does Pesalink beat cards, and when do cards win?

Pesalink advantages over cards:

• More Kenyans have bank accounts than have debit or credit cards. Pesalink reaches those customers.
• No 3D Secure friction. Card payments require the customer to enter card details and go through 3D Secure authentication. Pesalink uses the bank's existing authentication (app PIN, fingerprint, USSD).
• No card fraud risk. Pesalink is an authenticated bank transfer. The customer authorizes it directly with their bank. There are no chargebacks in the card sense.
• No card decline issues. Kenyan debit cards sometimes get declined for online transactions due to daily limits, international transaction blocks, or insufficient card limits (which can be different from the account balance).

Card advantages over Pesalink:

• International customers cannot use Pesalink. It is a Kenya-only network. If you serve customers outside Kenya, you need cards.
• Recurring payments. Cards can be tokenized for automatic recurring charges. Pesalink requires the customer to authorize each payment individually.
• Some customers simply prefer cards. Corporate credit cards, travel cards, and reward cards are used by a segment of Kenyan professionals.

The takeaway: offer both. Let the customer decide. Your backend code does not change either way.

Common issues you will encounter with Pesalink payments and how to handle them:

• Customer's bank not listed. If a customer's bank is not yet on the Pesalink network, they will not see it as an option. Direct them to M-Pesa or card payment instead. Your checkout should always offer at least two payment methods.
• Authorization timeout. The customer selects their bank but does not complete the authorization within the allowed window. The transaction expires. Display a clear message and let them try again with a new transaction.
• Bank app not set up. Some customers have bank accounts but have never activated their mobile banking app. They cannot complete a Pesalink payment through the app flow. USSD-based authorization (where supported) is the fallback, but not all banks support it for Pesalink.
• Amount exceeds bank limit. The customer's bank may have daily or per-transaction limits that are lower than the Pesalink network limit. The payment will be rejected by the bank. The customer needs to check with their bank or split the payment.
• Weekend and holiday processing. While Pesalink itself works 24/7, some banks may have limited processing windows for certain types of transactions. This is rare but worth knowing about if you see intermittent failures on weekends.

For network-level issues that affect all payment methods in Kenya, see Building for Kenyan Network Conditions: Retries and Timeouts.

Pesalink gives you a high-value payment method with minimal additional code. Here is where to go next:

• Paystack in Kenya: M-Pesa, Pesalink, and the Daraja Question for the full picture of payment methods in Kenya.
• Accepting M-Pesa Payments Through Paystack Checkout if you have not set up M-Pesa alongside Pesalink yet.
• Building a Kenyan E-Commerce Checkout for a complete checkout implementation that includes all payment methods.
• Apple Pay for Kenyan Merchants on Paystack for another payment method you can add to your checkout.

If you are building payment systems for the Kenyan market, the McTaba 26-week Full-Stack Software and AI Engineering bootcamp covers payment integration as part of a complete engineering education. You build and ship products that handle real money from real Kenyan customers.