Most payment bugs come from ambiguity: a payment that is close to an invoice, but not quite it. Q8QPay removes that ambiguity with an exact-match policy. An invoice is confirmed only when an incoming payment satisfies four conditions at once — otherwise nothing happens to the invoice.
The four conditions
For a payment to confirm an invoice, all of the following must be true:
- Network matches. The payment's network (TRC20, ERC20, or BSC) must equal the invoice's asset code. The right amount on the wrong network does not count.
- Address matches. The destination must be the exact payout address on the invoice.
- Amount matches exactly. The amount must equal the invoice amount to four decimal places — 150.0000 means 150.0000, not 150.0001 or 149.9999.
- Within the expiry window. The payment must arrive and confirm before the invoice expires. Expiry is configurable from 5 minutes to 2 hours (30 minutes by default).
Why the amount has to be exact
Because many invoices can share the same payout address, the amount is what makes a payment unambiguous. By requiring a precise, four-decimal match, Q8QPay can tie an on-chain transfer to exactly one invoice with no guessing. That is what "deterministic" means here: the same inputs always produce the same, single result.
What happens when a payment does not match
Q8QPay has no underpayment or overpayment logic by design. If a customer sends the wrong amount, the wrong network, or pays after expiry, the invoice is simply not confirmed and no webhook is sent. The funds still arrive in your wallet — remember, this is non-custodial — but reconciling a non-matching payment is a manual, merchant-side decision rather than something the gateway guesses at. Fewer automatic edge cases means fewer surprises in your books.
Confirmations before "final"
Matching is only half the job; a payment also has to be settled on-chain. Q8QPay waits for a network-specific number of confirmations before marking a payment final: 20 on TRC20, 12 on ERC20, and 15 on BSC. This protects you from chain reorganizations that could otherwise reverse a "paid" status.
The webhook you receive
When an invoice confirms, Q8QPay sends your callback URL a webhook whose body is signed with HMAC-SHA256 using your webhook secret, delivered in the X-Webhook-Signature header. Verifying that signature proves the notification genuinely came from Q8QPay and was not forged. Failed deliveries are retried automatically with exponential backoff.
Why build it this way
Exact-match verification trades flexibility for predictability. There are no partial-payment states to interpret and no fuzzy matching to audit. An invoice is either confirmed by a payment that matches it precisely, or it is not — which is exactly the property you want when money is on the line.