How to Accept Payme and Click Payments in a Mobile App

The short answer

Accepting Payme and Click in a mobile app always has two halves:

• The client part — the app opens a payment page or a provider SDK screen where the user confirms the payment.
• The server part — Payme or Click calls your backend to check the order and report the result. Only this callback is the source of truth.

The app never decides whether an order is paid. It creates the order on your backend, launches the payment and then asks the backend for the status.

Three integration options

For most first releases web checkout is enough. Tokenization makes sense for delivery services, taxis and anything with frequent repeat purchases.

How the backend part works

Both providers send requests to your server, but the protocols differ:

• Payme uses the Merchant API over JSON-RPC: methods like CheckPerformTransaction, CreateTransaction, PerformTransaction, CancelTransaction. Amounts are passed in tiyin (sum × 100).
• Click uses the SHOP API with two steps — Prepare and Complete — and a signature you must verify on every request.

A minimal Payme checkout link is built from parameters encoded in base64:

const params = `m=${merchantId};ac.order_id=${orderId};a=${amountTiyin};c=${returnUrl}`;
const checkoutUrl = `https://checkout.paycom.uz/${Buffer.from(params).toString("base64")}`;

Rules that save you from most incidents:

• Validate every callback: authorization header for Payme, signature for Click. Reject anything that does not match.
• Check the amount and the order against your database, not against what the app sent.
• Make handlers idempotent: the same callback can arrive twice. Store the provider's transaction ID and return the saved result on repeats.
• Handle cancellations and refunds, not only successful payments.

Returning the user to the app

After payment the provider redirects to the URL you passed. Use a Universal Link on iOS and an App Link on Android so the redirect opens the app directly, with a custom URL scheme as a fallback.

Then the app should:

1. Show a "checking payment" state.
2. Poll your backend for the order status for a short time, or wait for a push.
3. Show success, failure or "still processing" with a way to check later.

Do not treat the redirect itself as proof of payment: users close tabs, lose connection or come back without a redirect at all.

Store policies

Apple and Google separate goods by type:

• Physical goods and real-world services (food, delivery, taxi, tickets, courses offline) may be paid with Payme, Click or any other external method.
• Digital content and features used inside the app (premium access, in-game currency, subscriptions to content) generally must go through In-App Purchase or Google Play Billing.

If your app sells digital goods through Payme or Click, expect a rejection during review. Read the payment sections of the App Review Guidelines and Google Play Payments policy before you design the flow.

Testing in sandbox

• Request test access from both providers: Payme has a test environment with test cards, Click provides test credentials through the merchant setup.
• Test the full cycle: create, pay, cancel, repeat callback, wrong amount, expired order.
• Log every incoming request and your response — it is the fastest way to resolve disputes later.
• Switch to production keys only through configuration, never by editing code before release.

Common mistakes

• Marking the order paid on the client after the redirect.
• Storing merchant keys inside the app binary.
• Mixing up sum and tiyin in Payme amounts.
• No handling for a payment that arrives after the order has expired.