Acquiring and Processing: How Payments Really Work Under the Hood

For the customer, a payment is one button and a couple of seconds of waiting. For a business, behind that button sits a chain of several independent players, each taking a slice of the fee and carrying a slice of the risk. If you are launching an online service, a marketplace, or simply enabling card acceptance, understanding this mechanics directly affects your unit economics and how much money you actually keep from every transaction.

In this article we break the payment chain into layers: who is responsible for what, how a transaction moves, what fees are made of, and where money and nerves are most often lost — grounded in the realities of Uzbekistan, where local schemes Uzcard and HUMO operate and online acceptance rests on providers like Payme, Click and Uzum.

The players: who is who

To avoid confusion, let us fix the roles. In the classic card scheme there are five, and in Uzbekistan they are broadly the same, though local specifics add nuance.

• Cardholder — your customer, the one who pays.
• Issuer — the bank that issued the customer's card. It debits the funds and carries the main risk on held amounts.
• Acquirer — the bank or organization that accepts the payment on behalf of the merchant and credits the revenue.
• Processor (processing center) — the technical link that routes, authorizes and settles transactions. In Uzbekistan the processing centers of the Uzcard and HUMO schemes play a key role.
• Payment organization / PSP — Payme, Click, Uzum and the like. They give the merchant a ready integration (payment page, API, QR), hiding acquiring and processing beneath the surface.

It matters to distinguish acquiring (the financial function — who accepts and credits the money) from processing (the technical function — who routes and reconciles transactions). One company may combine both roles, but they are different layers of responsibility.

The transaction flow: what happens in those seconds

Take a typical online card payment. Simplified, it goes through several stages.

• Initiation. The customer enters card details or confirms the payment in their bank app. The PSP forms an authorization request.
• Authorization. The request travels through the processor to the issuer. The issuer checks balance, limits and card status, then decides: approve or decline. Funds on the cardholder's account are held, not yet debited.
• Capture. The merchant confirms the service was rendered or goods shipped. Only then does the hold turn into an actual debit.
• Clearing and settlement. At the end of the settlement period the acquirer gathers confirmed transactions, settles with issuers through the scheme, and credits revenue to the merchant — net of fees.

What fees are made of

The fee a merchant sees is not one number but the sum of several components. In the international model there are three: interchange (to the issuer), the scheme fee, and the acquirer/PSP margin. In Uzbek retail the merchant usually sees a final rate from the provider, but understanding the structure is still useful — it explains why the rate can never drop to zero.

• Issuer fee — the most "protected" part; it compensates the bank for risk and card servicing.
• Scheme fee — for routing and settlement.
• Acquirer/PSP margin — what your provider adds for integration, support, fraud monitoring and payouts.

Beyond the percentage of turnover, calculate total cost of ownership: payout timing (T+1, T+2 or longer), withdrawal fees, minimum payout threshold, refund and chargeback costs, integration and support pricing. Sometimes a lower turnover percentage is offset by a long payout cycle that freezes your working capital.

Risks and where money gets lost

The payment chain is long, and a failure can occur at any junction. The most common sources of trouble:

• Stuck holds. If authorization passed but capture was never called (a bug, a crashed worker), the customer's money is blocked while you have "no order". A classic source of complaints.
• Status drift. Your database treats a payment as successful while the provider has it as failed — or vice versa. Without reliable reconciliation you either ship the unpaid or hold a paid order.
• Refunds and chargebacks. A refund costs money and time; a cardholder disputing a transaction is a separate process with its own deadlines.
• Fraud. Stolen card data, small test debits, brute-forcing. Here 3-D Secure, limits and fraud monitoring come into play.
• Data security. Storing card data falls under the PCI DSS standard. For most businesses it is wiser not to store the PAN yourself but to use tokenization and the provider's payment page.

Key terms in one list

• Authorization — checking and holding funds without an actual debit.
• Capture — turning a hold into a real transaction.
• Settlement / clearing — mutual settlement and crediting revenue to the merchant.
• Interchange — the interbank fee paid to the issuer.
• Chargeback — a forced refund initiated by the cardholder through their bank.
• 3-D Secure — cardholder confirmation (code/biometrics) to reduce fraud.
• Tokenization — replacing the card number with a safe token so you never store the PAN.
• Reconciliation — matching your records against the provider's data.