Payment gateways for your store: how to compare total costs

A store has received two proposals for online payments: one offers a lower fee, while the other makes refunds and reconciliation easier. Comparing payment gateways by the percentage fee alone leaves some costs out of the picture. To choose, you need the same sales profile for each comparison, providers’ written terms and a check of the entire payment journey—from the basket to the bank statement.

Below is a way to compare LiqPay, WayForPay and other solutions available to you without a universal ranking. Add an international service such as Stripe to your shortlist only after checking whether it is available to your legal entity.

First, define exactly what you are buying

A payment gateway transmits transaction data and results, while acquiring enables the acceptance of card payments. A provider may bundle these components with a payment page and dashboard. Compare the scope of the specific offer, not product names.

Create a store profile: the seller’s country, currency, customer locations, payment volume, order value and refund rate. Add the operations you need: partial refunds, payment holds, recurring payments and payment in instalments. A feature’s presence in the documentation does not confirm that it is enabled under your contract.

Rule out solutions that do not support your seller or a required use case. As of 11 November 2026, Ukraine is not listed among the countries with standard access to Stripe Payments. Being able to accept money from a Ukrainian customer is not the same as being able to register a Ukrainian merchant.

Calculate the total cost, not just one rate

The total cost of accepting payments has two layers: charges for the provider’s services and the store’s implementation and operating costs. Request the same set of terms from each candidate. An empty cell in a response means “needs clarification”, not a zero price.

Recurring charges and deductions

Record the percentage of the payment amount, the fixed charge per transaction, subscription fees, any minimum charge and separate terms for different payment methods. For international payments, establish where currency conversion occurs, who sets the exchange rate and whether there is an additional charge for a foreign card. Do not apply Stripe’s US pricing to a Ukrainian store: pricing pages vary by market and product.

Separately clarify what happens to the fee on a full or partial refund, what costs arise when a customer disputes a payment and whether additional services carry charges. For Shopify, also check the platform’s fee for using a third-party provider: this is a separate expense from the payment service’s own fee. Check applicability and exceptions against your store’s current terms.

Money that is temporarily unavailable

Payout schedules and any reserve affect working capital, but do not always constitute a fee or permanent loss. Do not add the entire reserve to the monthly cost. Separately check whether you will have enough funds for purchasing, delivery and refunds before the payout arrives.

Technical costs include analysis, a module or custom integration, status handling, accounting integration, testing, monitoring and support. A module must be checked for compatibility with your CMS. For the broader budget, see what affects a store’s costs over three years; here, we are calculating the costs of the payment setup.

Compare candidates using verifiable criteria

LiqPay’s documentation describes Checkout with the provider’s payment page, immediate charges, payment holds and subscriptions. WayForPay Purchase also describes a secure page, the customer’s return via returnUrl and a separate notification to the seller via serviceUrl. These are starting points for a technical comparison, not proof of identical pricing or feature availability.

For a standard payment, an off-the-shelf module and the provider’s payment page may be sufficient. For pre-orders, check the transition from a hold to capture; for recurring sales, check repeat payments and customer consent management.

Calculate costs for the same set of transactions

Use historical data from a representative period or a clearly labelled forecast for a new store. Divide payments by method, currency and other characteristics that affect pricing. For each group, calculate the percentage fee on the agreed basis and fixed charges for the corresponding number of transactions. Then add subscription fees and other confirmed expenses without double-counting.

A hypothetical example, not market rates: a store has 1,000 successful payments of UAH 800 each. Offer A is 1.5% plus UAH 2 per payment; offer B is 1.8% with no fixed component. Under these assumptions, A costs UAH 14,000 and B costs UAH 14,400. The difference is UAH 400, rather than the whole difference between the percentages. The example deliberately excludes refunds, currency transactions and other possible charges.

Recalculate the model for smaller purchases, a higher refund rate and foreign cards. You can spread one-off development costs over the planning horizon, but also retain the full initial investment figure.

Check how the store learns that a payment has been made

Payment gateway integration does not end when the card form opens. The browser’s return to a “Thank you” page must not be the sole confirmation used to dispatch goods. The customer may close the tab or lose their connection. The result needs to be verified server-side using the provider’s mechanism, and the payment must be linked to the correct order.

A server notification, or webhook, may arrive more than once. Stripe’s documentation explicitly recommends accounting for duplicates and verifying signatures. The store must handle a repeat without creating another order or shipment. Take signature verification rules from the chosen service’s documentation, not another gateway’s.

A hypothetical delayed-confirmation scenario

A customer has paid for an order, but the server notification is delayed. The website keeps the status “awaiting confirmation”, not “payment declined”. After verified success, the system marks the payment as completed once. A repeat of the same notification does not trigger a new action. If the status remains unclear, the order enters a review queue with an assigned manager.

Describe cancellation, partial refunds and retries separately. A payment, an order and a provider payout are different entities; a payout may combine many transactions. Reconciliation requires identifiers, amounts, currencies and statuses. Include this logic in the technical specification for the online store.

Complete acceptance testing before launching advertising

LiqPay separates test and live keys: test transactions do not move real funds. They check the logic, but not whether the contract and payouts are ready. Agree on the scope of the test environment and a verification check after activation with each provider.

1. Match the amount, currency and order number across the basket, request and payment record. Check discounts and changes to the basket contents.
2. Test success, decline, interrupted bank authentication and a closed tab. The customer should understand the current status and next action.
3. Check delayed and repeated server notifications. Separately ensure that an unverified notification does not change the payment status.
4. Run the agreed full and partial refund scenarios. Compare the remaining refundable amount and the store’s and provider’s records.
5. Reconcile the transaction report with orders and accounting records. In the live environment, also verify actual receipt of the payout under an approved procedure.
6. Check the mobile journey, staff access permissions, failure alerts and support instructions. Record the results and assign responsibility for fixes.

Acceptance criteria must be unambiguous: the amount matches, a duplicate does not trigger a repeated action, and a refund has a traceable status. For release, the online store acceptance and rollback rules are also useful.

Timelines, risks and the final decision

The launch timeline depends on agreement on use cases and commercial terms, obtaining access, integration, acceptance testing and checks in the live environment. Seller verification and feature activation may depend on the provider. Plan these dependencies separately: finished code does not mean you are ready to accept money.

Leave room in the budget for module updates, API changes, monitoring and support. Switching to another service also has constraints: transaction history must be retained, pending refunds must be handled, and payment token migration cannot be assumed to be automatically possible. A second gateway does not become a backup merely by being installed: you need switching rules that prevent duplicate charges.

Check requirements against the current LiqPay Checkout documentation or your candidate’s primary documentation. Compare the contract, cost model and tests. If a required use case does not work or payouts cannot be reconciled, a lower rate will not compensate.

Prepare your sales profile, providers’ responses and a list of problems with your current payment setup. Bring these to GL.ua (Glyanets) to discuss payment integration as part of developing or improving your online store. The concrete next deliverable is agreed use cases, a defined scope of work and acceptance criteria that allow the budget to be estimated without guesswork.