A third party payment flow has five steps: cart preparation, order creation, redirect to the gateway, payment, and return with verification. Each can fail through tampering or replay. Validate the cart on your server, confirm payment status with the gateway directly, and make fulfillment happen once.
The five steps
The OWASP Third Party Payment Gateway Integration cheat sheet lays out a typical flow:
- Cart preparation: the user selects items and starts checkout.
- Order initialization: your backend creates an order through the gateway API and receives an order ID or payment URL.
- Redirection: the user goes to the gateway hosted payment page.
- Payment: the user completes or fails the payment.
- Return and verification: the user returns to your site, and the gateway may also send a server to server notification. You verify the result and fulfill the order.
The guidance notes that gateways handle sensitive card data and can reduce your PCI DSS scope if integrated correctly. A poor integration can still allow payment spoofing, order manipulation and business logic flaws.
What goes wrong, step by step
| Step | Risk | Control |
|---|---|---|
| 1 and 2: Order data | Price tampering or product substitution on the client | Validate product IDs, prices and discounts on the backend, recalculate totals from trusted data |
| 5: Return page | Trusting parameters in the redirect URL | Treat them as untrusted, since users can change them |
| 5: Notification | Spoofed or replayed callbacks | Verify authenticity, for example with HMAC signatures or secret tokens |
| 5: Fulfillment | Processing before payment is confirmed | Confirm status through the gateway API before fulfilling |
| 5: Repeated callbacks | Double shipment or double credit | Idempotent processing, one fulfillment per order |
| 5: Late events | Retries and out of order delivery | Reconcile current payment state instead of discarding late events |
Match amount, currency and order
When you verify, check more than a success flag. The guidance says to match the expected amount, currency and order ID. A successful payment for a smaller amount than the cart is still a bug waiting to be exploited.
Timing subtleties
One line in the guidance is easy to miss. Treat checkout expiry separately from webhook signature freshness. Gateways can retry or send events out of order, so verify late notifications and reconcile current payment state rather than throwing them away just because the checkout session expired. Use persistent duplicate event records and idempotent fulfillment, as described in the OWASP Webhook Security guidance.
Our existing posts on webhook verification and idempotency keys cover the signature and retry mechanics in more depth.
Logging that helps without leaking
Log every payment attempt, redirect and callback with timestamps and IP addresses. Alert on unexpected statuses, such as an order marked paid with no gateway confirmation, excessive callbacks for the same order, and repeated failures with identical data.
The guidance also says to log callback identifiers, validation outcomes and order correlation data instead of raw headers and bodies, exclude credentials and unnecessary personal or payment data, and never retain sensitive authentication data such as card verification codes after authorization, even encrypted. Add risk scoring to spot carding behavior during payment execution.
A test plan
- Change the price in the browser request and confirm the order still uses the server price.
- Open the return URL with a forged success parameter and confirm the order is not fulfilled.
- Send a callback with a bad signature and confirm it is rejected.
- Send the same valid callback twice and confirm one fulfillment.
- Send a valid payment for the wrong amount and confirm it is flagged.
- Delay a callback past checkout expiry and confirm state reconciles correctly.
Where Safeguard fits
Safeguard does not process payments. Its dependency scanning and policy gates help keep the SDKs and libraries around your checkout code reviewed, and its zero-day discovery can flag newly disclosed issues in them. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the scan and look at which API weaknesses are flagged, such as missing authorization checks.
Quick check
Can I trust the return URL to confirm payment?
No. The guidance treats redirect parameters as untrusted. Confirm status with the gateway API from your server.
What does idempotent fulfillment mean?
However many times a callback arrives, the order is fulfilled once.
Sources
Last reviewed: 19 October 2026.
