The Art of Business Logic — When the Checkout Got the Price ...

src/pentesting-web/bypass-payment-process.md

@@ -12,6 +12,25 @@ Map the complete transaction state machine—cart, checkout session, payment-pro
 - **Referrer**: It might point to the source from where the request originated.
 - **Callback**: This is typically used for redirecting the user after a transaction is completed.
 
+### Stale Pricing State and Checkout State-Machine Abuse
+
+A checkout can be vulnerable even when the client never submits a price. The backend may create a derived pricing object (discount, quote, promotion result, shipping selection, or checkout session) for **cart state A**, accept a later transition to **cart state B**, and then reuse the state-A pricing context. If checkout trusts only the cart/session identifier instead of rebuilding or validating all dependent pricing data, the server itself can calculate an attacker-beneficial total.<sup>[[2]](#references)</sup>
+
+Test the workflow as a sequence of state transitions, not as isolated requests. The core probe is to create valid pricing state, mutate the cart through an accepted application action, and request checkout again without editing any explicit `price` field:<sup>[[2]](#references)</sup>
+
+```text
+record product -> cart -> checkout baseline
+trigger quote/discount/promotion calculation
+return to cart and intercept one state transition
+change its state-controlling value and forward it
+request checkout again with the same cart/session
+compare the new server-generated pricing and payable amount
+```
+
+Repeat this around quantity changes, item replacement/removal, coupons, bundles, shipping methods, subscription options, and promotion activation/deactivation. After each transition, verify that `productId`, quantity, currency, subtotal, discount eligibility/value, shipping, tax, and total all describe the **same current cart state**. If exposed, also compare cart revisions, quote IDs, promotion IDs, and checkout-session IDs; an older identifier that remains valid after a dependent mutation is a strong stale-state signal.<sup>[[2]](#references)</sup>
+
+Do not stop at a checkout preview or browser-rendered amount. Trace the reduced server-side total through order creation and the payment request/callback: if the final stage recalculates the authoritative amount, impact is limited; if it accepts and fulfills the stale lower amount, this is server-side price manipulation.<sup>[[2]](#references)</sup>
+
 ### URL Analysis
 
 If you encounter a parameter that contains a URL, especially one following the pattern _example.com/payment/MD5HASH_, it requires closer examination. Here's a step-by-step approach:
@@ -41,5 +60,6 @@ If you encounter a parameter that contains a URL, especially one following the p
 ## References
 
 - [1] [OWASP WSTG — Test Payment Functionality](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/10-Business_Logic_Testing/10-Test-Payment-Functionality)
+- [2] [The Art of Business Logic — When the Checkout Got the Price Wrong](https://zuksh.medium.com/the-art-of-business-logic-when-the-checkout-got-the-price-wrong-4d548971b4a3)
 
 {{#include ../banners/hacktricks-training.md}}