The payment layer of a web platform is not a pay button but a record of who pays for what and on which plan: invoices and their statuses, subscriptions, refunds and reconciliation with the provider. For an Uzbek audience it connects to Payme, CLICK and Uzum Bank, while the card data stays on the provider's side.
Key takeaways
A pay button charges the money once and stops there. Billing remembers what was paid for, on which plan, how much of it has already been used and when the next charge is due.
The difference shows up as soon as payment stops being a one-off: the platform gains plans with limits, renewals, prorated plan changes and refunds. All of it has to be counted in one place, otherwise the numbers in the product, at the provider and in accounting drift apart.
If payments are also needed inside Telegram, they follow different rules — see payments in a Telegram bot and automatic notifications.
The layer is assembled from five parts, each responsible for its own stretch of the money's journey. The split matters not for architectural elegance: it is what lets you add a new provider without rewriting the product.
Tip Build in support for several providers from day one, even if you launch with a single one. Rewriting the payment module for a second system always costs more than separating the generic invoice logic from provider specifics up front.
All three are connected the same way: a provider contract, a test environment, an implementation of the protocol on the platform's side and a switch to live keys. The differences lie in who calls whom and which methods you have to implement.
| Provider | How the integration works | What else is available | Documentation |
|---|---|---|---|
| Payme | Merchant API: the provider calls the platform's billing with methods to check, create, perform and cancel a transaction | Subscribe API for saving a card, payment page initialisation, Telegram bot connection | developer.help.paycom.uz |
| CLICK | SHOP API: the platform implements the Prepare and Complete requests, after which the service becomes available across CLICK interfaces | Merchant API, CLICK Pass, payment links and card payments | docs.click.uz |
| Uzum Bank | API integration of payment methods for a website, an app and a Telegram bot | QR payments at the point of sale: static and dynamic QR, FastPay | merchants.uzumbank.uz |
The key trait of Payme and CLICK is that the initiative sits with the provider: it calls your server and asks whether such an order exists and whether a payment can be made against it. That means your billing has to be reachable from outside, answer fast and answer identically to repeated requests.
Support for local systems is not required by law, but without it a platform loses most of its paying audience: people pay with the app already installed on their phone. Uzcard and Humo cards are served through local gateways, and an international provider is added for payments from abroad.
A subscription differs from a one-off sale in that it has to be managed over time rather than simply charged. Most losses in subscription products come not from customers leaving but from technical breaks in that cycle.
Recurring card charges are not always possible: they depend on whether the provider supports saving a card and issuing a token, and on the contract terms. Without that option, a subscription runs on invoices and reminders — almost the same for the customer, but a different notification logic underneath.
The paths where something goes wrong deserve to be designed alongside the happy path, not after launch. This is exactly where a platform either keeps a customer or loses both the money and the trust.
Every scenario needs clear wording for the customer and a log entry for support. Otherwise resolving one disputed payment costs the business more time than the payment is worth.
Card data is stored and processed by the payment provider. The platform receives only the transaction status and the charge identifier — enough to find the operation, issue a refund and reconcile the books.
PCI DSS is a standard of the international card schemes, and it governs work with Visa, Mastercard and other council members. Uzcard and Humo cards are served by local gateways under their own rules, so their requirements are clarified with the provider and the acquiring bank. When the card entry form sits entirely with the provider, a merchant usually needs only a simplified self-assessment: the SAQ A questionnaire is designed exactly for those who do not store, process or transmit card data themselves.
The exact set of requirements is defined by the acquiring bank or the card scheme, so it is fixed in the contract before development starts rather than after the first audit.
Reconciliation exists so that discrepancies surface automatically rather than at the end of a quarter. Money travels through several systems, and in each of them an operation can be left in its own status.
Example A customer paid, the provider processed the charge, but the callback never reached the platform because of a network failure. The provider's report shows the operation, the platform still shows the invoice as unpaid, and accounting sees money with no basis. Daily reconciliation finds that operation the next day rather than three months later.
The minimum working order looks like this: the platform regularly requests the list of operations for a period from the provider, matches them against its own invoices by identifier and shows the discrepancies as a separate list. Payme offers a method that returns information about the merchant's transactions; other providers have their own exports.
From there the data goes to the accounting system: amounts, dates, purposes and refunds. How to tie those figures to sellers and settlements is covered in marketplace development, where payouts add one more layer to the payment loop.
There is no separate price tag for billing: it is counted as part of the platform or of an integration project. Connecting systems that already run in the company starts at $4,000, a dedicated module for one job at $8,000.
The scope and prices are listed on the ERP and integrations service page. The provider's commission is not part of that sum: the company pays it separately under its own contract. If the payment layer is for an online shop, see the walkthrough in launching an online store.
Syntra Systems starts with the sales model: what exactly is bought, how often, what happens on cancellation and which employees work with the money. That produces the scheme of invoices and statuses, and only then are the providers chosen.
Next we build the layer with room for a second provider, test it in a sandbox across every scenario — successful, cancelled, repeated and refunded — and switch reconciliation on before launch rather than after the first lost payment. The customer's payment history goes into their customer account, so support does not have to read out statements by hand.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
You can, but the module is worth building for several providers from the start: shared invoice logic on its own, with Payme, CLICK or Uzum Bank specifics in separate adapters. That way a second system connects without a rewrite, whereas without it the platform loses people used to paying through a different app.
PCI DSS is a set of rules for protecting card data from Visa, Mastercard and other international schemes. Uzcard and Humo run through local gateways under their own rules, so those requirements are confirmed with the payment provider and the acquiring bank. If the card is entered on the provider's own page, international cards usually only need the simplified SAQ A self-assessment.
Set up scheduled retries and a message asking the customer to update the payment method. Access is restricted gradually so that the customer can come back without losing data. A full cut-off makes sense only after several failed attempts and warnings.
On the provider's page the card is entered by the provider, and the platform never touches that data. A form on the site feels more seamless but shifts noticeably more security obligations onto the company. For most projects the gain in convenience is not worth it.
Local systems work with Uzbek cards, so for customers abroad an international provider is connected as one more adapter. The invoice currency, taxes and refund rules are then defined separately from the local payment loop.
A partial refund is issued when part of an order is cancelled: the sum is recalculated and the remainder stays paid. The provider processes the refund itself under its own rules, while the platform updates the invoice status and includes the refund in the accounting export — otherwise reconciliation stops matching.
The history lives in the platform's own database: amounts, dates, statuses and the provider's transaction identifiers. Access to financial sections is restricted by role, and employee actions are written to a log. The customer sees their own part of it in the customer account.
