Choosing a Payment Provider for Your Online Store

Payment provider selection usually comes down to whoever has the lowest advertised percentage. That number is one line in a longer bill, and it is often not the line that hurts.

Here is what to compare properly.

Terms worth separating

Three different things get called the same thing.

A merchant account is what allows funds from card sales to reach you. Traditionally a separate arrangement with an acquiring bank.

A payment gateway is the technical layer that carries the transaction from your checkout to the network.

A payment service provider bundles both, which is why most small and mid-sized businesses use one. A single relationship, a single integration, one place to look when something goes wrong.

The bundled route costs slightly more per transaction and saves a great deal of setup and ongoing administration.

Why the headline rate misleads

The advertised percentage is the best case. Your effective rate includes several things that are not in the headline.

• Cards issued outside your region carry a higher rate
• Commercial and premium cards cost more than standard consumer cards
• Currency conversion has its own margin
• There is usually a fixed fee per transaction on top of the percentage
• Refunds may not return the original fee
• Chargebacks carry a flat fee whether or not you win

Work it out against your own mix. If your average basket is small, the fixed per-transaction fee dominates and the percentage barely matters. If baskets are large, the reverse.

Run the numbers on last year's actual orders rather than on an example. The answer often flips.

When you actually get paid

This affects the business more than the rate does and it rarely appears in the comparison.

Some providers settle within a couple of days. Others hold funds for a week or longer, and new accounts frequently sit on a longer hold until a trading history exists.

If you pay suppliers up front and collect late, growth makes the squeeze worse rather than better. A higher rate with fast settlement can be cheaper than a low rate that ties up your working capital.

Ask specifically about the hold period for new accounts, not the standard one. They are often different.

Chargebacks

A customer disputes a charge with their bank. The amount is taken back, a fee is applied, and you get a window to submit evidence.

Two things matter here. How much help the provider gives you in responding, and what your dispute rate does to your account. Persistently high rates lead to reserves, higher pricing or termination.

Most chargebacks are avoidable with unglamorous work. A clear billing descriptor so people recognise the charge on their statement. Delivery confirmation you can produce. Contact details easy enough to find that the customer calls you before calling their bank.

Strong authentication and conversion

Additional cardholder verification reduces fraud and shifts liability away from you. It also adds a step, and some customers drop out at that step.

Modern implementations let low-risk transactions pass without a challenge while riskier ones get one. Ask how the provider decides, because a blunt implementation that challenges everyone costs real orders.

Whatever the setting, know where liability sits for a fraudulent transaction under each path. That is the part that costs money when it goes wrong.

Refunds and partial refunds

Selling is easy, refunding reveals the quality of the platform.

Ask whether refunds can be issued from your own admin in one action or require a request to the provider. Ask whether partial refunds are supported. Ask how long the money takes to reach the customer, and be ready to tell customers that number.

A weak refund flow shows up as support load and complaints, not as a line on an invoice, which is why it is easy to underweight when choosing.

Saved cards and one-click checkout

Letting a returning customer pay without re-entering details lifts conversion measurably. The card details are not stored by you and must not be. The provider holds them and gives you a token.

If you want this, confirm the provider supports it before you build. Adding it later means asking existing customers to re-enter their cards, which most will not bother to do.

Subscriptions have the same constraint and it is sharper. Migrating live subscriptions between providers is a project of its own.

Selling across borders

Shoppers want to pay in their own currency and with the methods they are used to. In several European markets, bank transfer based methods outrank cards.

Check the local methods for the countries you actually sell into rather than adding everything. Each additional method is more to configure and reconcile.

Decide who carries the currency risk. Displaying prices in the buyer's currency is better for conversion and exposes you to the rate. Find out how often the provider refreshes its rate, because a daily refresh can hurt in a volatile week.

What the integration actually involves

Payment integration is not a few lines of code. The work includes.

• Initiating and confirming the payment
• Handling success, failure and abandoned states separately
• Verifying provider notifications properly rather than trusting them
• Preventing the same payment being processed twice
• Connecting the result to stock and invoicing
• Testing every path in the sandbox

The duplicate prevention item is the one that bites. A customer refreshes the confirmation page, or a notification arrives twice, and one order becomes two. Systems that do not guard against it produce duplicate orders quietly for months.

PCI scope is a design decision

Card data brings compliance obligations, and how much depends entirely on whether the numbers ever touch your systems.

If the card form is hosted by the provider, or rendered inside your page by their code, the details never reach your server and your obligations shrink to a short self-assessment.

If you build your own card form and post it to your backend, you are in a much heavier regime with annual work attached.

For almost every business the first option is correct. The slight loss of control over the checkout appearance is not worth the compliance burden the second one carries.

Reconciliation at month end

The provider's payout report and your order records have to agree. When they do not, something is missing or duplicated.

By hand this is possible at low volume and impossible later. Writing your order reference into the transaction on the provider side makes it tractable.

Decide this before launch. Retrofitting a reference onto historical transactions is not really possible, and the conversation about whether the money arrived is unpleasant without one.

Testing and going live

Every provider has a sandbox with test cards. Use it for every path, including failures and refunds.

Then do it once for real. A small live order with your own card, followed by a live refund. Sandboxes do not behave identically to production and the difference always shows up in the least convenient place.

Switching later

Possible and unpleasant. Saved cards rarely move. Active subscriptions have to be recreated. Historical transactions stay behind.

Which is the argument for taking a week over the decision rather than a day. A week now is cheaper than a migration in two years.