The page answers two different questions at once
A player looking at a payment methods page is usually holding two questions that pull in opposite directions. The first is practical: which route will move money into the account, and which will move it back out. The second is about control: once the money has moved, who can reverse it, and on what conditions. A payment methods page that only lists logos answers the first question and leaves the second entirely to the reader's imagination. The page is most useful when it separates what a route can do from what the operator will do with it.
Runebanks publishes its payment methods page as the entry point for both questions. The page itself is a catalogue of route classes, not a contract. The contract lives in the terms that govern deposits and withdrawals, in the cashier screens that appear after login, and in the provider's own terms for the instrument the player chooses. Reading the page well means knowing which of those documents carries which part of the answer.
Route classes and where the reversal risk sits
Payment routes fall into a small number of classes, and each class puts the reversal risk in a different place. A card payment is a pull from the player's bank through a card scheme. The scheme's chargeback rules allow the cardholder to dispute a transaction after it has settled, which means the operator can never treat a card deposit as final money until the scheme's dispute window has closed. A bank transfer is a push from the player's account. Once the transfer has cleared, reversing it requires the sending bank to recall it, which is a slower and less automatic process than a card chargeback. An e-wallet sits in between: the wallet itself is the payer of record, so the operator sees the wallet's settlement rather than the underlying card or bank account, and the wallet's own dispute process governs what can be pulled back. A prepaid voucher is the closest thing to cash: once the code is redeemed, there is no payer-side reversal mechanism at all, which is why operators often restrict withdrawals to a different route when the deposit was prepaid. Crypto is a push settlement on a public ledger; once confirmations have accumulated, the transfer is irreversible by design, and the only reversal is a voluntary return initiated by the recipient.
The practical consequence is that a deposit route and a withdrawal route are not automatically the same thing. An operator may accept a deposit method that it will not use for withdrawals, either because the method cannot receive funds or because the operator's own risk rules require a route with stronger identity checks. The payment methods page is where that asymmetry should be visible, but it is often shown only as a footnote or a separate withdrawal column. When the page does not state a withdrawal route for a deposit method, the reader cannot assume one exists.
| Item to confirm | Why it can change | Where it is stated |
|---|---|---|
| Which deposit routes are currently accepted | Operators add and remove routes as provider agreements change | The deposit section of the payment methods page, and the cashier after login |
| Which withdrawal routes are available for each deposit route | Withdrawal routing depends on identity checks and provider support, not just on the deposit method | The withdrawal section, or the cashier's withdrawal screen |
| Which fees belong to the provider | Provider fee schedules change independently of the operator | The provider's own terms; the operator's page may only state whether it passes fees through |
| Which stage sets the timing | Each route has a provider-side settlement window and an operator-side processing window | The operator's withdrawal policy, not the payment methods page itself |
| Whether a deposit route can be reversed | Reversal rules are set by the card scheme, bank, wallet, or ledger, not by the operator | The terms of the instrument, and the operator's chargeback or disputes clause |
| Whether the operator requires the same route for deposit and withdrawal | Anti-money-laundering rules can require withdrawals to return to the deposit source | The withdrawal policy or the AML page |
Which stage sets the timing
Timing is the item players most want to read off a payment methods page, and it is the item the page itself almost never states. The reason is structural: a payment has at least three stages, and the operator controls only one of them. The first stage is the provider's settlement window, which is the time the card scheme, bank, wallet, or ledger takes to move the funds from the player's side to the operator's side. The second stage is the operator's processing window, which is the time between the operator receiving the funds and the operator crediting the player's account or approving a withdrawal. The third stage is the return leg, which for withdrawals is the same provider settlement window in reverse.
Across operators, the provider-side windows are the ones that vary most by route. Card deposits commonly settle within minutes but can be held for scheme-level review. Bank transfers commonly take one to three business days on the deposit leg and the same again on the withdrawal leg. E-wallets commonly move funds within minutes within the same wallet ecosystem but can take longer when the wallet itself settles to a bank. Crypto settlement depends on network congestion and the number of confirmations the recipient requires. None of these figures should be read as Runebanks's numbers; they are the market's usual ranges, and the operator's own page is the only place a figure for Runebanks is binding.
The reader's job is to identify which stage a stated time refers to. A time that covers only the operator's processing window leaves the provider's settlement window unstated, so the total time is longer than the page suggests. A time that covers the full cycle from request to receipt is the useful one, but it is rare. When the page states no time at all, the reader should treat the withdrawal policy as the controlling document and the payment methods page as a list of routes, not a schedule.
Fees belong to someone, and it is usually not the operator
A payment methods page that lists fees is doing something unusual: it is aggregating costs that are set by third parties. Card schemes charge interchange and scheme fees to the merchant, not to the cardholder, but an operator may pass those costs through as a deposit surcharge. Banks charge wire fees on both legs, and the sending bank's fee is separate from the receiving bank's fee. E-wallets charge for currency conversion, for wallet-to-bank transfers, and sometimes for inactivity. Crypto networks charge a transaction fee that varies with network load, and an operator may add a processing margin on top of it. Prepaid vouchers often carry an issuance fee at the point of purchase, before the operator ever sees the voucher.
The distinction that matters is between a fee the operator sets and a fee the provider sets. An operator can decide to absorb provider fees, to pass them through unchanged, or to add its own margin. The payment methods page may state the operator's policy, but the provider's fee schedule is the provider's document. When the page is silent on fees, the reader should check the cashier screen at the moment of the transaction, because that screen is where the total cost is itemised. A fee read from a third-party summary is not a fee the operator is bound to honour.
What the page cannot tell you
There are three things a payment methods page structurally cannot answer, no matter how carefully it is written. The first is which route will work for a specific player. Availability depends on the player's country, the player's verification status, the player's history with the operator, and the operator's current risk rules. A route listed on the public page may not appear in the cashier after login, and a route that appears after login may not be listed on the public page. The second is the total cost of a transaction. The operator's page can state its own fees, but the provider's fees, the currency conversion spread, and any intermediary bank charges are outside the operator's control and often outside its knowledge. The third is the reversal risk on a specific deposit. Whether a card chargeback will succeed, whether a bank will recall a transfer, whether a wallet will honour a dispute: these are decided by the provider's rules, not by the operator's page.
When the page does not state a withdrawal route for a deposit method, the absence is itself the answer: the operator has not committed to returning funds by that route, and the reader should not assume symmetry. When the page does not state a processing time, the absence means the timing is set elsewhere, usually in the withdrawal policy or in the cashier at the moment of the request. When the page does not state a fee, the absence means the fee is either zero, absorbed, or itemised only at the point of payment. The reader cannot tell which from the page alone.
FAQ
Why is a deposit method sometimes not available for withdrawals?
A deposit route and a withdrawal route are different operations. A withdrawal requires the operator to send funds to the player, which means the route must be able to receive funds, must pass the operator's identity checks, and must not create a money-laundering path. Some deposit methods, especially prepaid vouchers, cannot receive funds at all, so the operator must use a different route for the return leg.
Where does the payment methods page state the processing time?
Often it does not. A processing time has a provider-side settlement window and an operator-side processing window, and the payment methods page may state only one of them, or neither. The binding time is in the withdrawal policy or in the cashier at the moment of the request, not in a summary table on the public page.
Which fees on a payment methods page are the operator's fees?
Only the fees the operator sets itself. Provider fees, card scheme fees, bank wire fees, wallet conversion fees, and crypto network fees are set by third parties and can change without notice to the operator. The operator's page may state whether it passes those fees through, but the provider's own terms are the source for the provider's charges.
Can a deposit be reversed after it has been credited?
That depends on the route class. Card deposits can be disputed through the card scheme's chargeback process. Bank transfers can be recalled by the sending bank in limited circumstances. E-wallet deposits are subject to the wallet's dispute rules. Prepaid and crypto deposits are effectively irreversible once settled. The operator's chargeback or disputes clause states how the operator handles a reversal, but the reversal itself is the provider's decision.
This page is an independent summary of what a payment methods page covers. It is not published by Runebanks, and it states no figure or status for them; the operator's own payment methods page, cashier, and withdrawal policy are the only binding sources.
Play responsibly
Gambling should be treated as paid entertainment, never as a way to earn income or recover losses. 1-800-MY-RESET (1-800-697-3738)
18+ or 21+ depending on where you are; follow the minimum age that applies to you.
This article is general information about how these mechanics work. It is not legal advice and not a recommendation to gamble or to use any particular operator. Availability and legality differ by jurisdiction — check the rules that apply where you are.
