In the payment method you do not offer we argued that a missing payment method looks exactly like abandonment. This is the practical sequel for one market: if you sell in Uzbekistan, how do you actually get Click, Payme or Uzum working on your site — the paperwork, the money, the integration, and the mistakes that turn a working checkout into lost orders.
The short version first, because most people searching this want it:
- Paperwork comes before code. Every provider needs a legal entity or a sole proprietor, a bank account and a signed contract. The integration is a week of work; the paperwork can take longer.
- The "Pay" button is the easy part. The payment is only real when the provider's server calls your server and your server answers correctly. That callback is where every serious bug lives.
- Every payment gets a fiscal receipt, and your products need the tax catalog codes to produce one.
- Most stores end up with two providers, not one. Which two depends on your customers, not on which logo is newest.
What you need before any code
A legal entity or a sole proprietor
Click's own documentation defines the merchant as a legal person, and its Telegram payments guide says it plainly: to accept payments you must be registered as a legal entity or an individual entrepreneur and sign a payment-acceptance agreement with one of the banks connected to the system (Click docs). Uzum's partner page asks for the organization's TIN, settlement account and bank MFO, the state registration certificate, the manager's passport and — except for sole proprietors — the order appointing the manager (Uzum Bank Partners).
If you are selling as a private person with no registration, stop here and register first. No integration work helps until you can sign a contract.
The documents
Click's list is the most detailed published one: certificate of registration, a licence if your activity needs one, the director's appointment order and passport, the founders' minutes, the full charter — and a domain agreement (Click docs). That last one matters more than it looks: the provider wants to see that the site belongs to your business. If your developer registered the domain in their own name, fix that now; we explain how in who owns your website.
Product codes for the fiscal receipt
Every product or service you sell needs its IKPU (MXIK) code and a package code from the national product catalog at tasnif.soliq.uz. Uzum's Checkout documentation calls fiscalization "a mandatory process imposed by legislation" and walks you through finding both codes in that catalog (Uzum Checkout). Click's fiscal API marks the IKPU code, the package code, the VAT amount and the VAT percentage as required fields for each item (Click fiscalization).
Do this with your accountant before the developer starts. A catalog of two hundred products without codes is a data-entry project nobody scheduled.
What it costs: the commission question
Here we have to be honest about what we could and could not verify.
Click states there is no connection fee and no subscription fee; you pay the bank a service fee as a percentage of the turnover that goes through Click (Click docs). The percentage itself is set in your bank contract and is not published.
Uzum connects partners for free and publishes one number: 0% for payments by Uzum card and 0.4% for other banks' cards — but that figure is for Uzum to'lov, its QR-based payment method. For online acquiring through the API it says only that the cost "depends on the type of acquiring chosen" (Uzum Bank Partners).
Payme does not publish an online acquiring rate on the pages we could reach in September 2026.
So we are not going to print a "typical commission" we cannot source. What we recommend instead: get the rate in writing from each provider for your turnover and category, and ask three more questions with it — how quickly the money reaches your account (Uzum advertises daily withdrawal to your settlement account), whether refunds cost anything, and whether the rate changes as volume grows.
How the integration actually works
The customer sees a redirect; your server sees a conversation
On the surface all three look alike: the customer clicks a button, lands on the provider's payment page, pays with Uzcard or Humo, and comes back. Click's simplest option is literally a link to my.click.uz/services/pay with your service ID, the amount and an order number (Click payment button); Payme has an equivalent checkout form.
The return to your site proves nothing. Anyone can open your "thank you" URL. The order is paid only when the provider tells your server so, and each provider has its own protocol for that conversation:
- Click (Shop API) sends two requests to your server. Prepare asks whether the order exists, whether the amount is right and whether you can still supply it; Click's own documentation tells online stores to reserve the product at this stage to prevent resale. Complete tells you the money was taken. Both are signed with an MD5 string built from the transaction data and your secret key, and you must verify that signature (Click Shop API).
- Payme (Merchant API) is JSON-RPC:
CheckPerformTransaction,CreateTransaction,PerformTransaction,CancelTransaction,CheckTransactionandGetStatement, authenticated with HTTP Basic. The docs require you to reserve the order until payment or timeout, block the customer from changing it, and they cancel an unpaid transaction after 12 hours — 43,200,000 milliseconds (Payme CreateTransaction). - Uzum has two products. Checkout is the gateway for websites: you register the payment, send the customer to Uzum's form, and Uzum sends you a callback when it completes; it takes Visa and Mastercard as well as Uzcard and Humo (Uzum Checkout). The Merchant API is for customers paying you from inside the Uzum Bank app: webhooks for
/check,/create,/confirm,/reverseand/status, where a transaction not confirmed within 30 minutes is treated as failed and/statusis retried up to 10 times if your server errors (Uzum Merchant API).
Fiscal receipts
Since the tax committee's requirement took full effect in late 2022, payment services issue the fiscal receipt as intermediaries between buyer and seller (Gazeta.uz). Payme began issuing electronic fiscal receipts for all payments on 24 December 2022 and asked merchants for the IKPU code, VAT rate and receipt type of what they sell (Payme blog).
In practice that means your integration sends item-level data: Payme accepts a detail object with the items in its response to CheckPerformTransaction (Payme docs), Click has a separate call to submit items after payment (Click fiscalization), and Uzum Checkout can fiscalize one-step payments automatically once your manager enables it. Store the receipt link you get back — a customer asking for a receipt next spring should not need a support ticket.
Test mode
All three let you test before a single real so'm moves. Payme's sandbox at test.paycom.uz runs two scenarios in sequence — unconfirmed transactions with security checks, then confirmed ones with cancellation — and recommends testing live payment initialization only after the sandbox passes (Payme sandbox). Click's documentation includes a sandbox that fires Prepare and Complete at your server from the browser. Uzum Checkout publishes Humo and Uzcard test cards with a fixed 3-D Secure code.
Side by side
| Click | Payme | Uzum | |
|---|---|---|---|
| Website integration | Payment link or form + Shop API callbacks | Checkout form + Merchant API (JSON-RPC) | Checkout API (register → form → callback) |
| Paying from the provider's app | Yes, same Shop API | Yes, same Merchant API | Merchant API webhooks |
| Amount unit your server receives | So'm (fiscal API uses tiyin) | Tiyin | Tiyin |
| How requests are authenticated | MD5 signature with secret key | HTTP Basic | Basic (Merchant API), API key (Checkout) |
| Timeouts to design for | Reserve at Prepare | Unpaid transaction cancelled after 12 h | Unconfirmed after 30 min = failed |
| Cards | Uzcard, Humo | Uzcard, Humo | Uzcard, Humo, Visa, Mastercard (Checkout) |
| Telegram bot payments | Yes, via BotFather | Yes, via BotFather | Not covered in the docs we read |
| Test environment | Browser sandbox | test.paycom.uz | Test cards |
| Published fee | No connection or subscription fee; % set by bank | Not published | Free connection; online rate not published |
Paynet and direct card acquiring through your own bank exist too. We left them out of the table because we could not find public merchant integration documentation to verify against.
Telegram bots take the same providers
If your storefront is a bot rather than a site — the case we made in Telegram is a storefront — you connect Click or Payme through BotFather's Payments menu, test first with the provider's test connection, then switch to live with your merchant login. Your bot sends an invoice with sendInvoice and must answer the pre-checkout query within 10 seconds or the transaction is cancelled (Telegram). Digital goods are a separate case in Telegram's rules and go through Telegram Stars. We price the full picture in how much a Telegram bot costs.
The mistakes that cost the most
- Marking an order paid on the return URL. The only source of truth is the signed server callback. Treat the return page as a "we are checking" screen.
- Mixing so'm and tiyin. Click's Shop API sends so'm; Payme and Uzum send tiyin; Click's own fiscal API wants tiyin. Store money as integers in the smallest unit and convert at the edge — the rule from what multi-currency actually means, applied to one currency.
- Not reserving stock. Both Click and Payme tell you to hold the order between check and payment. Without it, two customers can pay for the last item.
- Handlers that are not idempotent. Providers retry. Uzum retries
/statusup to ten times; Click has a dedicated "already paid" error. The same request arriving twice must not ship twice. - Answering an error after the money is taken. Click is explicit: once Prepare succeeded and the card was charged, your response to Complete must not be an error; if you cannot deliver, answer success and start a reversal. Returning an error sends the payment to manual investigation.
- Fiscal data as an afterthought. Missing IKPU or package codes surface at launch, not in testing, unless you test with the real catalog.
- Accounts in the wrong name. The merchant contract, the domain and the dashboard logins belong to the business, and the live keys belong in server configuration — never in the repository.
What this costs to build with us
Our e-commerce builds start at $499 and run one to five weeks, and the store plan on our pricing page includes a payment gateway, inventory and orders, discounts and delivery setup, with six months of support. Telegram bots with payments start at $199. Payme and Click are both in our stack.
The honest scoping note from our earlier article still applies: one provider is part of a standard store build; a second provider is scoped and priced before we build it, so you decide with the number in front of you. The paperwork and the merchant contract stay yours — we prepare the technical side and the product-code list, but the contract is between your business and the bank.
Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.
Frequently asked questions
Can I accept Click or Payme as a private person?
Not according to the providers' own documents. Click requires a legal entity or an individual entrepreneur with a bank contract, and Uzum asks for organization details and a state registration certificate. Register first; it is the longest step and it does not depend on your developer.
Which provider should I connect first?
The one your customers already pay with. If you have no data, start with one of Click or Payme — both are widely used for Uzcard and Humo — and capture failed checkouts as leads, as described in the payment method you do not offer. After a month you will know which second method is costing you sales.
How long does connection take?
None of the three providers publishes a timeline. Plan the paperwork, the provider's review and the sandbox tests as a separate track that starts on day one, in parallel with building the store.
Can I accept cards issued abroad?
Uzum Checkout lists Visa and Mastercard among supported systems. Whether a specific foreign-issued card goes through depends on your contract and the issuing bank, so ask the provider directly and test with a real foreign card before you promise it on the site.
Does Tilda or another builder support these providers?
Tilda has a built-in Click connector for catalog products, and it asks for the IKPU and package code on every product (Tilda help). We did not find a built-in Payme connector in Tilda's help centre. If you need both, or need custom logic around orders, that is where a builder stops and a custom checkout starts.
