Crypto Callback Manipulation

Overview

What it means and why it matters

Crypto callback manipulation is an attempt to forge, alter, replay or misroute a payment-status notification so a merchant application accepts an incorrect outcome. The danger lies in trusting a network message without appropriate verification.

How it works in practice

An attacker may post a fake paid payload to a public endpoint, change the amount or invoice identifier, or replay an old genuine notification. A secure handler verifies the authentication method prescribed by the provider, binds the event to an existing order and enforces allowed state transitions.

Technical detail without the jargon

If using HMAC signatures, verify the exact specified bytes, preferably the raw body, using constant-time comparison and appropriate replay protection. Also verify expected merchant/account scope, event ID and actual payment state when appropriate. HTTPS protects transport but does not prove the event came from the intended provider.

A deeper point to understand

Replay protection requires more than checking whether a signature matches: a valid old message can still be harmful if the handler allows it to overwrite newer state. Pair event authentication with freshness or unique IDs where supported and enforce the payment state machine independently of delivery order.

Common mistakes and limitations

Never mark an order paid solely because a browser redirect contains `status=paid`, or because a callback body says paid without authentication. Client-side hidden fields do not provide payment evidence.

What to check in a real payment system

Attempt replay of a previously valid paid message with a changed invoice ID or amount. The handler should reject tampering and avoid duplicate effects. Compare event identifiers, signing scope and current provider payment evidence without trusting browser redirects as payment proof.

Related concepts

Webhook, Webhook Verification, API Key.

Further reading

OWASP — Webhook Security.