3.0.11 — correct the transaction payload sent to Paystack

[jules-paystack]

Release 3.0.11. Three corrections to what the module sends to Paystack. Deliberately scoped to the outbound payload — nothing here changes how a payment is verified or how an order advances, so none of it can reject a payment that succeeded. The verification gate is a separate release.

Builds on #70 (@iammcoding), which is already on master.

What was wrong

1. Redirect-mode checkout failed outright on many totals. The amount was grandTotal * 100 — a float. Paystack rejects a non-integer amount, confirmed against the live API:

amount=1998.9999999999998 → {"status":false,"message":"\"amount\" must be an integer","code":"invalid_amount"}
amount=1999                → {"status":true,"message":"Authorization URL created"}

So this was never the 1-kobo undercharge #70's description guessed — it was a checkout the customer could not complete. Only inexact products break (19.99, 8.21, 1.10, 0.29); 5000.00 is fine, which is why it looked intermittent. Fixed by #70.

2. Inline mode overcharged by one subunit. Math.ceil(8.21 * 100) is 822, not 821. Now Math.round.

3. Redirect mode sent no currency at all. Setup.php called $order->getCurrency() — not a method on Magento\Sales\Model\Order:

getCurrency            declared: NO (magic __call -> getData)
getOrderCurrencyCode   declared: YES in Magento\Sales\Model\Order

It fell through to getData('currency'); sales_order has no such column, so it returned null. Paystack accepts a null currency silently, substituting the integration's default — so a base-NGN/display-USD store charged ₦12.50 for a $12.50 order with a status:true response and nothing in the logs. Now sends getOrderCurrencyCode() (not getBaseCurrencyCode() — the customer is charged in the display currency, and the inline flow already sends quote_currency_code).

Also fails closed when the order currency is empty, rather than letting Paystack pick.

⚠️ Behaviour change

A merchant whose Paystack integration does not have their store currency enabled will now see unsupported_currency where checkout previously completed in the wrong currency. That is the correct outcome, but it is visible — such merchants must enable their currency on their Paystack integration. Documented in the CHANGELOG upgrade note.

Verified

Runtime, on dev-repro/ (Magento 2.4.9 / PHP 8.5.1 / CSP enforced, production mode) — not just unit tests:

• Redirect, grand total 19.99 → the transaction Paystack actually created: amount: 1999, currency: ZAR. Integer, and the order's own currency.
• Inline, grand total 8.21 → popup posted amount=821. Same page shows Math.ceil would have posted 822.
• verify-checkout.js CSP regression guard: PASS — 0 blocked CSP violations, 0 JS errors, popup opens.

Unit suite: 12 errors → 7, 93 → 98 tests, 129 assertions. The 7 remaining are pre-existing and unrelated (observer tests stubbing magic accessors). Note the suite is not runnable from a fresh checkout and no CI runs it — that is why SetupTest had been failing since March; wiring it up is tracked separately, deliberately not coupled to this fix.

New tests: a data provider over the inexact totals (19.99, 8.21, 1.10, 0.29) — the old assertion used 5000.00, whose *100 is exact, so it did not cover the bug — plus a case asserting initializeTransaction is never called when the order currency is missing. Both confirmed to fail when the corresponding fix is reverted.

Also in here

• SetupTest/ConfigProviderTest stubbed getCurrency() and StoreInterface::getBaseUrl(), neither of which exists. That stub is how defect 3 hid — a PHPUnit stub on a magic accessor makes a non-existent method look real.
• build-adobe-zip.sh removed only the current version's zip, leaving prior-version artifacts at the repo root to be uploaded to Adobe by mistake.

Found while verifying, NOT fixed here

/paystack/payment/setup is invoked twice per redirect order, and I measured it rather than inferring it — temporary logging at the top of execute() and immediately before initializeTransaction, one order attempt:

PROBE setup::execute entered                    {"ref":"081799004"}
PROBE initializeTransaction about to be called  {"ref":"081799004"}
PROBE setup::execute entered                    {"ref":"081799004"}
PROBE initializeTransaction about to be called  {"ref":"081799004"}

Same reference both times. The first call initializes successfully; the second is rejected by Paystack as duplicate_reference, and it is that second response which reaches the catch — so the customer lands on checkout/onepage/failure with "Duplicate Transaction Reference" in order history even though the transaction was created and is payable.

The fact of the double invocation is measured; the cause is not yet known — I have not established what re-enters the route, and it should be diagnosed rather than guessed. Pre-existing and independent of this diff (none of these three lines affects invocation count); previously masked because the first call failed anyway. Filed for the next release.

🤖 Generated with Claude Code