Two confirmed transfers to the same swap address do not necessarily form one accepted deposit. The service may process only one transfer automatically or require a separate decision about the second. Stop sending additional funds, preserve the original order and build a receipt ledger that identifies what each transaction actually delivered.
First establish whether there really are two incoming transfers
Two hashes in a swap history can describe different stages rather than two payments into the order. Gem Wallet’s cross-chain swap explanation distinguishes a source transfer from a destination payout, with possible additional identifiers for other stages. An order number is different again. Label the purpose and network of each identifier before deciding you paid twice.
The scenario here is narrower: two distinct source transfers each delivered funds to the deposit destination of one order. It can arise when a person sends from two wallets, splits an amount around a withdrawal limit or sends a small test followed by a remainder. A successful test shows that transfer reached its destination; it does not give permission to reuse a single-order address or guarantee that the service combines subsequent receipts.
Inspect the actual recipient amount rather than two changes in your wallet balance. For Bitcoin, the transaction developer guide distinguishes inputs, outputs and change. An input total is not the payment to the swap service, and change returned to you is not another deposit. Use the specific output paying the order destination. For tokens, verify the token identifier and network rather than adding amounts that merely share a ticker.
Build a two-receipt ledger before adding the totals
Use one row for each incoming transfer and keep the original order terms alongside it. The following is a fictional example, not a supported minimum, fee quote or KOT.CASH incident. The order expected 100 units of one asset on one network; the sender intended to supply 40 and then 60. Whether that plan is accepted remains a service-policy question even if the arithmetic matches.
| Ledger item | First transfer | Second transfer | Why the comparison matters |
|---|---|---|---|
| Distinct source transaction | Transaction A | Transaction B | A copied explorer link must not be counted twice |
| Asset and network | Asset X on network N | Asset X on network N | Different assets or networks cannot be merged by ticker |
| Actual amount delivered | 40 units | 60 units | The example totals 100; wallet fees are not added to the deposit |
| Order destination and required identifier | Compare against the original order | Compare separately against the same order | A wrong destination or memo changes the problem |
| Chain status and receipt time | Record the observed status | Record independently | One confirmed receipt does not confirm the other |
| Service processing result | Ask whether attached and processed | Ask whether attached, held or returned | A chain receipt is not the service’s order allocation |
Only total entries after confirming they represent the same accepted asset, network and destination context. Keep chain amounts in the asset’s units, rather than converting one receipt to a fiat estimate and comparing it with a later quote. Record what the service actually acknowledged next to what the explorer shows. A mismatch is the issue to investigate, not a reason to overwrite the evidence with your expected total.
If a transfer remains pending, label it pending rather than counting it as a confirmed receipt. If both references lead to the same transaction, fix the ledger instead of claiming a second payment. For a replacement transaction, follow the final transaction and its actual outputs; two wallet history entries do not establish two independent deliveries. This prevents support from searching for a deposit that never existed.
Read the rule for one order, not the rule for an account balance
A reusable account deposit address and an address created for one swap order can have different processing rules. FixedFloat’s terms of service, checked on 27 October 2026, explicitly restrict an order to one transaction and describe separate handling when multiple transactions arrive. That is an example of a named service’s policy, not a statement about every swap platform or the rules of KOT.CASH.
The distinction explains why a mathematically complete deposit can remain commercially incomplete. The service must decide whether the receipts can be attached together, whether one has already been exchanged, and what happens to an additional transfer. The original rate and the treatment of a later receipt should be confirmed rather than assumed. A refund can also have conditions and costs that need explicit review.
Look for the original order’s accepted amount, deposit deadline, permitted number of transactions and handling of additional receipts. If a minimum is relevant, ask whether it applies to each incoming transfer or to a supported aggregate. Do not invent the answer from the fact that two smaller amounts add up to more than the displayed minimum. Do not send a third top-up to test which interpretation the system uses.
Reconcile both receipts through one support conversation
- Keep the original order reference and make a separate ledger row for every actual incoming source transfer.
- Verify each network, asset identifier, destination, required memo or tag, actual delivered amount and current chain status.
- Record what the order page acknowledges and whether any payout has already been made.
- Contact the service through the original order’s official support route, providing both source references in the same conversation.
- Ask for a disposition for each receipt: included in the exchange, awaiting a stated action, handled under a separate quote or eligible for a reviewed refund.
- Do not confirm completion of the case until any agreed payout or refund is identifiable and its actual result matches the decision.
A useful message is specific: ‘I funded order [reference] through two source transfers, listed below with their networks and delivered amounts. The order page currently shows [status]. Please confirm which transfer has been processed and how the second receipt will be handled. I will not send further funds until this is clarified.’ Add the exact error if there is one, without posting the entire order page publicly.
Ask whether an existing payout corresponds to the first receipt, an agreed total or another calculation. Do not subtract the payout from the deposits when they are different assets. If a refund is offered, confirm its asset, network, destination and applicable deductions. An address visible as the sender of a custodial withdrawal may not be a personal receiving address you can safely use for a return.
Keep the second receipt visible after the first order completes
An order marked completed does not, by itself, account for every additional transfer you sent to its address. Retain the second row until the service explains its handling and you can verify the agreed result. Equally, two support tickets do not create two claims for the same receipt. Keep one timeline and update it as each transfer is resolved.
For the next swap, read the permitted funding method before sending a test amount and a remainder. If your funds are spread across wallets, ask about a supported procedure in advance or consider separate orders only under their own valid terms. Do not create an order with an invented deposit assumption and expect support to reconstruct your intended funding plan afterwards.
The KOT.CASH exchange walkthrough and simple-swap form are places to review the actual workflow and the current order details. They are not evidence of an undocumented promise to merge multiple deposits. Where amounts and costs are unclear, consult the fees page and ask about the specific order. A no-account swap still has terms for what constitutes its deposit; arithmetic alone does not replace them.
FAQ
Why is my crypto deposit not received when two transfers add up correctly?
The chain receipts and the service’s rules for attaching them to one order are separate checks. Verify each actual receipt and ask whether multiple incoming transfers are permitted for that order.
Does a Bitcoin transaction ID lookup prove both swap deposits arrived?
One lookup establishes information about that transaction, not a separate second transfer. Use a distinct row and recipient-output check for every source transaction.
Can a delayed deposit be fixed by sending the remainder again?
Do not send more until you know which receipts already exist and how they will be handled. An extra transfer can create another unresolved deposit rather than completing the original order.