In short
If your company sells into Kazakhstan, at some point someone on the team will ask why the checkout doesn't take Kaspi Pay. Kaspi is the dominant consumer payment rail in the country the way Alipay or WeChat Pay dominate in China, or GCash in the Philippines: a bank-owned super-app with its own QR standard, and most local shoppers simply expect it at checkout. Building for it is less like adding a card processor and more like onboarding into a closed national payment network.
There are three practical routes, and they trade speed for durability in opposite directions. Official partnership through Kaspi Pay gives you a real merchant contract and webhook-driven confirmation, but it demands a Kazakhstan legal entity, a digital signature, an IPSec VPN tunnel, and one to three weeks of technical work after approval. Generating a Kaspi QR code per order and reconciling manually gets you live in a day, with no automation. Third-party "Kaspi Pay API" gateways promise a REST integration in fifteen minutes — and that speed usually comes from wrapping internal Kaspi mechanisms that were never designed as a public API for outside developers.
Why this isn't like adding Stripe
Most payment integration guides assume a public, documented REST API with a sandbox, API keys, and a support queue. Kaspi Pay doesn't work that way for external merchants. There's no open API comparable to Stripe or Adyen that any developer can sign up for and start calling that afternoon. The only durable path into the network is a direct partnership agreement with Kaspi Pay LLC — a contract of adhesion, accepted in full on Kaspi's standard terms, the same way every merchant does it, with no custom clauses.
That single fact explains most of the confusion in Kazakh developer forums and outsourced dev-shop pitches: what gets marketed as "Kaspi Pay API" by a third party is almost never the same thing Kaspi offers its signed partners.
Route one: official partnership
Applications go through kaspi.kz/webpay/partnership. The prerequisites are concrete: a registered Kazakhstan entity (sole proprietor or LLC), an active account at a Kazakhstan bank, an electronic digital signature (EDS), an HTTPS site with a valid certificate, the ability to stand up an IPSec VPN tunnel to Kaspi's infrastructure, and a backend that can receive JSON webhooks over a RESTful contract.
Source: the public Kaspi WebPay partnership page, public page captured in July 2026.
After approval, the technical build tends to run 3-5 business days for basic QR checkout, 7-10 days if you're building custom UI and CRM sync, and two weeks or more once 1C or a full VPN data contour enters the picture. The approval step itself — Kaspi reviewing and accepting the partnership application — can take longer than the engineering work, so it belongs at the front of any launch timeline, not as an afterthought.
The upside is real: you're dealing directly with the operator, funds move through the sanctioned rail, and support responds as Kaspi rather than as a reseller who connected to the network through means nobody can fully explain.
Route two: QR checkout without a contract
For a small storefront or a single-product landing page, full partnership can be more infrastructure than the volume justifies. The lighter path is generating a Kaspi QR code on the payment step after checkout — the customer scans it or opens the Kaspi.kz app directly on mobile, pays, and a staff member confirms the payment manually against a statement or an app notification.
This needs no VPN and no formal acquiring agreement, but it also gives you no automatic "paid" state on the site — reconciliation is a human step. That's fine at ten or twenty orders a day. Past that, manual matching turns into a job of its own, and it's usually cheaper to automate the confirmation than to hire someone whose entire role is checking a banking app against an order list.
This is a different product from the Kaspi Merchant seller cabinet, which is built for the Kaspi.kz marketplace and offline point-of-sale rather than for embedding payment into your own checkout flow. If you're selling through the marketplace itself, that's a separate integration path worth understanding on its own terms.
Route three: third-party gateways, and what they actually are
Several services — commonly marketed under names like ApiPay or similar regional providers — advertise a REST API for Kaspi Pay: pay-by-phone-number, automatic invoicing, status webhooks, SDKs in JavaScript, Python, and PHP, with onboarding claimed at fifteen minutes and no direct Kaspi contract required.
Here's the honest read: Kaspi has no public REST API for accepting payments on an arbitrary website, comparable to what Stripe or a standard acquirer exposes. What these gateways expose is a wrapper around Kaspi's internal mechanisms — often the same endpoints the mobile app or the merchant cabinet uses — never built as a stable, versioned, third-party-facing interface. Some open-source client libraries built on this say directly in their docs that they are not officially connected to Kaspi.kz.
Three risks follow. The integration can break without warning, since Kaspi owes no SLA to an interface it never published. The money often doesn't move through a licensed acquiring relationship with your business as the contracting party — it passes through someone else's account or a middle layer, which raises real questions for accounting and fiscal compliance. And when a customer dispute or account block happens, there's no direct line to Kaspi support; you're dependent on a third party who is itself dependent on the same unstable mechanism.
These gateways can be a reasonable choice for a fast prototype or an MVP where the goal is proving demand before an investor call. Betting a live store's only payment channel on unofficial access means the checkout can simply stop working one day, and no one on the other end is contractually obligated to care.
The fiscal receipt requirement nobody puts in the API docs
The part that gets left out of most integration writeups is the tax receipt. Under Article 166 of Kazakhstan's Tax Code, online cash register (ККМ) equipment with real-time data transmission to a fiscal data operator is mandatory for most businesses, and payment via Kaspi Pay doesn't change that requirement. A fiscal receipt has to be generated for every sale, regardless of whether the money arrived by card, Kaspi QR, or bank transfer.
In practice, that means integrating Kaspi Pay on a website is not just a payments problem — it's a payments-plus-fiscal-cash-register problem. Local services like E-Kassa or Webkassa handle the receipt side, and the integration needs to connect payment confirmation to receipt issuance so the two happen together, not with a manual gap in between. If a human confirms payment by eyeballing a bank statement instead of an automated webhook, the delay between payment and receipt is already a compliance gap — it just doesn't get noticed until an audit.
Whichever of the three routes you pick, ask up front how payment status reaches the cash register module and who's accountable if a receipt doesn't fire in time. Official partnership with webhooks solves this in code. Manual QR reconciliation leaves it as an open gap that eventually surfaces during a tax review.
Choosing a route for your business
If the business is past the early-traction stage and real revenue is flowing through the checkout, official partnership is worth the two-to-three-week lead time — it's the only route where accountability for an outage sits with the party you have a contract with.
If this is a demand test, a single-product landing page, or a store doing a handful of orders a day, Kaspi QR with manual reconciliation gets you live fast, with the understanding that it needs replacing once order volume grows.
Third-party gateways make sense only when you've accepted that the integration might disappear and you have a fallback plan. Making one the sole payment channel for a live store is a decision companies tend to regret roughly six months in, once order volume makes the outage actually expensive.
Beyond the payment method itself, there's the layer around it: confirming the order to the customer, notifying them of payment status, and answering the "did my payment go through" messages that land in WhatsApp or a support inbox minutes after checkout. If the store also sells through Kaspi marketplace, the payment route should be designed next to the Kaspi Merchant API and the seller cabinet flow, not as a separate island. We build that layer as part of GPT and API integration work — payment status, CRM, and customer messaging running as one connected system instead of three that nobody reconciles by hand.
FAQ
Is there an official public API for Kaspi Pay?
The official route is a partnership agreement through kaspi.kz/webpay/partnership, with webhook-based confirmation over an IPSec VPN tunnel. There is no open REST API at Stripe's level of accessibility — what gets marketed as "Kaspi Pay API" by third parties is typically a wrapper around internal mechanisms not built for outside integrators.
How long does Kaspi Pay integration take?
Basic QR checkout usually runs 3-5 business days once the partnership application is approved, custom UI and CRM sync run 7-10 days, and a full 1C and VPN setup runs two weeks or more. Kaspi's own review of the partnership application can take longer than the technical build itself.
Can I accept Kaspi Pay without a formal partnership?
Yes, either through manual QR-code reconciliation or through a third-party gateway. The first option is legitimate but doesn't scale past low order volumes. The second carries real risk of the integration breaking without notice and raises fiscal-compliance questions during a tax review.
Do I need a separate cash register for Kaspi Pay sales?
Yes. Article 166 of Kazakhstan's Tax Code requires a fiscal receipt for every sale, including payments made through Kaspi Pay. The online cash register needs to be tied to payment status so the receipt fires at the moment of payment, not on a delay.
If checkout is already live and payment is the bottleneck, start by asking how many payments actually go through per day and what happens if that channel goes dark for twenty-four hours. That answer usually decides which of the three integration routes is worth building.