Crypto payment AML checks: why a payment does not go through

A customer writes in: "I sent USDT half an hour ago, here is the hash, the money is not there." Behind that one sentence hide three different stories: the invoice expired, the wrong amount arrived, or the gateway stopped the payment on an AML check. They look identical to the customer, and each needs a different response. Here is the breakdown from the panel owner's side.

What the gateway actually checks

An AML check on a crypto payment is not a check on the payer. The gateway does not look at who sent the money, it looks at where the coins came from: every address has an open history on the blockchain, and a risk score is built from it. This kind of control is called KYT, know your transaction, as opposed to KYC, where a person and their documents are verified.

The score is assembled from three things. Address labels first: exchange, mixer, darknet market, sanctions list, casino, non-verifying swap service. Then tracing several hops back - where the coins reached the sender from, and where they reached that party from. Finally behavioural patterns, such as splitting a sum into dozens of small transfers. The output is a risk percentage, and everything after that depends on the threshold the gateway set for itself.

Hence a consequence worth spelling out to customers: money belonging to someone who broke no rules can still be held. Coins bought peer-to-peer from a random seller score around a third by industry measurements, while many platforms set their refusal threshold near seventy percent. So it usually goes through - but not always, and the buyer knows nothing about the coins' history until the payment is made.

Why one gateway accepts a payment and another freezes it

This is the most common customer question, and the answer is not "one gateway is good, the other is bad."

• Different scoring vendors. Gateways buy their scores from different analytics services, and the label sets do not match. An address flagged as a non-verifying exchanger by one may carry no flag at all with another.
• Different thresholds. A threshold is a setting, not a law. A gateway that works with European banks cuts harder than one serving crypto only.
• Labels appear retroactively. An address can be flagged a month after your payment, once an investigation reaches it. A check done yesterday guarantees nothing today.
• Different moment of checking. One gateway screens on the way in, before crediting. Another screens when the merchant withdraws. The second is the worst case for a panel: the customer has been credited, the service delivered and the provider paid, and you cannot withdraw the revenue.
• Issuer freezes. A separate case that has nothing to do with the gateway: the issuer of a centralised stablecoin can blacklist an address in the contract itself. Then the coins move nowhere, through any gateway.

What the panel sees meanwhile

Before you write to the customer about AML, look at the payment status - most cases are explained by it. Crypto gateways report a set of statuses, and the panel treats them differently.

• paid and confirmed - money received, balance topped up.
• paid_over - overpayment. The customer sent more than the invoice.
• wrong_amount_waiting - an underpayment that can still be topped up within the same invoice. Not a refusal, just an unfinished payment.
• wrong_amount - a final underpayment: less than the invoice arrived, but it arrived.
• expired - the invoice closed on time.
• cancel and system_fail - the gateway refused.

A rule our panel follows: the balance is credited with the amount that actually arrived, not the amount on the invoice. On both overpayment and underpayment the customer gets exactly what they paid. Crediting the invoice instead would mean gifting the difference on every underpayment.

Two details trip people up most often. First, for coins not pegged to the dollar the payment figure tells you nothing - 0.00007912 BTC is not comparable to a price, so the panel relies on the dollar equivalent the gateway sends. With USDT, USDC and the like the figure matches the dollar, so such a payment can be reconstructed even without that equivalent. Second, if the gateway charges a surcharge it sits inside the invoice, and an underpayment smaller than the surcharge leaves zero on the balance - not "something", exactly zero. For those cases the operator can confirm a payment manually with an explicit amount: when a customer underpaid and agreed something in support, a human decides, not the gateway.

Half of these tickets are not AML at all

Before suspecting a check, rule out five mundane causes. In our experience they generate more tickets than all blocks combined.

• The invoice expired. A crypto invoice is issued for a fixed amount and lives for a limited time - an hour by default with most crypto gateways. A transfer sent after it closes is not credited automatically: the address belonged to that specific invoice.
• Wrong network. USDT exists on TRC20, ERC20, BEP20, TON and several more, with different addresses. Sending "the same USDT" over another network is the most expensive beginner mistake.
• Missing memo. On networks where payments to a shared address are told apart by a tag, a transfer without a memo lands in the unclaimed pile. It gets sorted out manually and slowly.
• The rate moved. The customer copies the amount in coin, thinks for twenty minutes and sends - by then the rate has shifted and it is an underpayment. Not an issue for stablecoins, routine for BTC and ETH.
• Too few confirmations. The transaction is already visible on chain, but the gateway waits for the required number of network confirmations. The customer sees a hash and no balance - and opens a ticket.

Four of the five are fixed not by correspondence but by text on the payment page: name the network, warn about the invoice lifetime and about the memo. Which payment methods are worth connecting at all we covered separately - SMM panel payment methods.

When the problem lands on the panel owner

As long as it concerns the customer, it is the customer's trouble. The merchant has a risk zone of their own, and it is larger.

Incoming payments are yours. If a customer paid with coins carrying a bad history, the gateway asks the merchant account holder rather than them: verification, source of funds, a withdrawal screenshot, a description of what was being bought. The money sits frozen meanwhile, and no deadline for the review is usually given. For the SMM niche this bites harder: it is already treated as high risk, and a run of questionable top-ups gives a gateway grounds to close the whole merchant, not one payment.

That is why the panel carries its own risk signals on payments, counted honestly. No "risk 73%": the panel has no card data, no chargeback history and no payer device, so a percentage would be invented. There are five signals the panel genuinely knows - underpayment, several accounts from one address, a fresh account, complaints about the customer, a suspension - and which one fired is always shown next to it. No signals is honestly called "no signals", not "safe".

They matter in one specific scenario: a large first top-up from a new account, spent immediately on expensive services. That is textbook laundering through a storefront, and chains like it are exactly what gets merchants closed.

What to set up in advance

• Two crypto gateways rather than one. We have three, and it is not about variety: when one stops a payment or goes down for maintenance, the customer pays through the other instead of leaving. The connected set is on the payment systems page.
• Honest text at checkout. Network, invoice lifetime, memo, a warning not to send after expiry. The cheapest fix available.
• Large top-ups from new accounts by hand. That is exactly what the risk signals are for: not blocking everyone, but looking closely at five percent of payments.
• Refunds to the internal balance. Refunding crypto to a different address on request is a ready-made laundering scheme, and you are the one who will explain it. The detailed breakdown is in customer support and refunds.
• Keep the hash, the invoice id and the correspondence. That is what a gateway asks for, and it asks retroactively.

Two rules are worth passing on to customers who pay in crypto: screen the wallet before paying rather than after, and do not buy USDT at a rate noticeably better than the market. A rate that good on peer-to-peer is usually the price of a history the seller knows about and the buyer does not.

Where this will not help

Honestly about the limits. Once a gateway opens an AML review or an issuer freezes an address, the panel can do nothing: it has no access to that money, the gateway decides, and it promises no deadline. No checklist gives a guarantee either - labels appear retroactively, and yesterday's clean screening means nothing today.

We do not run AML expertise and do not give legal advice: our part is that the panel shows the payment status correctly, credits exactly what arrived and gives the operator levers when something goes wrong. If your audience pays in crypto only and buys it peer-to-peer only, some payments will always hang - plan support around that instead of treating it as an outage.

The rest is simple arithmetic: gateways are connected under your own credentials, customers pay you directly, and our plan does not depend on your turnover. Orders through our catalogue are never metered, and with third-party providers the first hundred orders a month are free.