Kaspi is not just a bank — it is Kazakhstan's main payment and commerce ecosystem. People pay with Kaspi Pay and QR in retail and for services, while for thousands of sellers Kaspi Magazin effectively replaces having their own online store. It is only logical that any business running sales in Bitrix24 sooner or later asks the same question: how to link Kaspi and the CRM so that payments and orders land in the funnel automatically. And almost immediately they run into an unpleasant truth — there is no official one-click 'Kaspi for Bitrix24' connector. In this article, we break down, without marketing fog, which schemes actually work in 2026, what they deliver, what they cost in fees, and where the pitfalls are hidden.
If you would rather have it done for you, we set up Kaspi + Bitrix24 integration: payment links, payment acceptance and Kaspi Store orders in your CRM.
Why there is no one-click 'Kaspi connector for Bitrix24' — and what actually works
Kaspi does not release a public payment connector for third-party CRMs as a ready-made app in the Bitrix24 marketplace, the way some acquiring services do, for example. Access to features is granted selectively: acquiring and payment links are available through a contract with the bank, while Kaspi Magazin data is available through the Merchant API, which a seller is connected to upon application. That is why any Kaspi–Bitrix24 link is assembled from several building blocks rather than enabled with a single checkbox in the settings.
In practice there are three working directions, and they can be combined with each other:
- Accepting payments — Kaspi payment links and QR codes that are generated and sent to the client straight from the deal card.
- Issuing invoices and acquiring — Kaspi Pay as a payment method for an online order or invoice in the CRM.
- Orders from Kaspi Magazin — pulling new marketplace orders into the Bitrix24 funnel via API, an intermediary, or import.
It is important to be honest about expectations up front: the first two directions solve the task of 'getting the money and recording the payment in the CRM,' while the third solves 'not losing marketplace orders and processing them in the same funnel as everything else.' These are different tasks, different connections, and different pitfalls. Below we cover each one.
Method 1: Kaspi payment links and QR codes straight from the deal card
The most common and simplest scenario for services and B2C sales. A manager runs a deal in Bitrix24, has agreed on the amount, and needs to send the client a Kaspi payment link or QR code in a single move, then see the payment reflected in the CRM afterward. Technically this is done through Kaspi payment links (Kaspi Pay / Kaspi QR), which your business obtains under an acquiring contract with the bank.
How it works
- In Bitrix24, the deal card has a built-in 'Invoice for payment' mechanism, as well as CRM forms / Smart Processes for online payment — a payment system can be linked to them.
- A link or QR code is generated for the specific deal amount and sent to the client via WhatsApp, SMS, or email straight from the timeline.
- After payment, the status can be pulled back in via a webhook from the payment provider, and a robot can move the deal to the 'Paid' stage.
The key nuance: 'bare' Kaspi acquiring cannot always send a webhook specifically to Bitrix24 in a convenient format. That is why the link is often built through an intermediary — a payment aggregator that is officially connected to Kaspi and at the same time has a ready-made module or webhooks for Bitrix24. Then the manager clicks 'Issue invoice,' the client pays via Kaspi, and the deal moves automatically.
Method 2: issuing invoices and accepting payments via Kaspi Pay / acquiring
This method is a continuation of the first, but with a focus on online payment by invoice and internet acquiring. It suits cases where you have a website or online store on Bitrix24 (or an external site that feeds leads into the CRM) and you need the client to pay for the order by card or via Kaspi right on the payment page.
What you need for this
- An internet acquiring contract that includes Kaspi payment (via a Kaspi Gold card or through the Kaspi app).
- A configured payment system in the CRM → Payment Methods section or in the Bitrix24 online store.
- Linking the payment system to orders / invoices so that the payment link is generated automatically when an invoice is created.
The advantage of this scheme is that the payment is recorded in Bitrix24 as a fact tied to a specific invoice, rather than 'money came in somewhere on the settlement account.' This is critical for reconciliation: you can see which invoice and which deal were paid, not just an amount in a bank statement. The downside is that you need to account for the acquiring fee, which is built into the price or the margin, and to remember the timing of money being credited to your account (usually not same-day).
The rule is simple: if a payment is not tied to a specific deal or invoice in the CRM, you have not integrated Kaspi — you have simply received money. Integration begins where the payment itself moves the funnel.
Method 3: orders from Kaspi Magazin into the Bitrix24 funnel (API, intermediaries, import)
For Kaspi Magazin sellers, the main pain is not payment (the marketplace handles that) but orders: they arrive in the Kaspi dashboard, and managers process them separately from the rest of the CRM. As a result, part of the business lives in Bitrix24 and part in the Kaspi dashboard, analytics are fragmented, and statuses have to be duplicated by hand. There are three ways to link this together.
Option A — directly via the Kaspi Merchant API
Kaspi provides sellers with an API for working with Magazin orders and products (receiving new orders, changing statuses, uploading stock and prices). On top of it, an integration is written that pulls new orders on a schedule and creates deals in the right Bitrix24 funnel, filling in products, amount, full name, and delivery. This is the most flexible but also the most labor-intensive path: you need a developer and ongoing support, because the API and its limits change.
Option B — a ready-made intermediary / connector
There are middleware services on the market that already know how to pull Kaspi Magazin orders and put them into Bitrix24 (or into 1C, and from there into the CRM). You pay a subscription and get a ready-made exchange without your own development. This suits cases where the order volume is moderate and there is no resource for in-house code, but it is important to check exactly which fields and statuses the connector transfers.
Option C — manual or semi-automatic import
The most budget-friendly start: export orders from the Kaspi dashboard to a file and import them into Bitrix24, or use simple automation via scenarios. This works for small volumes and as a temporary solution until a proper exchange is set up. The downside is obvious — it is manual labor and the human factor in reconciliation.
Automation: changing the deal stage and notifying the manager after payment
The mere fact that 'the money has arrived' is useless if the CRM does not know about it. That is why accepting a payment must always be backed by automation in Bitrix24. The minimally useful set of robots and triggers looks like this:
- Payment received via a payment link or invoice → the deal automatically moves to the 'Paid' stage.
- After the stage change → a notification to the manager and the person responsible for shipping (chat, push, or email).
- A new order from Kaspi Magazin → creating a deal in a separate funnel with the source 'Kaspi' for clean analytics.
- If the payment is partial → the deal stays at an intermediate stage and a task 'collect the rest of the payment' is created.
This is also a convenient place to wire in an automatic message to the client via Wazzup (WhatsApp): 'payment received, the order has been put into processing.' For retail and services, this kind of confirmation removes half of the 'did you get my payment?' calls. The main thing is to trigger robots on the actual payment event, not on a manual move by the manager — otherwise the automation turns into a fiction.
Reconciliation and fees: how not to lose money and statuses between Kaspi and the CRM
Reconciliation is where most homemade integrations fall apart. Kaspi money reaches your account not instantly and minus a fee, while in the CRM the deal is often marked 'Paid' for the full order amount. As a result, the amounts in Bitrix24 and at the bank do not match, and accounting cannot tell what was actually received.
- Record two amounts in the deal: the order amount and the amount actually credited (minus the acquiring / Kaspi Magazin fee).
- Tie the payment to a specific invoice or order, not just to a contact — otherwise reconciliation against the statement is impossible.
- Account for the crediting timeline: while the money is in transit, the deal can be at the 'Payment confirmed' stage but not 'Money in the account.'
- Regularly reconcile the Kaspi / bank report against an export of Bitrix24 deals — that is exactly how discrepancies are caught.
A fee is not a 'technical trifle' but a line item that hits your margin directly. Build it into your financial model in advance: the percentages differ for the marketplace and for acquiring, and they depend on the product category and contract terms. Always confirm the exact rates in your own contract with Kaspi — public figures go out of date quickly, and plugging someone else's into your model is dangerous.
Pitfalls: API limits, legal entity / sole proprietor, refunds, and partial payments
A few things almost everyone stumbles over during the first connection:
- API limits and changes. The Kaspi Merchant API has request-rate limits and changes periodically — the integration needs to be maintained, not 'set up and forgotten.'
- Business form. Acquiring and API access are set up for a sole proprietor (IP) or LLP (TOO) with a valid contract; you cannot build a full integration on an individual.
- Refunds. A Kaspi refund must be reflected in the CRM too — otherwise revenue analytics are overstated. Build a separate scenario for cancellations and refunds.
- Partial payments and prepayments. If the business works with prepayment, you need logic for two payments on one deal, otherwise the stages will lie.
- Duplicate orders. When importing from Kaspi Magazin, it is easy to create a duplicate deal — be sure to set up deduplication by order number.
Separately about statuses: Kaspi Magazin has its own order status model (new, in assembly, handed to delivery, issued), and it needs to be deliberately mapped to the stages of your funnel rather than copied mechanically. Otherwise managers will see stages in the CRM that do not match what the Kaspi app shows the client.
Which method to choose for your business: retail, services, online store
To avoid overpaying for the unnecessary, choose a scheme that fits your sales model:
- Services and B2C sales by managers (repair, training, agencies) — Method 1: payment links and QR codes from the deal card. Minimum investment, maximum speed.
- A website or online store on Bitrix24 — Method 2: acquiring with Kaspi payment right on the order page plus automatic stage changes.
- A Kaspi Magazin seller with a stream of orders — Method 3: pulling marketplace orders into a separate funnel, via API or a ready-made intermediary.
- A mixed model (both store and services) — a combination: Kaspi Magazin orders into one funnel, payment links for direct sales into another.
The main criterion is volume. With a few orders a day, you start with manual import and payment links. With dozens and hundreds, your own API exchange or a connector pays for itself through the managers' time saved and the absence of reconciliation errors.
Connection checklist and what to prepare before you start
Before you start linking Kaspi and Bitrix24, prepare the groundwork — it cuts the connection time several times over:
- Define the goal: accepting payments, orders from Magazin, or both.
- Check your business form (sole proprietor / LLP) and whether you have an acquiring contract and/or access to the Kaspi Merchant API.
- Decide which funnels and stages in Bitrix24 will be responsible for payments and for Kaspi orders.
- Resolve the reconciliation question: where you record the fee and the actually credited amount.
- Describe scenarios for refunds, partial payments, and cancellations — before launch, not after.
- Set up order deduplication and the mapping of Kaspi statuses to CRM stages.
- Connect notifications to the manager and an automatic message to the client after payment.
Linking Kaspi and Bitrix24 is realistic even without a 'magic button' — you just need to honestly choose a scheme that fits your business and carefully close out the questions of fees, reconciliation, and statuses. Then the payment moves the funnel by itself, marketplace orders are not lost, and managers work in a single system instead of switching between the Kaspi dashboard and the CRM. Start with one direction, get it to run reliably — and only then expand.
