auditing-payment-callback-and-amount-integrity

Auditing payment callback and amount integrity: the success message is attacker-reachable until you verify it

When a payment finishes, the application finds out from the processor through a redirect back to the site, a server-to-server webhook, or a status poll, and it acts on that message by marking the order paid and shipping the goods. If the message is trusted without verification, the attacker controls the one signal that releases value. The failures are concrete. A callback whose signature is not verified lets an attacker post a spoofed success with no real payment. An amount or currency read from the callback or the client, rather than reconciled against the order the server itself created, lets an attacker pay one cent for a thousand-dollar order or switch to a cheaper currency. A success notification not bound to a specific order can be captured from a real small purchase and replayed onto a larger order. And a status trusted without an out-of-band confirmation to the provider takes the attacker's word for settlement. The audit treats the payment result as untrusted input until the server verifies its authenticity, its amount, and its binding to the order. You audit this by forging and altering the callback and confirming each is refused.

When to use

• The application learns a payment succeeded from a processor callback, webhook, or status poll.
• The amount, currency, or status may be read from the callback or client instead of reconciled server-side.
• A success notification may lack a verified signature or a binding to the specific order it settles.

Scope check

Test payment callbacks only against systems you own or are authorized to assess, on non-production or sandbox payment paths. Forging and replaying callbacks drives real fulfillment on a live system, so use sandbox processor credentials and test orders and never mark a real order paid or trigger a real shipment. If you can't name the authorization, stop.

The loop

1. Establish the trusted settlement signal first. Name exactly what the server must verify before it treats a payment as settled: the callback's signature against the processor's key, the amount and currency against the order the server created, and the notification's binding to that specific order, ideally confirmed out of band with the provider. This is the false-positive killer: a flow that verifies the signature, reconciles the amount and currency server-side, binds the notification to the order, and confirms settlement with the provider is correct. Name the trusted signal, then test forgery.