Payme and Click on your website: accepting payments in Uzbekistan

The payment question almost always arrives in the same wording: how much does it cost to bolt Payme on. The answer depends not on the code but on who you are legally, what you sell and which payment scenario you actually need. Let me go through it in order, without numbers I do not have.

Does your business need online payments at all?

Not every business does. Online payment earns its place where the purchase happens without a conversation: an online store, a course, a subscription, delivery, a ticket. If you sell a service where scope and price get discussed - a construction company, a clinic, a studio - payment on the site does not make the deal faster, because a call still comes before it.

A common mistake is adding payment just to have it. It brings a contract, an integration, fiscalization and refunds with it, and it does not bring deals. First check whether you have a scenario where a person is ready to pay on their own, without asking anyone.

Where the line runs between a catalog without a cart and a real store with payments I covered separately: Online store or catalog website.

Who can connect Payme and Click?

This is the first question and the main filter. Payme checkouts work only with registered businesses - the legal forms ИП, ЧП, ООО, СП ООО, АО, УП and the others on the official list. A private individual without registration will not get card acceptance on a website, and there is no way around it: the money arrives in the business bank account, not on a card.

So three things are needed before any conversation about development:

A registered company or sole trader with a tax ID (ИНН).

A settlement account in a bank in Uzbekistan.

A contract with the payment system - with Payme that is a contract with АО "PAYME", with Click the contract is drawn up after an application through the business onboarding form.

If any of that is missing, website development runs its own course and payment is connected later: the button is added to a finished site as a small separate piece of work, once the documents are in hand.

How does a payment link differ from a full integration?

This is the fork that determines both the timeline and the price. Payme, for example, offers three checkout types, and they differ fundamentally in effort.

An on-site checkout works right after connection: you issue an invoice from the cabinet or the app, the client pays. No development needed at all.

An invoice by link. The site builds a payment link, the client moves to the app and pays. It suits one-off services, courses, prepayment for an order. Cheap and quick to launch.

A full integration. The payment system calls your server and asks: does this order exist, is the amount correct? With Payme that is Merchant API over JSON-RPC 2.0, with Click the Prepare and Complete methods of SHOP API. Your site has to answer both correctly, otherwise the payment fails or goes nowhere.

The rule is simple: if you have a cart, stock levels and order statuses, you need the full integration. If you sell one service at a fixed price, a link is enough and there is no reason to overpay for the API.

What do the connection steps look like?

The order is this:

Registration in the cabinet - Payme Business or the Click merchant cabinet.

Adding the business and the documents, signing the contract. With Click, access to the cabinet is granted by a manager once the application has been processed.

Receiving the integration credentials. These are the checkout or service identifiers and the secret key. The key is a secret: it lives on the server and never reaches the site code that opens in a browser.

The technical integration on the website side.

Test payments and acceptance.

I do not name approval timelines: they depend on how complete the documents are and on the type of activity, and there is no public norm here. The real timeline comes from the payment system's manager, not from a developer.

What has to exist on the website side?

Payment is not a button, it is server logic. The minimum you cannot launch without:

The order is created before payment and stored on the server with a status. The payment system will ask about it by identifier.

A callback handler answers the payment system's requests and changes the order status. This is the single source of truth about payment - redirecting the user to a "thank you" page confirms nothing.

Amounts in tiyin. The Click API passes amounts in tiyin, that is in hundredths of a sum. Confusion at this spot is the classic reason for discrepancies by a factor of a hundred.

Request signature verification. Otherwise a payment can be faked with an outside request.

A refund scenario - manual at the very least, but written down and tested.

HTTPS across the whole site.

An important consequence for the stack: the callback handler is server code. Pure static hosting does not have it, so you need either a server-side handler on the hosting or a separate function. That is exactly why the request form on my own site works through a server proxy rather than straight from the browser.

Payments can be taken in a Telegram bot too - for many tasks that is cheaper than a store: Telegram bot for business.

What about fiscalization and IKPU?

The part almost nobody warns you about in advance. Under clause 5 of decree ПП-5252 of 04.10.2021, payment organizations are obliged to show a fiscal mark on electronic receipts for remote payments for goods and services - the only exception is P2P and credit payments.

In practice that means two things for you:

Goods and services have to be matched to IKPU codes. Without correct codes the receipt is generated with an error.

The payment system has to be added as a commission agent in the my.soliq.uz cabinet. Payme describes this directly in its help: you add ИП ООО "INSPIRED" with tax ID (ИНН) 302050181, the contract number and dates. After that the receipts fiscalized by Payme are visible in the commission agents' receipts section and can be corrected.

This is the accounting part, not the programming part. As a developer I do not close it - your accountant does, together with the payment system's support. But you need to know about it before launch, not after the first payment.

How much does it cost to add payments to a website?

There are two different sums here, and they get mixed up.

The first is the payment system's commission on every payment. Neither Payme nor Click publishes the rate openly: it is fixed in the contract and depends on turnover and type of activity. Any site that quotes you an exact percentage is guessing. Ask the payment system's call center before you sign - it is one short call.

The second is the cost of the integration on my side. Payment by link is a small addition to a finished site. A full integration with callback handling and order statuses is already a complex project, and the price there is on request. For a reference point on the sites themselves: a landing page from $190, a multipage site from $490. What the price is made of: How much does a website cost in Tashkent.

If you want to work out which scenario is right for you, write to me through the form on the contact page - I will go through the task and tell you honestly if you do not need payments on the site yet.