Repository navigation
Fix: the callback rejected PENDING
PENDING is a live status on the wire, but the callback switch had no case for it, so it fell through to the unknown-status branch and answered HTTP 400. SpectroCoin records that as a failed delivery and retries it. The order is already sitting in the module's pending state when it arrives, so the right response is to acknowledge and change nothing — exactly what NEW already did.
WooCommerce and OpenCart both handle PENDING; PrestaShop was the outlier.
Adds a tier 2 end-to-end test
Configures the module in a real PrestaShop, places a real order, and delivers a callback for all 18 statuses, asserting the resulting order state each time — including the ten informational ones, which must leave the order alone. Also asserts the outbound create-order request describes the shop's order (currency, total, order id, callback URL, project id, User-Agent), and that the callback endpoint refuses a GET, an unknown order, an order paid through another module, and a settlement in the wrong currency.
The SpectroCoin API is stood in for by a stub answering as spectrocoin.com inside the compose network over TLS, so the module's shipped Config URLs are exercised unmodified — no credentials, nothing reaches the real API.
This test is what found the bug: it failed on PENDING only, and went green after the fix. The guard assertions were separately negative-tested by disabling the payment-method check, which then let a callback settle an order paid through another module.
Scope note recorded in the test: the order fixture is cloned from PrestaShop's own demo order rather than built by validateOrder(), and the redirect controller is not run — both need the Symfony container, which is null outside an HTTP request. The callback controller, which is the code under test, runs over real HTTP with the full framework.