Accepting Online Payments in Uzbekistan: Connecting Click, Payme and Uzum to Your Website or App

Every business that sells online in Uzbekistan reaches the same question sooner or later: how do we accept online payments on our own website or app? The short answer is to connect a payment provider that acts as your payment gateway, such as Payme Business, Click or Uzum Checkout. The longer answer involves a merchant agreement, server code, fiscal receipts and refunds, and that is where projects slip. This guide covers Payme, Click and Uzum Checkout integration from the business side: what to prepare, how the payment flow works, refunds and receipts, how the providers differ and what to test before going live, based on each provider's documentation at the time of writing. Fees are left aside: check the current terms with the provider and your bank before you sign.

How online payments work in Uzbekistan

A business does not connect to card processing directly. It signs an agreement with a payment provider, which handles the card details, the authorisation and the payment page. Your site or app sends the customer to that page or to the provider's app, the customer pays, and the money settles to your company's settlement account. With the provider's payment page, your server never handles card numbers.

The providers' own documentation lists different cards:

• Payme Business: UZCARD Online and HUMO cards of any bank, and Payme CARD.
• Click: Uzcard and Humo, the two card types its payment button can be limited to.
• Uzum Checkout: Visa, Mastercard, Uzcard and Humo.

Of the three, only Uzum Checkout's documentation lists Visa and Mastercard. If you expect cards issued abroad, confirm with the provider that they will be accepted.

What you need before integration

Most delays happen before any code is written, so work through this list in the first week:

• A legal entity or individual entrepreneur. Click, for example, requires one of the two. Payme Business says that, under current law, payments must reach the organisation's settlement account, and the tax authority has said the same: not a personal card.
• A settlement account at a bank, in the business's name.
• A merchant agreement. For Click, a payment-acceptance agreement with one of the banks connected to Click. For Payme Business, in person or online, with the electronic contract signed through Didox using an electronic digital signature. For Uzum Checkout, through Uzum Bank, which issues your terminal ID and API key.
• The provider's document set. Click's list includes the registration certificate, the charter, the director's appointment, a licence where your activity requires one and the domain agreement. Ask each provider for its current list.
• A live site with your terms: public offer, delivery and refund terms, and contact details, on the domain you are connecting.
• IKPU, package code and VAT rate for every product, agreed with your accountant.
• Credentials registered to your company. Merchant cabinet logins, secret keys and API keys belong to the company; a developer gets access that the company can revoke.

How Payme, Click and Uzum integration works, step by step

1. The order is created on your side, with a fixed amount and the status "awaiting payment".
2. The customer is sent to the provider. For Click, a payment link to my.click.uz carrying your merchant and service IDs, the order number, the amount and an optional return URL. For Payme, a payment form that your site builds and sends to Payme's checkout. For Uzum, you register the payment through the Checkout API and receive the URL of a payment page.
3. The provider and your server exchange messages. Payme and Click call you. Payme's Merchant API sends JSON-RPC 2.0 requests such as CheckPerformTransaction, CreateTransaction and PerformTransaction. Click's SHOP API sends Prepare and Complete requests, each signed with an MD5 signature built with your secret key. With Uzum, you make the calls, registering the payment and checking its status, and Uzum sends a callback when the payment completes, repeating it if your server does not confirm receipt.
4. Your server checks everything: the signature or authorisation, that the order exists and can still be paid, and that the amount matches exactly.
5. The order status changes only after those checks pass.
6. The customer returns to your site or app, which shows the status from your own database.

Two rules hold for every provider. First, never treat the browser redirect as proof of payment: a customer can close the tab, lose signal or open the success URL by hand. Only a verified server-side notification counts. Second, handle repeated notifications idempotently. The same notification can arrive more than once, for example when your server answers late, and it must never confirm an order twice, ship it twice or create two receipts.

Order statuses, timeouts and refunds

While a payment is pending, reserve the goods and lock the order. Payme's documentation says it cancels an unpaid transaction 12 hours after creation, and asks merchants to keep the order reserved and unchanged until payment or timeout. Click asks online stores to reserve goods at the Prepare step. Both are rules of the current documentation, so check them again when you build.

Map each provider's states to a small set of your own: awaiting payment, paid, cancelled, refunded and partially refunded. Uzum's one-step payment, for example, uses REGISTERED, COMPLETED, DECLINED and REFUNDED. Order logic should know only your statuses; the translation lives in one place per provider.

Refunds work differently with each provider:

• Payme Business: refunds are made from the merchant cabinet, and only if your server implements CancelTransaction, which cancels both created and completed transactions.
• Click: payments are reversed through the Merchant API. Under the currently documented conditions, a reversal needs a successful payment made with an online card in the current reporting month (a previous month's payment only on the first day of the current one), and UZCARD may reject it.
• Uzum Checkout: full and partial refunds through the API.

If an order cannot be fulfilled after the money has been taken, refund through the provider rather than by a separate bank transfer, so that the payment, the refund and the receipts reconcile. Click's documentation covers this case directly: answer Complete as successful, then cancel the payment through the reversal method. And reconcile daily: compare the provider's payment report with your orders, and investigate every payment without an order and every paid order without a payment.

Fiscal receipts and IKPU codes

Taking payment through Click or Payme does not remove the duty to issue a receipt; that has been the tax authority's published position. Under current fiscal rules, each receipt must carry the product's 17-digit IKPU code, which you look up on tasnif.soliq.uz. Each provider's API can carry the item data a receipt needs:

• Payme Business: in the CheckPerformTransaction response, your server can return a detail object listing each item's title, price in tiyin, quantity, IKPU code, package code and VAT percent. After a payment or cancellation, Payme calls SetFiscalData with the receipt data from the fiscal data operator, including a QR-code link to the receipt.
• Click: its fiscalisation API takes the items of a payment, with name, IKPU, package code, price, quantity, VAT amount and VAT percent, plus commission details with a TIN or PINFL. If you fiscalised the receipt elsewhere, you can submit its QR link instead.
• Uzum Checkout: auto-fiscalisation for one-step payments, off by default and switched on through your Uzum Bank manager. It needs the cart with IKPU, package code and VAT rate. Without it, you send receipt data yourself, for example through Uzum's separate fiscalisation API.

Decide with your accountant who issues receipts: the provider, or your own virtual cash register, through which e-commerce businesses can send receipt data to the fiscal data operator. Agree on refund receipts at the same time: Payme passes receipt data after cancellations too, and with auto-fiscalisation switched on, Uzum fiscalises the return receipt. Either route changes who transmits the data, not whether your fiscal obligations apply. Store the receipt link against the order so that support and accounting can find it.

Choosing a payment gateway: one provider or several

Offer the providers your customers actually use, not every provider available. Build one internal payment layer, with your own statuses and one adapter per provider, so that adding a provider later does not touch checkout logic. Every extra provider also adds reconciliation work: another report, another cabinet, another set of refund rules. If you sell through a bot, our guide to a Telegram bot for business covers bot payments.

Testing before go-live

When you add a web cash register, Payme Business issues two keys: one for the cabinet and a TEST_KEY for its sandbox at test.paycom.uz, where you run Payme's test scenarios against your server. Uzum provides a test environment with test cards. Click's documentation includes a playground and a Postman collection that send signed Prepare and Complete requests to your endpoints; since no real money moves there, finish with a small, controlled live payment and reverse it.

Run these scenarios with every provider you connect:

• a successful payment;
• a wrong amount;
• an unknown order, or one already paid;
• a duplicate notification for the same transaction;
• an expired or timed-out transaction;
• a cancellation after payment;
• a partial refund, where the provider supports it;
• a receipt created and linked to the order;
• your server unavailable during a callback, then back online;
• the return flow on a phone, including coming back from the provider's app.

Common mistakes

• Trusting the success page instead of the provider's confirmation.
• Not checking signatures, so anyone who finds your callback URL can mark orders paid.
• Secret keys in frontend or mobile app code. Anything shipped to a browser or phone can be extracted, and Click's documentation makes the supplier responsible for keeping its secret key safe.
• Mixing up amount units. Payme and Uzum work in tiyin, Click's SHOP API sends so'm and Click's fiscalisation API takes tiyin. A factor of 100 is the classic bug.
• Not reserving stock, so two customers pay for the last item.
• Orders editable after payment starts, so the basket no longer matches the transaction.
• Missing or wrong IKPU codes, found only when receipts fail.
• Merchant credentials on a freelancer's account, which ties your revenue to one person's login.
• No daily reconciliation, so a lost callback is found weeks later by a customer.
• Payments never reaching accounting. If finance retypes payments into 1C by hand, see our guide to 1C integration with a website and CRM.

How BITS can help

Integration with local and international payment providers is part of our web development work and of the mobile apps we build. Your company signs the merchant agreement and holds the credentials. Provider onboarding runs on the provider's schedule, so apply early. We verify payment notifications on the server and reconcile them with orders rather than trusting the browser. Passing payments on to 1C is separate system integration work.

If you are still choosing who will build the rest, our guides to choosing a web development company and building a mobile application may help, and everything we do is on our solutions page. We send a quote after a discovery call: contact us and tell us what you sell and which providers you plan to use.