English

Русский
Deutsch

English

Русский
Deutsch

Appearance

Working with payments in QryptoPay ​

Every payment in QryptoPay has its own card — the "Blockchain payment details" dialog. Open a merchant, go to the "Payments" tab, hover over the row you need, and click the icon with the "Payment details" tooltip.

The tab has a search — by the customer's email (partial match) or the exact payment ID — plus filters by paid status, currency, and chain. The status next to a payment shows its stage: "Created" and "Not paid" mean the money hasn't arrived yet, "Partially paid" and "Overpaid" mean the amount didn't match what was expected, "Paid" means the payment is closed, "Expired" means the deadline passed, and "Void" means it closed without a payment.

Blockchain transaction data ​

The card shows the transactions found for the payment, and the "View in explorer" link next to each one opens the block explorer.

⚠️ Recheck and transaction lookup — Tron and Ethereum only

The "Recheck payment" and "Check transaction by ID" buttons only appear on the card for payments on the Tron and Ethereum chains — that's TRX, USDT TRC-20 and other Tron tokens, plus ETH, USDT ERC-20, USDC and other Ethereum tokens. For Bitcoin, Litecoin, and Monero there are no such buttons in the card — there's no manual recovery tool for those chains.

Webhook delivery ​

Once a payment is paid, the card gains a "Webhook delivery" block — it shows whether your store's status notification for this specific payment got through. Possible states:

  • Delivered — the store received the notification.
  • Sending… — a delivery attempt is in progress right now.
  • Retry pending — the previous attempt failed, the retry has been queued and runs automatically.
  • Failed — delivery didn't succeed, and there won't be any more automatic attempts.
  • Never sent — the notification has never been attempted.

Scenario 1. The customer paid, but the panel doesn't register it ​

The customer says they sent the money, but the payment is still unpaid. For Tron or Ethereum there are two tools, in order of effort.

Start with "Recheck payment". The panel re-scans the blocks for the payment's entire lifetime, looking for transfers to its address beyond what the regular scanner covers. The result arrives as a notification: found — the panel credits it and updates the payment's status; nothing found — for an already-paid payment that just means it's already accounted for, for anything else the next step is the transaction lookup. Capped at three rechecks per payment per hour.

If the recheck doesn't help, or the customer can share the transfer's hash, click "Check transaction by ID", paste the hash into the "Transaction ID" field, and click "Check" — a dry run that changes nothing yet. If the transfer belongs to this very payment, an "Import" button appears. Other answers are covered in The money landed in the wrong place below. Capped at ten checks per hour per terminal.

Scenario 2. The panel registers the payment, but the store never got the notification ​

The payment is paid, but the store never reacted: the order didn't close. The reason lives in the "Webhook delivery" block, which only appears on already-paid payments.

The panel sends the status notification automatically as soon as a payment closes, and if the first attempt fails, it keeps retrying once an hour until it gets a 200 OK back. The "Resend" button is for when waiting isn't an option, or the automatic retries have already run out:

  • at "Retry pending" — the panel sends it right away instead of waiting for the next automatic attempt;
  • at "Failed" — there are no more automatic attempts left, and this is the only way to try again;
  • at "Never sent" — this sends the notification for the first time.

If the terminal has no webhook URL configured, there's no button — instead a prompt to fill in the webhook appears (that's done during the webhook setup step of the store integration).

⚠️ Resending an already-delivered notification is risky

For the "Delivered" state, the panel calls this out specifically: the store already got the notification once, and resending it may cause a duplicate credit on the store's side. Only resend if you're sure the store never actually processed it.

⚠️ "Never sent" covers two different cases

If a notification was already generated but never went out, the panel resends that exact one, unchanged. But if nothing was ever generated, it builds a fresh one from the payment's current data — which may end up different from what the store would have gotten originally.

The "Resend" button is capped too — no more than five sends per payment per hour.

Scenario 3. The money landed in the wrong place ​

The customer sent you a hash, but the payment you have open isn't the one it belongs to: the transfer landed on the customer's address, but got attributed to a different payment, or to none at all. The panel usually assigns the same address to a customer for all of their payments and looks up the transfer by address, not by a specific invoice — so any payment of that customer's will do, not necessarily the "right" one.

Open the card of such a payment, click "Check transaction by ID", paste the hash into "Transaction ID", and click "Check". From here:

  • The transfer belongs to a different payment — that payment's card opens, with an "Import to this payment" button, which credits the transfer there, not to the payment you had open.
  • No matching payment exists — the transfer arrived while no invoice was open on that address. "Record as top-up" creates a separate, already-paid payment for it so the funds aren't lost, and notifies the store about it.
  • The transfer was already imported earlier — the card shows which payment it belongs to, nothing else to do.

Other answers — a blockchain node error, a licence restriction, and the like — are explained right in the dialog; then the only thing left is to try again later.

BeAdmin © 2025. All rights reserved.