View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007946 | module PayPal Checkout | module PayPal checkout - sub | public | 2026-05-07 10:55 | 2026-05-21 14:51 |
| Reporter | mario_lorenz | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2.8.3 / 3.7.3 | ||||
| Target Version | 2.8.4 / 3.7.4 | Fixed in Version | 2.8.4 / 3.7.4 | ||
| Summary | 0007946: remove storno-flag if paypal heal a pending order | ||||
| Description | If there is a genuine pending order from PayPal, it is initially moved to the ERROR status and cancelled. If PayPal subsequently marks the order as paid after a short while, the status is indeed updated to OK and the order is marked as paid; however, the OXSTORNO field remains set, and the order continues to be displayed as "Cancelled" within the admin interface. The cancellation status must definitely be removed, and—if possible—the "Pending" order status should perhaps be utilized in cases where the order corresponds to a "Payment Pending" status within PayPal. | ||||
| Additional Information | QA - ES - | ||||
| Tags | No tags attached. | ||||
|
|
This highlights another general issue regarding "order healing." The current approach—combined with your requested fix—works without problems in cases involving high inventory levels. However, what would happen in the case of shops dealing in single-item stock or low-inventory goods? As a result of the initial cancellation, the item is released back into inventory. If that item has since been resold, the original order may indeed be paid for retroactively; however, the merchant would no longer be able to fulfill the order and would be forced to issue a definitive cancellation. How would you proceed in such a situation? |
|
|
When a customer pays using a payment method where PayPal provides the final payment confirmation with a delay—typical examples include uAPM methods (iDEAL, Bancontact, Blik, EPS, P24) and PayPal Standard with a delayed capture strategy—an intermediate state occurs: PayPal reports the payment as "authorized, capture to follow later," and the OXID order initially remains in a "not finished" (NOT_FINISHED) state. The crucial final webhook (PAYMENT.CAPTURE.COMPLETED or PAYMENT.CAPTURE.DENIED) can take anywhere from minutes to hours to arrive. During this waiting period, the automated cleanup job indiscriminately canceled all "not finished" PayPal orders that were older than the configured cleanup window—including legitimate orders that were merely pending payment. Consequently, when PayPal later confirmed the payment's success, the incoming webhook encountered an order that had already been canceled and, to protect data integrity, took no further action. The result: The funds had reached the merchant, but the order in OXID remained stuck in a "Canceled + ERROR" state. What changes does the fix introduce? - The cleanup job will now leave orders with an active PayPal status (APPROVED / COMPLETED) untouched. These orders will proceed to wait for the final webhook as intended. - Orders with no PayPal status, or with a status of CREATED (indicating the customer closed the PayPal popup without confirming), will continue to be cleaned up once they exceed the configured cleanup window—this behavior remains unchanged. - If PayPal subsequently declines the payment (PAYMENT.CAPTURE.DENIED), the order will now be correctly canceled, and the reserved inventory will be released. This functionality was previously missing. Lifecycle of a Pending Order Following the Fix: 1. The customer completes payment using, for example, iDeal ? The order is created with the status NOT_FINISHED; inventory is reserved; and the status APPROVED appears within the PayPal block of the order details. 2. PayPal renders a decision after a period of minutes or hours: - Success: The order is automatically set to OK and marked as paid. - Rejection: The order is automatically cancelled, and the inventory is released. Impact on Shops with Low Inventory Levels: Inventory remains reserved throughout the PayPal decision phase—a departure from previous behavior. Consequently, an item with a stock level of 1 cannot be sold simultaneously to a second customer while the first order is still pending within the PayPal processing window. This safeguards against a scenario where the merchant is unable to fulfill an order after a successful PayPal payment has been received. The trade-off: in cases where PayPal response times are lengthy, the merchandise becomes temporarily unavailable for re-order. We consider this trade-off to be the appropriate default setting. What Remains Outstanding? In the extremely rare event that PayPal fails to send a final webhook at all (e.g., due to persistent webhook delivery issues on PayPal's end), the order will remain permanently in a pending state, and the inventory will remain reserved. Currently, this issue must be resolved manually within the Admin interface (by viewing the order and, if necessary, selecting "Cancel PayPal Order" via the existing Admin function). An optional safety cleanup mechanism—featuring a long time-out period and a cross-check against the PayPal API—is planned as a follow-up ticket; should you encounter this specific scenario with any noticeable frequency in your setup, please do not hesitate to let us know. Orders that have already become "stranded" (i.e., orders that were erroneously cancelled prior to this fix, despite PayPal subsequently confirming the payment) will not be retroactively corrected by this update. Such a correction would necessitate manual adjustments to inventory levels—adjustments that could potentially impact merchandise that has since been sold to other customers. |
