Payment Bugs

When a payment request times out or the response fails to reach the client, the client retries the request. If the payment API is called without an idempotency key, the provider has no way to recognise the retry as a duplicate and processes it as a second, independent charge — billing the user twice for the same order.

The payment provider confirms a successful charge, but the application's order status is not updated from 'pending' to 'paid'. This leaves the order stuck — fulfilment is blocked, the customer is billed but receives nothing, and the only evidence of payment is in the payment provider's dashboard.

A refund for order 601 is successfully processed at the payment provider — the charge is reversed and the provider's dashboard shows the refund as complete — but the application's order status remains 'paid' rather than updating to 'refunded'. The application's webhook handler processes payment events but has no handler for the refund event type, so the order state machine never transitions.

The payment webhook endpoint POST /api/webhooks/payment processes any incoming request without verifying the provider's HMAC-SHA256 signature. A forged webhook event claiming a payment succeeded for order 701 can be sent by any HTTP client and will be processed as a legitimate payment, crediting an order without a real charge having occurred.