The problems below cover most of the support tickets we see for the Opayo by Elavon (formerly Sage Pay) Magento 2 extension. On Magento 1? Its errors are on Magento 1 (legacy).
First: check your version
A large share of payment-flow tickets are fixed by updating — recent releases fixed duplicate orders after 3-D Secure, duplicate invoices, stuck challenge screens and capture timeouts. Check the Changelog for your line before debugging further.
Reporting & Admin API failing? Update your extension
In July 2025 Opayo changed the security requirements of its Reporting and Admin XML API. Extensions older than the versions below can’t reach it any more. Admin refunds, online invoicing/capture, the Opayo Fraud column and order syncing all go through this API — even for PI and PayPal orders — so on an old version, live refunds and fraud updates fail while test mode may still appear to work. Update to at least 10.48.10 (Magento 2.4.8+), 10.4.10 (2.4.0–2.4.7), 10.3.7 (2.3), 10.2.7 (2.2), 10.1.7 (2.1) or 10.0.5 (Magento 1).
Setup & account
| Problem | Fix |
|---|---|
| “Your ebizmarts Payments Suite license is invalid” | Keys are per storefront domain and per release line — upgrading to Magento 2.4.8+ needs a new licence key from support. Work through the checklist on Licensing & tokens; development licences are free (the dev domain must contain “dev”, “local”, “beta”, “staging” or “test”) |
| Licence shows Active in your ebizmarts account but invalid in Magento | Scope, Base URL match, Activate + cache flush, release-line match — the full checklist is on Licensing & tokens. Never edit your Base URLs to match a licence record |
| Composer fails with “HTTP Basic: Access denied” or a token error | Tokens are per product with different usernames (token, hyva, brippo), and a new token is generated at every annual renewal — update auth.json after renewing. Details on Licensing & tokens; to start clean: composer config --unset repositories.ebizmarts, then redo the Installation steps |
| Invalid Opayo API credentials | The credentials don’t match the selected mode — test-environment credentials for test mode, live for live. See Configuration |
| “Invalid merchant authentication” | The PI integration’s API credentials are wrong — re-create them in MyOpayo per Configuration |
| “Authentication values are missing” | The PI Integration Key and Password fields are empty — fill them in per Configuration |
| “Invalid FORM encrypted password” / error 5080 — form transaction registration failed | The FORM encryption password is wrong — copy it again from MyOpayo → Settings → Admin |
| Error 4020 — “Information received from an Invalid IP address” | Register your server’s IP in MyOpayo → Settings → Valid IP’s; if you’re unsure which IP your server sends from, a test/simulator transaction reveals it |
The Reporting API user
Admin refunds, online invoicing, the Opayo Fraud order-grid column and the Sync From API job all depend on the Reporting API credentials in Basic Settings, and three things routinely break them:
- The user must have transaction access. An Opayo Administrator user doesn’t — create a separate MyOpayo user with transaction access for the Reporting API fields.
- A stale password in any store-view scope locks the account. The fraud and sync cron jobs retry every scope’s credentials; one forgotten scope with an old password will get the user locked out at Opayo again and again. Check every configuration scope for the credentials warning, not just the default.
- Old extension versions fail the API’s signature check — see the July 2025 callout above.
Symptoms of a broken Reporting API user: the Fraud column stuck on “Waiting”, refunds failing with “The specified vendor and user combination is not valid, or the user may be locked out”, and orders no longer syncing status from Opayo.
Checkout & 3-D Secure
| Problem | Fix |
|---|---|
| SameSite cookie errors — Chrome blocks Opayo’s callback cookies | Set the cookie flags at the web server. Apache: Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=None — or the equivalent cookie-flag configuration in Nginx |
| “Message not from trusted origin” | On Magento 2.4 this usually means the Magento_Csp module is disabled — re-enable it with bin/magento module:enable Magento_Csp. Otherwise allow *.sagepay.com, *.paypal.com and ebizmarts-website.s3.amazonaws.com in your CSP directives (script-src, img-src, style-src, connect-src, font-src, frame-src, form-action) |
| Duplicate orders — both paid, customer says they never saw the success page | The payment authorised but the customer wasn’t redirected back after 3-D Secure, so they ordered again; the replayed challenge logs “Operation not allowed for this transaction”. Update first — 10.48.14 / 10.4.14 fixed 3-D challenge edge cases that produced duplicates — and if it persists, contact support with the order pair and logs |
| Customers stuck at the 3-D Secure challenge / error 1029 “Duplicated Transaction” in the logs | The challenge is being submitted twice, looping at the ACS. Update to the latest release; browser ad-blockers are a known trigger, so ask affected customers to disable them as a test |
| Customer completed 3-D Secure but the log shows “Missing mandatory field: cRes” | The bank’s authentication page failed or was abandoned — the response never reached Opayo. It happens occasionally and is outside the module; if it clusters, enable Open 3D Secure in a new window (redirect instead of pop-up — pop-ups misbehave in some browsers), or consider the Server integration |
| After a failed 3-D Secure the cart is emptied and the stock is locked | By design: the pending order holds the stock until the cancel-orders cron releases it. To retry immediately, cancel the pending order manually; the pending-payment lifetime is configurable (added in 10.4.6) |
| Orders stuck in Pending Payment though the payment succeeded — “Order count: 0” in the callback log | A 3-D Secure callback timing issue — update to 10.48.12 / 10.4.12 or later. The Sync From API cron self-corrects affected orders to Processing within ~30 minutes; verify your Base URLs match the checkout domain |
| Payment rejected over address fields — “Invalid City. Please use A-Z, a-z, 0-9…” or long streets | Opayo enforces character rules and length limits (street ≤ 50 characters) on address fields. Recent releases trim long streets automatically — update first. Find the offending value in Request.log; note values are masked unless “Prevent customer personal data logging” is disabled in Advanced Settings |
| Card-testing fraud against payment API endpoints | Block the offending IPs and follow Adobe’s carding-attack guidance — rate-limit guest payment endpoints and watch for bursts of failed authorisations |
| One Step Checkout error | Known incompatibility between OSC 1.2.040 and Payments Suite 1.4.2 on Magento 2.4 — update OSC to its latest release |
| Error 5006 — “Unable to redirect to Vendor’s web site” | Opayo’s callback POST isn’t reaching your site: check firewall rules, disable maintenance mode or password protection, rule out a Magento error on the success path, and make sure SSL 3.0 is disabled |
| Google reCAPTCHA incompatibility | With reCAPTCHA enabled on checkout, FORM works but PI, Server and PayPal error — disable reCAPTCHA for checkout until the compatibility update ships |
Invoices, refunds & capture
| Problem | Fix |
|---|---|
| Capture Online (or a refund) returns a 503/timeout — retrying then says “The referenceTransactionId cannot be repeated” or “This refund amount will exceed the original transaction” | The first attempt usually succeeded at Opayo and only the response was lost — check MyOpayo before retrying, and don’t re-submit. The retry errors are the gateway refusing a duplicate, not a second charge. Sync From API reconciles the Magento order state; update to the latest release, which hardens invoice generation against this |
| Multiple invoices created for a single order (payment captured once) | A race in the invoice-creation cron on older releases — update to the latest version of your line; if you’re pinned to an older release, contact support for the patch |
| Refund or capture off by 1p — credit memo says £18.06, Opayo shows £18.05; or “the remaining refund amount isn’t a clean number of pence”; or error 4049 “The ReleaseAmount larger the original amount” on deferred capture | Rounding mismatches between Magento’s tax calculation and Opayo’s pence amounts. For deferred/SERVER, enable Save Order Before so the order total is fixed before redirect, and review your tax rounding settings (unit price vs row total). If a partial-refund remainder is rejected or refunds land consistently 1p out, contact support with the order’s Request.log entries |
| Refunds fail on live but work in test (seen with PayPal since August 2025) | Admin refunds go through the Reporting XML API even for PI and PayPal orders — this is the July 2025 API change; update per the callout at the top and check the Reporting API user above |
| “Invalid transaction id” (Magento 2.3) | Schema mismatch on sales_order_payment: run bin/magento setup:db-schema:upgrade, verify the last_trans_id field length is 100, remove the patch entry if needed and flush the cache |
| PI has no “Authenticate” payment action | Correct — PI offers Authorise & Capture and Defer only; Authenticate was never implemented for PI (it exists on FORM and Server). Defer behaves like Authenticate in practice: orders are captured when you invoice them from the order grid |
Still stuck after trying these? Contact ebizmarts support with your Magento and extension versions and the relevant var/log/SagePaySuite/ log excerpts. (Those logs can grow large on busy stores — they’re safe to delete and are regenerated automatically.)