> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mycryptoserver.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction Troubleshooting

> A payment looks missing or stuck — work through this before emailing support

**Your funds cannot be lost by this software.** My Crypto Server is non-custodial — payments go directly to wallet addresses you control. This guide helps you locate a payment that hasn't appeared in your dashboard yet.

***

## Step 1 — Check the blockchain directly

Get the transaction hash from your customer and look it up on the block explorer for the chain they used:

| Chain    | Block explorer                                             |
| -------- | ---------------------------------------------------------- |
| Ethereum | [etherscan.io](https://etherscan.io)                       |
| Base     | [basescan.org](https://basescan.org)                       |
| Arbitrum | [arbiscan.io](https://arbiscan.io)                         |
| Optimism | [optimistic.etherscan.io](https://optimistic.etherscan.io) |
| Polygon  | [polygonscan.com](https://polygonscan.com)                 |
| Solana   | [solscan.io](https://solscan.io)                           |
| Bitcoin  | [mempool.space](https://mempool.space)                     |

### What you see → what it means

**Transaction doesn't exist**

The customer hasn't sent it yet, or sent it on a different chain. Common causes:

* Customer selected the wrong network in their wallet (e.g. sent Polygon USDC to an Ethereum address)
* Customer's wallet is still broadcasting — wait 2–3 minutes and refresh
* Customer copied a different address than the one shown at checkout

**Transaction exists but shows as unconfirmed / pending**

It's in the mempool waiting to be mined. Expected wait times:

| Chain    | Typical confirmation time      |
| -------- | ------------------------------ |
| Ethereum | 2–5 minutes (12 confirmations) |
| Base     | Under 30 seconds               |
| Arbitrum | Under 30 seconds               |
| Optimism | Under 30 seconds               |
| Polygon  | Under 30 seconds               |
| Solana   | Under 30 seconds               |
| Bitcoin  | 10–60 minutes (1–6 blocks)     |

Bitcoin transactions with very low fees can sit in the mempool for hours. The customer can use a fee-bumping (RBF) tool to speed it up.

**Transaction exists, confirmed, but not in your dashboard → go to Step 2**

***

## Step 2 — Trigger detection manually

The dashboard has a built-in recovery tool. Go to the session in your dashboard and click **Check payment**. This scans the chain directly for transfers to the session's deposit address, bypassing the Alchemy webhook entirely.

If that marks the session paid, you're done. Your webhook endpoint will receive the `session.paid` event shortly after.

If it doesn't, continue below.

***

## Step 3 — Check your Alchemy webhook listener

When the automatic detection doesn't fire, the most common cause is a misconfigured or unreachable Alchemy webhook.

<Steps>
  <Step title="Verify your webhook public URL is reachable">
    Go to **Integrations → Alchemy** in your dashboard. Confirm the Webhook Public URL is set to your server's public HTTPS address. It must be reachable from the internet — `localhost` and private IPs won't work.
  </Step>

  <Step title="Check Alchemy's delivery logs">
    In the [Alchemy dashboard](https://dashboard.alchemy.com), open **Notify → Webhooks**. Find the webhook for the chain the payment was sent on and check recent delivery attempts. Look for failed deliveries, 4xx or 5xx responses from your server, or connection timeouts.
  </Step>

  <Step title="Signing-key mismatch (401s) self-heals">
    If Alchemy's logs show deliveries reaching your server but your server returns 401, the signing key is out of sync (e.g. a webhook was recreated out of band). The hourly Alchemy reconcile job re-asserts webhooks from the database and corrects this automatically; meanwhile the poller still catches the payment, so no funds are missed.
  </Step>

  <Step title="Check your server logs">
    Look for requests arriving at `/api/webhooks/alchemy` (EVM), `/api/webhooks/alchemy/solana`, or `/api/webhooks/alchemy/btc`. A missing request means Alchemy isn't reaching your server. A request with a verification error means a signing-key mismatch — the reconcile job will resync it.

    ```bash theme={null}
    # If self-hosting with Docker
    docker compose logs web --tail=200 | grep alchemy
    ```
  </Step>
</Steps>

<Note>
  If your Alchemy integration is disabled or the auth token isn't set, the app falls back to polling automatically. Detection will still work — it just takes up to 2–4 minutes instead of being near-instant.
</Note>

***

## Step 4 — Underpayment, overpayment, or wrong network

These cases are handled differently from a standard payment. Find the session in your dashboard and check its status:

| Dashboard status | What happened                                                      | Where to look                                                                                        |
| ---------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| `underpaid`      | Customer sent less than the required amount                        | Session detail → payment row shows the received amount                                               |
| `overpaid`       | Customer sent more than required                                   | Session is still marked paid; excess stays in the deposit address until swept                        |
| `expired`        | Session timed out before payment was confirmed                     | If a TX exists on-chain, click **Check payment** — it will still be accepted within the grace window |
| `paid_late`      | Payment confirmed after session expiry but within the grace window | Session is marked paid; webhook fires normally                                                       |

### Wrong network

If the customer sent on the wrong network (e.g. USDC on Polygon to a Base address), the funds went to a valid address on the wrong chain. The deposit address is derived from your seed, so you control that address on every EVM chain. You can recover the funds by importing the private key for that derivation index. Contact support with the transaction hash and we'll walk through the recovery.

***

## Step 5 — Sweep didn't run

If the session shows `paid` in your dashboard but the funds haven't arrived at your payout wallet:

1. Go to **Payouts** in the dashboard and find the corresponding payout record.
2. Check the status — if it shows `failed`, click **Retry**.
3. Common sweep failures:
   * Payout wallet address not configured (go to **Settings → Wallet**)
   * Insufficient gas — the deposit address needs a small amount of the native token (ETH, MATIC, SOL) to pay gas for the sweep transaction. For EVM chains, your server funds gas automatically if configured; check **Settings → Gas wallet**.

***

## Still unresolved?

Email **[support@mycryptoserver.com](mailto:support@mycryptoserver.com)** with subject line **TX ISSUE** and include:

* Transaction hash
* Chain and network (e.g. Base Mainnet)
* Expected amount and token
* Your server logs around the time of the transaction (redact API keys and private keys — we will never ask for them)
* Screenshot of the Alchemy webhook delivery logs if available

We never have access to your funds. Recovery of funds sent to the wrong address requires access to the private key for that derivation index, which only you hold.