Webhooks Missing for Underpayments (Amount Signature Issue)

API
1

Hi Atlos Team,

We’re hitting a critical blocker with your EVM payment flow. Your amount signature approach for order identification on shared wallets breaks down when amounts don’t match exactly no webhook fires on under/overpayments.

Funds land in our wallet but our system stays blind, orders hang indefinitely.

Request:

1. Unique Addresses for EVM

I know EVM doesn’t natively support unique addresses like UTXO chains, but maybe one wallet per order with a sweep mechanism could work?

2. UTXO Webhook status

BTC/XMR/LTC already have unique addresses, just need UNDERPAID/OVERPAID status.

Cheers

2

We are aware of this issue and are looking into possibly adding unique address generation as an option in the future. We will likely never add the underpaid / overpaid status though, since we already pass the amount field. For now, you can have your users enter a transaction hash and pass it into our API for approving a transaction with a specific hash.

Here is the API endpoint:
“Transaction/CreateWithTxid”. The inputs are “PaymentId” and “Txid”.

This will detect and attribute payments even if your users send the wrong amount.

3

i cant find this api endpoint, could you please link it?

4

https://api.atlos.io/gateway/rest/Transaction/CreateWithTxid

5

ok so there seems to be an issue with that endpoint
i paid only “0.004030700000”

it says AmountPaid 0.006540940000

Atlos CreateWithTxid response: {
  "Result": 1,
  "AmountPaid": "6540940000",
  "Payment": {
    "Id": "dW9w9pd6ySm0WCbF",
    "AssetCode": "xmr",
    "BlockchainCode": "xmr",
    "Amount": "6540940000",
    "Fee": "0",
    "RecipientAddress": "49AYJCx5oc6UEBZ25ScUDMGDMR7bE4pW6i5MEZXpopMBf82w4QomLRqWH8DEbUaWG271qQveQWufrNigCYA6TBuzTXv8xZP",
    "Txid": "a65b68be0bcbc042f0deb94c1ebe833ffb7b21c1e0acba5db8fc24ab39e939d2",
    "Status": 100
  }
}

BTW THIS IS A HUGE BUG

PAYMENT ID: dW9w9pd6ySm0WCbF

expected amount is “0.006540940000”
sent amount is “0.004030700000”

6

Thanks for bringing this to our attention. Its been fixed. You can call the same endpoint to make sure.

1 Like