Accepting payments in Uzbekistan: what a product team should expect

If your product needs to take money from users in Uzbekistan, the payment part will not look like the one you already know. Payments here run through local providers. Each has its own protocol, and each of them expects your server to answer their calls.

This page is a short map of that work, written for a product team planning market entry from outside the country. It is based on payment systems we have built in this market, not on a survey of the industry.

Three parts, and only two of them can be bought

Acquiring is a contract. A bank or a licensed payment institution moves money from the buyer's card to your account. You buy it.

A payment provider gives you a checkout page, a merchant dashboard, documentation and a protocol. You buy that as well.

The third part is code on your side that speaks the protocol — nobody sells it. It gets written, and it is the part that slips out of launch plans, because it does not appear on any pricing page.

Who may sign a merchant contract, and on what terms, is a question for the provider. Requirements differ between them and they change. Ask that first, then plan the engineering around the answer.

Local cards are the starting point, not an edge case

Uzcard and Humo are the card schemes most buyers here hold. In 2018 we built a service that let people pay for foreign online services with those cards, because the foreign side accepted international cards only and the purchase simply did not happen. That product exists because of the gap, and the gap is still there.

The practical reading for you is short. A payment stack that assumes an international card will reach a smaller audience than you planned, and the fix is an integration with local providers rather than a setting in your current gateway.

The provider calls your server, not the other way round

Teams usually picture the flow like this: the buyer clicks pay, the site calls the provider, the provider answers. The documentation describes the opposite.

Payme Business runs its Merchant API over JSON-RPC 2.0 on top of HTTPS. Requests arrive at your server by POST, and your server has to reply with HTTP status 200. Any other status is read as a protocol error.

The payment path is four methods. CheckPerformTransaction asks whether a transaction for this amount can exist at all. CreateTransaction creates it. PerformTransaction completes it. CancelTransaction cancels it. Next to them sit methods for checking state and for pulling a statement of merchant operations.

Click is shorter and shaped differently. The supplier's billing system implements Prepare and Complete, and after that the service becomes payable through every Click interface at once.

Two consequences follow, and both are architectural. Your server needs a public HTTPS endpoint that stays up. And your database has to answer the question "can this order be paid, for this amount, right now" before the provider's timeout expires.

What breaks

• Repeated calls. A provider may deliver the same confirmation twice when it does not receive your answer. A handler that ships the goods a second time passes manual testing without a complaint.
• Lost confirmations. The money left the card, the order stays unpaid, the buyer writes to support. The fix is a scheduled state check, not a retry button.
• Amounts. The amount arrives from outside. Compare it with your own before you trust it.
• Refunds. Cancellation is a separate protocol method and a separate branch in your logic. Returning the money is only the first half of it.
• Reconciliation. Payme includes a statement method for a reason. Differences between your ledger and the provider's appear in every integration, and the only question is who notices first.

We once audited the database of a working payment system where those differences had been growing for years: 212,191 significant operation rows in a single reconciliation, and partner statements assembled by hand.

What this looks like as a project

Timing depends on your side, not on the provider. If orders already exist as records with states, and a sandbox is available, one provider is a matter of days. If "paid" is not stored anywhere yet, order accounting comes first, and that is a larger piece of work with a different estimate.

Our record here is specific rather than general: a payment institution built for a Central Bank licence, a merchant platform that gives a shop 35+ different payment systems through one connection, and the reconciliation work described above.

If you are planning entry and want the engineering scope, start with payment system development. If the provider is already chosen and you only need the work on your side, start with API integrations.

Payments in Uzbekistan are not difficult, but they are specific, and the specifics sit on your side of the wire. Tell us what you want to charge for and which provider you are talking to. We will tell you what has to be built and how long it takes.