The "GET /api/v2/shop/payment-requests/{hash}" and "PUT /api/v2/shop/payment-requests/{hash}" endpoints look up the payment request solely by the hash from the URL. No ownership check is performed against the authenticated customer or the underlying order. An attacker who obtains a payment request hash can: - read the payment request and, through the "payment" IRI in the response, recover the underlying order's "tokenValue" (which itself grants access to the full order, items, addresses, customer email, totals); - update the payment request payload (e.g. "target_path", "after_path"). These fields are used by the front-end controller to redirect the user after the payment, so an attacker can flip them to an attacker-controlled URL and intercept the buyer. The hash is a UUID, so it has to be obtained out-of-band (logs, shared links, referrer headers, a co-located client), but once it is known no other credential is required, neither authentication nor knowledge of the order token. The creation endpoint "POST /api/v2/shop/orders/{tokenValue}/payment-requests" shares the same flaw: it resolves the target order solely from the "tokenValue" in the URL without verifying that the caller owns the order.