Payment Verification
Ownership of a paid module is granted by one thing only: a cryptographically signed payment confirmation from the payment provider that passes independent checks. Nothing else — not a redirect, not a URL, not a client request — can unlock a module.
How ownership is confirmed
After a buyer pays, CodeSCE waits for an IPN (Instant Payment Notification) sent directly from the payment provider (NOWPayments). Before granting anything, the server independently verifies all of the following:
- Signature — the notification carries a cryptographic signature (
HMAC-SHA512) over its contents. CodeSCE recomputes it with a shared secret and compares in constant time. A bad or missing signature is rejected outright. - Status — access is only granted when the payment status is
finished(fully settled). Intermediate states like "confirming" don't unlock anything. - Currency — the payment must be in USDT on Tron (TRC‑20). A different coin or network is treated as a mismatch and not fulfilled.
- Amount — the amount paid must be at least the module's price, which is fixed server-side from the listing.
Only when signature, status, currency, and amount all check out is the module added to the buyer's account.
The success page is not proof
When a buyer returns from the payment page, that redirect is purely for convenience. It grants nothing — the frontend simply polls the real order status, which only flips to "paid" after the verified IPN is processed. Landing on the success URL without a real payment does nothing.
Anti-fraud guarantees
The verification model closes the obvious attacks:
| Attempt | Why it fails |
|---|---|
| Fake the success redirect | The redirect grants nothing; only a signed IPN unlocks access. |
| Forge an IPN | Requires the provider's secret to produce a valid HMAC-SHA512 signature. |
| Replay a valid IPN | Confirmations are idempotent — a repeat is detected and ignored. |
| Underpay | The amount is checked against the server-side price; short payments are rejected. |
| Pay the wrong coin/network | Currency must match USDT TRC‑20 exactly, or it's not fulfilled. |
| Change the price | The price is set from the listing on the server; a client can't alter it. |
Idempotency
Payment providers legitimately retry notifications, so every confirmation is processed exactly once. CodeSCE de-duplicates on the payment identifier, and the ownership grant is an atomic claim — even if two identical notifications arrive at the same moment across different servers, only one fulfillment happens, and a buyer is never double-charged or double-fulfilled.
Payout of failures
Statuses like failed, expired, or refunded are recorded but never downgrade a completed purchase — a late "expired" notice can't revoke a module that was already paid for. Repeated failures also feed the fraud protection layer.
That's the security model
Across scanning, downloads, watermarking, fraud protection, and payment verification, every layer is independent and fail-safe. Next, see how the pieces fit together in Architecture.