# Payment Providers in Ukraine: Align Charging with Order Fulfilment

When comparing payment providers in Ukraine, ask when your business knows the final amount of an order. A retailer that confirms stock after checkout has a different requirement from a service that can charge the agreed price immediately. Both may accept cards in UAH, yet need different payment operations. The useful distinction is between reserving funds, collecting them and returning a completed payment. Public Ukrainian acquiring documentation makes those choices visible. A shortlist should explain how they fit your fulfilment process, alongside a separate assessment of UAH payouts.

## A numerical starting point for the provider comparison

We reviewed **16 unique historical payment offers** linked only to this country: 8 collection offers and 8 payout offers. They provide a structured starting point for comparing payment costs, access to funds and operational requirements. 109 additional offers linked to several countries are excluded from the country-only calculations below.

The source is the PayStar export dated 14 September 2026, supplied by payment gateways. We recomputed its aggregates, but did not independently verify its commercial statements. This is a historical sample, not a market survey, a count of PSPs or methods, or proof of active connections and current availability. Conditions can change weekly or more often. Independent country, currency and method associations do not establish every possible payment route. Direction counts and settlement-label charts cover all recorded currencies. Only the percentage comparison below is restricted to explicit UAH fee records.

16 unique offers linked only to this GEO, across all recorded currencies; not methods, providers or live connections. [Download SVG](https://paystar.uk/ukraine-payment-solutions/media/2026-10-08-v2/charts/offers-en-desktop-download.svg)

## What the recorded UAH percentage components show

We calculate the arithmetic mean of explicit percentage components stated in UAH, giving each comparable offer equal weight. A record qualifies only when its structured percentage matches one unambiguous percentage in the original fee description. Offers in another fee currency, missing percentages and ambiguous descriptions are excluded.

We also exclude bound or conditional percentages such as “from”, tiers and explicitly restricted customer categories. Exact nominal percentage components with fixed minimums or caps can remain in the sample; those minimums and caps still affect the final charge.

| Direction | n | Mean | Median | Range |
| --- | --- | --- | --- | --- |
| Collections | 7 | 8.86% | 8% | 7–12% |
| Payouts | 8 | 2.94% | 3% | 1–4% |

Explicit UAH percentage components only. n is the comparable sample in each direction; missing fees are excluded, not zero. [Download SVG](https://paystar.uk/ukraine-payment-solutions/media/2026-10-08-v2/charts/fees-en-desktop-download.svg)

**These are percentage components, not all-in payment prices.** Fixed charges, FX, tax, reserves, minimums and charges for refunds or other exceptions must be assessed separately. This sample is not weighted by payment volume, contains no measured conversion rate and cannot rank provider quality. Small or insufficiently independent groups are withheld.

### A hypothetical payment calculation

Take an illustrative payment of 1,000 UAH; this is not a typical market ticket. Applying the rounded means shown above gives:

- Collections: 1,000 UAH × 8.86% = **88.6 UAH**.
- Payouts: 1,000 UAH × 2.94% = **29.4 UAH**.

Each line is a separate direction, not a combined service quote. The arithmetic shows only the percentage part. Ask for an actual quote at your ticket size, volume, business model and settlement currency before calculating net proceeds.

## When money becomes usable matters

Collection offers across all recorded currencies. T/D labels are recorded as supplied, without assuming calendar or business days. Other includes complex labels and pooled groups below 3 records. No guaranteed settlement time. [Download SVG](https://paystar.uk/ukraine-payment-solutions/media/2026-10-08-v2/charts/timing-en-desktop-download.svg)

A successful payment notification and money available to your business are different events. Treat recorded settlement labels as questions for a provider: what starts the clock, which cut-off applies, are weekends counted, which account is credited, and can a reserve or review delay availability?

For payouts, agree prefunding, beneficiary validation, rejection handling and how returned funds appear in your balance. An incoming-payment settlement label does not prove payout completion time.

### A cash-buffer planning example

If a business must fund 100,000 UAH of obligations per day, a one-day gap requires 100,000 UAH; a three-day gap requires 300,000 UAH. The additional buffer is 200,000 UAH. This is a hypothetical constant-flow model, excluding fees, reserves and volatility, not an observed settlement promise.

## Choose when the customer is charged

Monobank's invoice documentation distinguishes an ordinary debit from a hold that reserves funds for later finalisation. It also documents payment by card, its banking app and supported wallets. Those checkout choices do not, by themselves, answer when your order should be charged. [Monobank: creating an invoice](https://monobank.ua/api-docs/acquiring/methods/ia/post--api--merchant--invoice--create).

Start with the event that fixes your price: stock confirmation, completion of a booking check or agreement on the final basket. Then ask each candidate whether its merchant product supports the necessary hold and capture operations for your company and transaction type.

Build the deadline into the operating procedure. A warehouse delay must not silently turn into an overdue capture attempt. Confirm the applicable authorisation period, the latest safe capture time, what happens at expiry and who receives an alert. A checkout that offers a hold is useful only if your team can complete the next step reliably.

## A smaller final basket needs a different operation

LiqPay's two-step payment documentation describes collecting all or part of a reserved amount. After a partial collection, the reservation on the remainder is cancelled automatically. Its documentation also distinguishes the period for which funds remain blocked from a longer technical completion window; those are not interchangeable planning deadlines. [LiqPay: two-step payment](https://www.liqpay.ua/en/doc/api/internet_acquiring/two_step?tab=2).

Monobank documents a separate operation for finalising a hold, with the amount to collect and item data for fiscalisation when the finalised amount differs from the original. [Monobank: finalising a hold](https://monobank.ua/api-docs/acquiring/methods/ia/post--api--merchant--invoice--finalize).

For a merchant, the comparison is concrete:

| Order situation | Operation to discuss with the provider | Evidence your team should retain |
| --- | --- | --- |
| Price and availability confirmed at checkout | Immediate collection | Confirmed payment linked to the final order |
| Stock or final basket still being checked | Hold, followed by collection of the agreed amount | Reserved amount, deadline and final collected amount |
| Customer returns goods after collection | Refund against the original payment | Refund amount, status and original payment reference |

These are questions for qualification, not a statement that every candidate supports every row. Monobank and LiqPay are cited as public documentation examples, without implying a PayStar partnership or identifying suppliers in our private records.

## A worked example: UAH 2,400 becomes UAH 1,900

Consider a hypothetical retailer whose customer orders three items totalling UAH 2,400. Before dispatch, the retailer finds that one UAH 500 item is unavailable, and the customer agrees to the smaller basket.

If the payment is still held and the agreed product supports partial collection, the intended outcome is to collect UAH 1,900 and release the remaining UAH 500 reservation. If UAH 2,400 has already been collected, the intended outcome instead requires a UAH 500 refund. The arithmetic is identical; the customer's bank record and the merchant's work are different.

Use both cases in acceptance testing. Check that customer support can explain a released reservation without calling it a completed refund, and that the order record contains the final basket. Add a cancelled order before capture and a return after dispatch. This is an illustrative test plan, not a client result or a promise of availability.

## Check how refunds are funded

Monobank's cancellation documentation addresses an already successful payment. That is a separate workflow from finalising a hold. [Monobank: cancelling a payment](https://monobank.ua/api-docs/acquiring/methods/ia/post--api--merchant--invoice--cancel).

LiqPay's refund guide describes funding a refund from future incoming payments or from the company's eligible payment-acceptance account at PrivatBank, when configured and sufficiently funded. This makes refund funding a useful shortlist question, especially for a merchant whose sales are irregular. [LiqPay: refunds](https://www.liqpay.ua/en/doc/api/internet_acquiring/refund?tab=0).

Ask which balance funds refunds, whether account funding needs separate activation, and what evidence support receives while a request is pending. Compare the provider's processing step with the customer's eventual receipt of funds. Do not turn a submitted request into a promise that the customer already has the money.

## Assess UAH payouts separately

A refund of a purchase does not establish a general business payout capability. Define your payout purpose, recipient type, destination account, funding source and expected amounts separately from card acceptance.

Likewise, collecting UAH does not establish a settlement currency, settlement schedule or permission to transfer funds abroad. Obtain current confirmation for your company's registration, activity and complete funds flow. Any foreign-exchange, cross-border or restricted-party questions need review for the actual parties and jurisdictions before a route is proposed. This article makes no eligibility or regulatory-clearance determination.

## The role of PayStar

PayStar provides information for comparing payment solutions and, where agreed, a technical layer for connecting and operating them. PayStar is not a bank or payment service provider and does not accept, hold or settle customer or business funds in its own name.

You select the payment provider and enter into a direct agreement with it. The provider processes payments and performs settlement under that agreement. Local eligibility, required authorisations and commercial terms must be confirmed for your company and use case. A method described in this article is not a promise that it is available through PayStar for your business.

Information about payment options is free. Payment processing and any agreed technical services have separate commercial terms.

## Official sources and research scope

- [Monobank: invoice creation](https://monobank.ua/api-docs/acquiring/methods/ia/post--api--merchant--invoice--create)
- [LiqPay: two-step payment](https://www.liqpay.ua/en/doc/api/internet_acquiring/two_step?tab=2)
- [Monobank: hold finalisation](https://monobank.ua/api-docs/acquiring/methods/ia/post--api--merchant--invoice--finalize)
- [Monobank: cancellation](https://monobank.ua/api-docs/acquiring/methods/ia/post--api--merchant--invoice--cancel)
- [LiqPay: refund API](https://www.liqpay.ua/en/doc/api/internet_acquiring/refund?tab=0)

Research check: 8 October 2026. The export date remains 14 September 2026. Local scheme descriptions are context, not confirmation of a particular provider’s capabilities.