This is the question that stalls deals in high-risk payments, and the one most providers answer with a shrug. Local push rails do not carry a card-scheme dispute mechanism — which removes one very specific threat and leaves several others intact. Here is the honest version of both halves.
A chargeback is not a refund. It is a forced reversal executed by the card networks against the merchant's acquirer, initiated by the cardholder's issuing bank. The merchant is a defendant in a process they do not control and did not consent to.
Three properties follow, and all three are what make card acquiring painful for restricted verticals. First, the decision belongs to the issuer. Second, the window is long — months after the transaction in many scheme rules. Third, and worst, the network counts your ratio. Cross a threshold and the problem stops being individual transactions and becomes your entire account.
That third property is the real damage. It is why a cluster of disputes can freeze a month of revenue, and why acquirers hold rolling reserves against a category rather than against a merchant.
On a card rail the merchant pulls funds from the customer's account. On a wallet, national QR or instant bank transfer rail, the customer pushes funds to the merchant, authenticating inside their own bank or wallet app before anything moves.
This is a structural difference, not a policy one. There is no card-scheme dispute system on these rails, and therefore no scheme dispute ratio to breach and no ratio-driven termination hanging over the account. That is the same point made on the high-risk merchant account page, and it is genuine.
The exemption is also narrower than it sounds. What disappears is the card networks' mechanism. What does not disappear is every other way a payment can be contested — and each local market has its own.
Market mechanics, described generically. Specific handling differs by channel and country and is confirmed at onboarding.
| Dimension | Card rails | Local push rails |
|---|---|---|
| Dispute mechanism | Formal card-scheme chargeback, initiated by the issuer against the acquirer | No scheme chargeback — complaints run through the payer's own bank or wallet operator |
| Who decides | The issuing bank, under network rules, with the merchant responding | The payer's bank or wallet operator, under its own local rules and local regulation |
| Typical window | Months after the transaction, set by scheme rules | Varies by rail and country; generally far shorter, and confirmed per channel |
| Effect on the account | Ratio counted at portfolio level; thresholds trigger penalties and termination | No scheme ratio; sustained fraud patterns are a channel-level and market-level matter |
| Refund execution | Reversal of the original authorisation through the acquirer | A new payout back to the payer, priced and limited like any payout |
These are market mechanics that exist independently of any provider. Treat this as the risk register, not as a statement of anyone's policy.
Removing the scheme mechanism does not remove the obligation to run a defensible business. Everything below is yours regardless of which rails you use, and all of it prices into your underwriting.
Written, visible before payment, and actually followed. Prop firms already know this — the funded-trader model lives or dies on it — but it applies everywhere. An unwritten policy is a policy the payer's bank gets to invent for you.
Logged acceptance of terms at checkout, transaction references that reconcile to your ledger, and records showing the service was delivered. When a complaint arrives, this is the entire difference between a conversation and a loss.
Knowing who paid you matters more on push rails than on card rails, because there is no issuer standing behind the identity. Matching payer identity to account holder is what defuses third-party-use claims before they become anything.
Most complaints escalate because nobody answered. A refund issued in hours rarely becomes a claim to a bank; the same refund issued in three weeks often does. Speed here is cheaper than any amount of documentation later.
This is the single most useful thing to internalise before you build your cashier, because it changes your cost model, not just your workflow.
Refunds are not free reversals. They execute as new payouts and are priced like payouts, which on a channel with a high refund rate can move your effective cost more than the collection rate does.
See payout rates by market →Per-transaction payout minimums and ceilings apply to refunds too. A deposit accepted below a channel's payout floor cannot be refunded as a single payout on that channel — worth checking against your ticket sizes.
Example limits: Malaysia →You are sending money to an account; there is no token to reverse. Capture and retain payer account or wallet details at collection, or you will be chasing them at the worst possible moment.
How settlement works →A webpage is the wrong place to commit to numbers that differ across 21 markets. These are the ones to get in writing against your actual channels.
Each market page carries its rails, limits and settlement terms, the context that decides how contested payments actually behave there. Compare all 21 markets on one page →
Send your vertical and target countries and we will walk through how contested payments and refunds work on the channels you would be using.
Message ZenexPay on TelegramDirect line to the team that runs the channels, not a sales layer.