Choosing a domestic PG and simple-pay provider · 2026

The first document everyone asks a provider for is the rate card, and some domestic providers publish standard rates. The rate applied to a merchant may still vary with the contract and eligibility conditions, so compare published schedules and individual quotes on the same assumptions. Roughly five things move the number: your category and what you sell, expected monthly volume and average ticket size, the mix of payment methods you want, how far forward you pull the settlement cycle, and how you post surety — insurance or collateral. Cards, bank transfer, simple pay, and carrier billing have different cost structures, so each carries its own rate, and any additional wallet charge must be checked for the specific method and contract. Comparing two candidates on the card rate alone is therefore not a comparison. Start instead by writing down your real transaction mix: split the last three months of orders by method share and average ticket, hand that same sheet to every candidate, and the quotes come back on one basis. A pre-launch service writes the projected mix for the first six months in the same format. There are other places a number lands in the contract. Some providers charge a setup fee or an annual platform fee, and settlement transfers, tax invoice issuance, or extra admin accounts can be billed per item or per month. The first year is not the rate line alone.

The axis that moves a cash plan more than the rate is the settlement cycle. Card revenue travels from the issuer to the provider and then to the merchant, so the day money lands in your account is set by the cycle in the contract, not by the purchase date. That cycle differs by method: a virtual account, where the deposit is confirmed first, does not settle on the same day as a card transaction that passes through acquiring. Pulling the cycle forward raises the rate, so read the two on one table. If you buy inventory before you sell it, a few days earlier is worth more than a few basis points. Deposits and surety insurance sit on the same axis. A provider wants recourse against cancellation, refund, and non-delivery risk, so category and volume determine whether collateral or surety insurance becomes a contract term, and services where payment and delivery are far apart — prepaid balance, reservations — attract that requirement hardest. Reserve clauses deserve particular attention: a term withholding a share of settlement when disputes spike or the cancellation ratio crosses a threshold is common, and if the ratio and release conditions are not written as numbers it becomes the route by which cash freezes in peak season. When volume overtakes the assumption in the contract, rate and cycle can be renegotiated, so fix that review point at signing. When the contract arrives, find four lines first: settlement cycle, withholding conditions, collateral size, and how residual funds are handled on termination.

The methods actually used in Korea come down to credit and debit cards, real-time bank transfer, virtual accounts, simple pay, carrier billing, and gift certificates. Simple-pay brands such as KakaoPay, Naver Pay, Toss Pay, and Payco can be reached either through the PG or under a direct contract with the operator, and which route you take changes both the rate and the settlement cycle. Device-bound methods such as Samsung Pay and Apple Pay carry their own app and hardware conditions. Methods differ in more than price — they differ in cancellation rules. Cards support partial cancellation as a matter of course, but carrier billing is charged alongside a phone bill, so once the billing month closes the cancellation path itself changes, and refunding a virtual account requires collecting the customer's bank details and sending money back. When gift certificates and loyalty points enter the mix, which tender is unwound first in a partial refund has to be written as a rule. So the method list is written in the order cancellation and refund actually flow, not in the order marketing prefers. A mail-order business accepting cash-equivalent payment falls under the escrow or consumer indemnity insurance requirement in the e-commerce act, so that item is checked before the shortlist closes. Whether the provider accepts cards issued abroad belongs in the same conversation: display currency, settlement currency, and issuer authentication all behave differently from domestic cards, so a service with overseas revenue needs a separate review.

Three capabilities look unnecessary at kickoff and get asked about within six months. The first is partial cancellation. Any service where one order holds several items, or where shipping splits, will soon need to return part of a single payment. Ask before signing how far the provider and each method allow partial cancellation, how many times a payment can be split, and what happens to a transaction that has already settled. The second is recurring billing. Domestic auto-payment works from a billing key the provider issues, with the merchant charging again from its own side, and billing key issuance is a review item separate from ordinary payment. If subscriptions are on the roadmap, putting the item in the first contract avoids a second review. The third is escrow. Transactions where payment and delivery are far apart fall under the deposit requirement, and switching it on creates new operational steps — purchase confirmation and shipping information handoff. All three reopen the order state model if added later, so record support for each on the comparison sheet even when you do not need them yet. Put the notification contract on the same sheet: how many times a provider retries a failed result notification, whether an inquiry contract exists for the merchant to ask the transaction state back, and when an authorized but unconfirmed transaction is auto-voided all differ by provider, and those differences become your exception-handling code.

Compare integrations by separating the work done by the provider's screen, widget, or SDK from the work done by your server. A provider-hosted payment screen can still require a server-side approval API call. Calling that API does not by itself mean your server handles raw card data. Check the product's documentation for the path of tokens and card data and for who performs authentication, approval, and cancellation. Compare screen customization, security requirements, and any additional review for that specific architecture. If you ship both an app and a web front end, the SDKs diverge even within one provider, so count that effort separately. Review runs on its own clock. It needs a business registration certificate, mail-order registration, a settlement account, and a live service screen, and reviewers read the product page, the terms of service, the refund policy, and the contact details. Category restrictions surface here too: every provider declines certain categories, and within an accepted category the items you carry can attach conditions. So name your category in the first call with each candidate and start document preparation in the same week as the build. Developer-facing conditions also separate candidates — whether the test environment reproduces failure, cancellation, and partial refund, whether every failure code is documented, and whether the integration docs match the current SDK all show up in week one and stay in the schedule. Opening a candidate's integration docs before signing settles most of this axis.

"More methods is better" is a sentence written without counting engineering and operations. Every added method brings three things. In engineering, one more authorization, cancellation, and refund path, with different failure codes and notification contracts, so exception handling and testing grow with it. In operations, another class of inquiry and one more desk to call when something breaks. In settlement, another file to reconcile, with fees applied at a different point and under different column names, so the matching rules are rewritten. Launch therefore with the methods that cover most attempts and add the rest once data exists. Start with cards and one or two simple-pay brands, watch where customers drop out of checkout and what arrives as inquiries, and add a method when the drop-off is visibly caused by its absence. Judge an addition by the orders lost for want of it rather than by the revenue it might create. Putting a gateway layer in first keeps that addition to one adapter instead of a change in order code, which makes the later decision cheap. If you do run more than one provider, settle the incident desk before signing: whether intake is by phone or console, whether a severity-based contact matrix exists in writing, whether a person answers at night and on weekends, and whether provider-side incidents are announced to merchants first. Two providers means every inquiry starts with deciding whose problem it is, so the intake route and diagnostic order per provider belong in the operations runbook — and that preparation is part of what selection costs.