Payment Integration in Uzbekistan: a Complete Business Guide for 2026

No modern business — an online store, a delivery service, a booking app or a SaaS platform — works properly without convenient online payments. In Uzbekistan that task has its own character: the market is digitising fast, but it has its own rules, its own leaders and its own technical quirks.

This article covers how the payment ecosystem in Uzbekistan is put together, which services are worth integrating first, the technical and organisational obstacles a business runs into, and how to build a payment infrastructure that works reliably and scales with your product.

1. Why Payment Integration Is Not Just “Adding a Pay Button”

Many business owners treat payment integration as a formality: find an API, paste the code, done. In practice it is one of the most sensitive modules in any product. It is tied directly to customers’ money and the company’s reputation, it is subject to local legislation and Central Bank requirements, and it demands particular care around security and the protection of personal data.

It also has to run reliably around the clock, and it sits directly on the conversion path. Both of those turn engineering decisions into revenue numbers rather than technical preferences.

Every extra step or error in the payment flow lowers the share of successful purchases — and a payment gateway that is down is lost revenue, not a backlog item.

That is exactly why the choice of payment providers and integration architecture belongs at the start of a project, not on the “later” pile.

2. The Main Players in the Uzbek Market

Payme

Payme is one of the country’s most recognisable payment services, originally grown out of a mobile wallet and since turned into a full business ecosystem. For integration it offers Payme Business API — a REST API for taking payments on a site or in an app; Payme Subscribe — a tool for recurring subscription payments, which matters for SaaS and any service on a subscription model; and ready-made plugins for popular CMSs plus widgets for fast integration without deep customisation.

Payme is often picked for its wide user base and relatively clear documentation — though merchant certification and onboarding still take time and correspondence with technical support.

Click

Click is the oldest and one of the most widespread mobile payment services in Uzbekistan, tightly integrated with the country’s banking system. Its Click Merchant API follows the classic prepare/complete scheme, is well documented and is familiar to local developers. It supports both one-off and recurring payments, and it runs its own acquiring infrastructure, which simplifies settlement for local businesses.

Click is especially strong in high-frequency b2c services: taxis, food delivery, utility payments.

Uzcard and Humo

Uzcard and Humo are the national payment systems behind most of the bank cards people in Uzbekistan actually carry. Unlike Payme and Click, which act as aggregators and convenient wrappers for the end user, Uzcard and Humo are more often connected directly through an acquiring bank — via a particular bank’s processing centre — as part of a broader acquiring solution that already supports both card schemes under the hood, or through an SDK for in-app payments with card storage and later charges.

Most projects do not need to integrate with Uzcard and Humo directly — the acquiring bank or the payment aggregator already supports both.

Visa, Mastercard and Cross-Border Payments

If the business is not aimed solely at the local market and plans to take payment from tourists, expats or clients abroad, budget for Visa/Mastercard support through a bank that holds the corresponding acquiring licence. That is a separate integration track with its own security requirements — the PCI DSS standard in particular.

3. What Integration Looks Like, Step by Step

Here is the typical path a company walks when connecting a payment system — Payme or Click, say — to its website or mobile app.

Step 1. Merchant registration. You apply to register as a merchant with the chosen payment system. This usually requires the company’s legal documents (certificate of registration, tax ID, bank details), a description of the business model and the type of goods or services, a link to the site or app prototype where payment will happen, and sometimes a contract with an acquiring bank if the payment system operates through a partner bank. Expect anywhere from a few days to a few weeks, depending on how complete your document pack is and how busy the provider’s support team is.

Step 2. Sandbox access. After preliminary approval you get a test environment where payments can be sent without real money moving. This stage is critical: it is where developers verify the handling of both successful and failed transactions, the system’s behaviour on timeouts and network failures, webhook processing (payment status notifications), and refund and cancellation scenarios.

Step 3. Building the integration. The backend team implements the interaction with the payment system’s API. As a rule that means creating a payment (initialising a transaction with amount, currency and order number), handling the redirect to the payment page or embedding the payment form via iframe/SDK, receiving and validating status-change webhooks, logging every operation for later reconciliation and dispute resolution, and handling request idempotency so a retry cannot charge the customer twice.

Step 4. Testing and provider acceptance. Before going live the payment system usually runs its own acceptance pass on the integration, checking that the merchant handles every scenario correctly, errors and cancellations included. Production keys are issued only after that.

Step 5. Launch and monitoring. Once live, the payment module should not be left unattended. Set up alerts for payment conversion dropping below a threshold, monitoring of the payment system’s API response time, regular reconciliation between your database and the provider’s reports, and a fallback path for when the main provider is unavailable.

4. The Technical Details People Forget

Idempotency and protection against double charges. Network failures are routine, and a customer may accidentally — or deliberately — send a repeat payment request. Sound architecture always uses unique transaction identifiers and checks whether an operation has already been processed before creating a new one.

The asynchronous nature of payments. Many developers starting out expect payment to be confirmed instantly and synchronously. In practice the status often arrives asynchronously, via a webhook that can be delayed by seconds or even minutes. The interface has to handle a “payment processing” state properly, without blocking the user or showing false errors.

Security and data storage. Even when the payment system stores the card numbers — which is almost always the case, and your server should never see a full card number — you still need encryption in transit (TLS), webhook endpoints protected against forged requests (signature verification, IP filtering), restricted access to logs containing financial information, and regular dependency audits with server software kept up to date.

A multi-provider strategy. Experienced teams often connect several payment systems at once — Payme and Click together, for instance — and let the user choose. That lifts conversion, reduces the risk of downtime while one provider does maintenance, and widens reach, since not every user is equally loyal to a particular wallet.

Multi-provider support does complicate the architecture, though: it needs a single internal abstraction layer — a payment gateway layer — that hides the differences between provider APIs and gives the rest of the system one unified interface for creating payments, handling statuses and issuing refunds.

5. Regulatory Considerations

Payments in Uzbekistan are regulated by the Central Bank of the Republic of Uzbekistan, and any business handling money transfers and payment acceptance has to account for merchant identification and business-model transparency requirements, restrictions on the activities for which online payment acceptance is available (some categories need additional licences or approvals), the rules on storing and processing customers’ personal data under the personal data law, and periodic reporting plus possible audits from payment systems and partner banks.

We recommend consulting not only developers at the start of a project but also a lawyer or accountant familiar with the specifics of Uzbek payment legislation — it saves weeks at the approvals stage.

6. How Long Integration Takes

Realistic timelines for a typical project:

Leave a buffer for dealing with the payment systems’ support teams — that is an external factor a development team cannot speed up on its own. We went through the same trade-off week by week in “An MVP in Eight Weeks”, where payments are one of the modules that decide whether the deadline holds.

7. Common Mistakes Businesses Make

Leaving integration to the last stage of development. Merchant registration and API access can take weeks — start that process in parallel with product development, not after the rest of the functionality is finished.

Ignoring error scenarios. Many teams test only the happy path — a successful payment — and forget cancellations, expired sessions, insufficient balance and timeouts.

No transaction reconciliation. Without regular automatic reconciliation between the internal database and the payment system’s reports, discrepancies slip through — and they are hard to explain to accounting later.

Hard-wiring a single provider with no abstraction layer. If a year from now you need to add a second provider or replace the main one, a significant part of the code has to be rewritten unless flexible architecture was there from the start.

Underestimating the support load. Payments are one of the leading reasons customers contact support. Think through in advance how a customer will see the status of their payment and where they go when something goes wrong.

8. How to Choose a Partner for Payment Integration

If you decide to hand payment integration to an outside team, a few criteria are worth weighing. Experience with the local providers specifically: working with Payme, Click, Uzcard and Humo differs from integrating a hypothetical Stripe, and it matters that the team has genuinely done it in this market.

An understanding of the full cycle, not just writing code: from help with the document pack for merchant registration through to setting up monitoring after launch. An approach to security in which webhook protection, idempotency and correct logging are the default rather than something added on request. And a willingness to explain the business logic, not only the technical detail — payments are too important for the business owner not to understand how a core part of their product works.

9. Fees and the Economics of Payments

A separate question, often underestimated at the start, is payment system fees and how they affect the product’s unit economics. The rate depends on the business category, turnover volume and the specific terms agreed with the provider or acquiring bank, so exact figures are worth confirming individually when you apply. A few principles are still worth building in.

The fee is part of the cost of a transaction, not a one-off payment, so it belongs in the margin calculation for every order rather than only in the company’s overall P&L. Transaction volume affects the terms: large merchants with high turnover can often negotiate better rates, so it is worth revisiting the terms as the business grows.

Refunds and cancellations can carry a fee too, depending on the provider’s terms, so the refund policy published on the site should match the payment system’s actual mechanics. Multi-currency operations, if the business takes foreign cards, usually sit on a different rate card and need separate agreement with the bank.

10. What a Mature Payment Infrastructure Looks Like

To pull all of the above together, here is an architecture worth planning for a mid-sized e-commerce or service project in Uzbekistan.

A payment gateway layer on the backend takes a single internal “create a payment” request from the rest of the system, knowing nothing about the specific provider. Adapters for each provider — Payme, Click and, where needed, Visa/Mastercard acquiring — translate the internal format into the format of a particular API.

A webhook processing queue receives provider notifications asynchronously, verifies the request signature and only then updates the order status — which is what protects the system from forged or duplicated notifications. A reconciliation service compares the transaction list in the internal database against the reports received from the payment systems every day and produces a discrepancy report for accounting automatically.

A monitoring panel shows the support team the status of every payment in real time, which sharply cuts response time on the classic “the money left my account but the order is unconfirmed” enquiry.

This architecture takes longer to build up front, but it pays for itself within months through fewer incidents and much simpler addition of new payment methods later.

11. Frequently Asked Questions

Can you take payment by foreign cards without a partnership with a local bank? In most cases accepting international Visa/Mastercard requires an acquiring agreement with a bank that holds the corresponding licence, or the use of a payment aggregator that already provides this as part of its infrastructure.

Do you need to integrate with Uzcard and Humo separately if Payme or Click is already connected? As a rule, no — as aggregators, Payme and Click already support Uzcard and Humo cards under the hood, and a separate direct integration is only needed in specific cases, such as working directly with an acquiring bank.

How many providers should you connect at the start? For an MVP one main provider is usually enough to reach the market faster and test the hypothesis. A second one makes sense once the product has confirmed demand and the team is ready to invest in a more complex architecture.

What do you do when a payment system is temporarily unavailable? Good practice is a clear message for the user in the interface and, if several providers are connected, automatically offering an alternative payment method instead of blocking the purchase entirely.

12. Conclusion

Payment integration in Uzbekistan is not a one-off technical task but a piece of business infrastructure that needs attention across the product’s whole life: from choosing a provider and registering as a merchant through to monitoring and scaling. Payme, Click, Uzcard and Humo form the base of the local payment ecosystem, and combining them well — with security, regulation and user convenience all accounted for — feeds directly into conversion and customer trust.

Companies that lay down a solid payment architecture at the start, rather than patching one together as they grow, gain a real advantage: less technical debt, better stability, and more time spent developing the product instead of picking apart payment incidents.

Start Point IT is a full-cycle software development agency with experience integrating Payme, Click, Uzcard and Humo into web and mobile products. If you need advice on the payment architecture for your project, get in touch.