Choosing a payment gateway and payment methods

It is just past nine on a Thursday evening. A basket with fourteen line items sits on a building-supplies retailer's site. The customer enters a card, the bank's verification screen loads, and the mobile browser loses the tab. Second attempt. Third. On the fourth the customer gives up and messages the sales line instead: can I just wire it? The money lands the next morning with nothing in the reference field but a surname, no order number anywhere. Bookkeeping finds that payment four days later by reading statement lines one at a time. The order ships four days late. On the dashboard nothing looks wrong: the basket counts as abandoned, and the three failed card attempts appear in no report at all.

Most of what leaks out of a payment stack behaves like that. It shows up as silence, not as a complaint. This article walks through what a gateway technically does and does not do, how a bank virtual POS differs from a payment institution, which payment method closes which specific loss, why installments are their own decision in Türkiye, where the payment page should live, what the cost is actually made of, when the money reaches your account, why reconciliation refuses to balance, how refunds differ from chargebacks, what you must never store, and which numbers deserve a weekly look.

1Checkout23D Secure3Authorization4Capture5Payout6Reconciliation

What a payment gateway actually does

Treating a gateway as a machine that takes money is the root of every later misunderstanding. What it does is authorize: it carries the card details to the issuing bank, receives back a confirmation that the amount exists on the card and has been held, and attaches that answer to your order record. That step is an authorization, and an authorization is not money. It is a reserved slice of the customer's limit. Money changes hands at capture, which in most setups is a separate instruction entirely.

The distinction has a practical edge. An authorization has a lifespan, and that lifespan is finite. Teams that ship on the strength of an authorization and capture days later end up having delivered goods they cannot collect on. Even with a cooperative customer the card has to be charged again, and that is a phone call nobody wants to make. Whoever decides the order between deducting stock and capturing the payment has, in effect, decided how much collection risk the company carries.

Bank virtual POS, payment institution, or platform infrastructure?

There are three models, and the real difference between them is not technical but a question of who owns the problem. With a bank virtual POS you sign with each bank separately, manage separate panels and track installment campaigns one at a time; in exchange the chain is short and the money moves straight into your own account. With a payment institution one integration reaches many banks and card types, the panel is in one place, and a party that manages the money flow now sits in the middle. On a platform or marketplace the platform usually collects and remits your share, which leaves you with almost no say over the payment experience itself.

The question worth asking is not which option is cheapest but who you will be talking to when something breaks. Who opens the file when a chargeback lands, who investigates when the daily totals disagree, who tells you when a rule changes on the bank side? For a five-person team, having a single counterpart is worth more than a marginal advantage on paper. The site-side half of the same decision is covered in our piece on choosing an e-commerce platform.

The name on the cardholder's statement is a design decision

If the customer's statement shows an abbreviation they do not recognize instead of the name they bought from, that line will eventually be queried with the bank and a dispute will be opened. The person on the other side is not acting in bad faith; they simply cannot remember. Asking what the statement descriptor will read during contract talks, and shaping it into something recognizable, costs nothing and quietly removes a share of disputes before they start. The same logic applies to the sender name on your payment confirmation message.

Which payment method closes which loss?

Adding a payment method looks like a marketing decision. It is an operations decision. Each method brings its own reconciliation load, its own refund logic and its own way of failing. The list below is ordered not by feature but by the concrete loss each one closes.

• Credit and debit cards: Approve instantly and keep the order moving; the trade-off is drop-off at the verification step and the chance of a later dispute.
• Card installments: Make large baskets easier to commit to; the cost stays on the seller's side and grows with the term.
• Bank transfers: The simplest option on the deduction side, but without an order-specific reference code the matching is manual and shipping waits.
• Payment links: Let teams without a checkout flow, or those who close on the phone, still use card rails; they close the gap between quote and collection.
• Stored cards and recurring billing: End the monthly chase on subscriptions and maintenance contracts; they demand a plan for what happens when a card expires.
• Buy now, pay later: Rescue a buyer who is short on cash and move collection risk to a third party; returns then flow differently than on a card sale.
• Cash on delivery: Saves orders from customers with a high trust threshold; when delivery fails, the shipping cost lands entirely on you.

The standard advice is to enable every method you can. Its limit is clear: each method you open is another source to reconcile at month end, another refund rule for support to memorize, and one more option on the payment screen. In a company selling mostly to other businesses, where cards are a small share of volume, putting an automatic reference code on transfer instructions earns far more than four new methods ever will. We go deeper into collecting with payment links, into buy now, pay later as a way of shifting risk, and into the mechanics of recurring revenue in our article on subscription and renewal sales.

Installments: the part of the decision that is specific to Türkiye

In Türkiye, paying by card rarely means paying in one go. Customers read the installment selector as a standard field rather than a privilege. The mechanism is straightforward: the bank remits the sale to you along the installment schedule, and the burden on the seller grows as the term lengthens. You can absorb that burden out of margin, build it into the shelf price, or show it openly to the customer as a term surcharge. All three are defensible, and all three produce different customer behavior.

Here is the part most teams miss: installments change the composition of the basket, not just the conversion rate. When the option appears, the average basket grows because customers move toward the more expensive variant. If your margin happens to be thinnest on exactly that variant, revenue rises while profit falls, and nobody reading the summary can explain why. The fix is to report gross margin separately for installment and single-payment sales. It also helps to surface installment options on the product page rather than only at checkout, where the decision has already been made.

Where should the payment page live?

Three placements. Redirecting to the provider's own page is the fastest to launch and carries the lightest compliance footprint; the price is that the customer leaves your site and your brand disappears at the most sensitive moment. Embedding the provider's fields inside your own page is the middle road. Collecting card fields entirely in your own interface produces the best experience, but the moment you touch card data the weight of compliance moves onto you. For most small teams the right answer is to start embedded and move further only when there is a reason to.

What actually decides conversion is usually not the provider but how the verification step is built. Does the customer find their basket intact after bouncing to the bank screen and back? Does the error message repeat a bank code, or does it say what to do next? After a failure, is trying a second card one tap away? Answering those three questions moves more volume than switching providers does. Recovering the baskets that never made it through is the subject of abandoned cart automation.

What the cost is actually made of

Nearly every provider comparison collapses into one line: the deduction per transaction. In practice the burden arrives from at least six independent places, and most of them are not printed on the front page of the contract. The table below sorts them by where they originate and how they escape notice.

Cost item	Where it appears	How it goes unnoticed
Per-transaction deduction	On every successful capture	Revenue is tracked gross, so it never reaches the margin view
Installment burden	Growing with the length of the term	Buried in the shelf price and eaten out of margin
Time to payout	Between the sale and the money arriving	Appears on no rate sheet anywhere
Refund and dispute handling	Cancellations, returns, chargeback files	Booked as support and accounting hours
Integration and maintenance	At launch and at every version change	Assumed to be one-off, in fact recurring
Add-on services	Card vaulting, fraud screening, extra reports	Lives in an annex to the contract

The practical way to put these side by side is to compare providers on a scenario rather than on a rate. Describe a typical month: how many transactions, what mix of methods, how many refunds, how many disputes, how much of it on installments. Hand the same scenario to every candidate and ask for the total effect, and you will watch the ranking implied by headline rates rearrange itself. Documentation is a separate question; when it comes to which document must be issued and when for a cancellation or refund, check your own case with your accountant.

When does the money reach your account?

The gap between a sale happening and the cash arriving is the least discussed property of a payment stack and the one that hits cash flow hardest. On installment sales the bank spreads remittance across the schedule. Weekends and public holidays sit in the middle. Newly onboarded merchants may face a holding period for a while. None of this is hidden, and none of it is ever said in the same sentence as the headline rate.

The second surprise is that refunds are netted out of payouts. In a week of heavy returns the transfer you expected shrinks, and in extreme cases the balance moves the other way. This is the most common reason a team running an end-of-season sale misses its month-end cash forecast by a wide margin. Reading that lag alongside the framework in cash flow management turns an abstract preference into a decision you can defend.

If the provider with the lowest deduction also pays out the latest, you did not get a discount, you extended credit without noticing.

Why reconciliation refuses to balance

The daily total in the payment panel failing to match the amount on the bank statement is not a fault. It is the design working as intended. Providers usually deduct before remitting, batch several days of transactions into one transfer, and net refunds inside the same batch. One line on your statement therefore stands for dozens of orders in your system. Every team that tries to match order totals directly against statement lines ends up maintaining a hand-kept side ledger within a month.

What works is matching on three levels: order to transaction, transaction to payout batch, payout batch to statement line. At each level the source of the difference is visible on its own terms, so deductions, refunds, holds and currency effects stop hiding behind one another. We cover the first link of that chain in payment and CRM integration and the last one in bank statement integration and automatic matching.

Refunds, voids and chargebacks are three different things

They get spoken of as one word, and the confusion costs money. A void, made before the batch closes, releases the authorization and is generally the cheapest path. A refund reverses a completed capture, carries its own handling load, and takes days to reach the customer's card. A chargeback is a process you did not start: the customer goes to their bank, the bank pulls the amount back, and the entire burden of proof lands on you.

That is why a dispute needs an evidence file that already exists rather than one assembled under deadline pressure: the order record, the accepted terms or distance-selling text, proof of delivery, the correspondence with the customer, and the payment record itself. When those five pieces sit on one customer record the file goes out in minutes; when they live in five places, most teams miss the window. The customer-facing half of your refund policy is covered in consumer rights and return processes.

What you must never store

The simplest rule is the strongest protection: never keep the card number or the security code anywhere. A card taken over the phone and written on a notepad, sitting as a screenshot in a messaging thread, or typed into the notes field of a customer record, imports a risk into the company that cannot be deleted later. If you need recurring collection, the answer is not to store the card but to store the token the provider issues, which is meaningful only inside your own merchant account.

The second risk gets less attention: permissions inside the panel. When the refund button sits in the same hand that takes the orders, control has quietly disappeared. Separating refund rights, requiring a second approval above a defined threshold, and reading the panel's session log on a schedule are all steps that need no new software. The wider frame for access and backup is collected in cybersecurity basics for small businesses.

Which numbers to watch, and where to start

Six indicators cover most teams. Authorization rate says how many attempted payments succeed, and looking at it without splitting by issuing bank is misleading; when one bank's rate collapses, that is a configuration problem, not a market signal. Drop-off at the verification step is the grade on your payment page design. The distribution of decline reasons is the least-read report that says the most. The remaining three are refund rate, dispute rate, and the average time from sale to money in the account.

The usual mistake at launch is testing the happy path and going live. The lessons live in the broken ones: a timeout on the verification screen, the same basket submitted twice, a partial refund, an authorization that expired, a refund arriving after its batch was already paid out. Walk through those five by hand before go-live and write down how each one looks on the order record afterwards. Running one method for two weeks and closing the reconciliation manually is the cheapest way to write the rules you will live with for the next year.

Keeping orders, payments, account balances and invoices in one place is the shortest route to making payment leakage visible. In Rocketly a payment record stays attached to the customer, the running account and the invoice, and reconciliation differences stay on the same screen; open a free account and build your own collection flow.