Your gateway charged the card. Why is the order still stuck?

Fixed prices, no hourly surprises: a Quick Fix is $99 (~4h @ $25/hr) for one well-defined bug — like a single stuck “Pending Payment” order or a 3DS redirect. A Bug-Fix Sprint is $499 (~20h @ $25/hr) for a batch of bugs or one gnarly root cause with reconciliation and regression tests. For live stores losing orders right now, the Emergency / Retainer tier adds a 24/7 on-call SLA, with a $2,499 stabilization sprint (~100h @ $25/hr) for deeper payment-stack rebuilds.

Almost always the gateway charged the card but its webhook / IPN / callback never reached Magento, so the order never advances to Processing. The notify URL might be blocked by a firewall or WAF, redirected by an HTTPS / trailing-slash rule, or rejected by Magento’s CSRF / form-key check. We confirm the charge in the gateway dashboard, fix the listener, then replay the missed events so the stuck orders settle to their real status. Seen most with Stripe, PayPal IPN, and Razorpay.

3DS breaks when the redirect handshake doesn’t complete. Common causes: the return URL doesn’t match what’s registered with the gateway, the bank’s 3DS page is blocked from loading in an iframe by an X-Frame-Options / CSP header, or the Stripe / Adyen payment intent has gone stale before the customer finishes the OTP. Customers see Authentication failed or land back on an empty cart. We fix the redirect / iframe flow and re-test SCA end to end with a live 3DS test card.

Yes — this is one of the most common payment bugs after a go-live or a server migration. If the live store still points at test keys you’ll see errors like No such payment_intent or This API key is a test key; if test environments hold live keys you can take real money in QA. We audit the per-website / per-store-view config, move secrets out of the database into env.php so each environment is correct, and verify a real transaction against the live endpoint.

Yes. Double charges come from a retried submit, a slow 3DS return, or a webhook firing twice — creating two orders or two captures for one checkout. We reconcile the gateway ledger against Magento’s sales_payment_transaction records, refund the duplicate, then add idempotency on the place-order and capture calls so it can’t recur. The reconciliation is included in the Bug-Fix Sprint tier.

A method (PayPal, Stripe, Authorize.Net) vanishes when it’s filtered out: disabled for that website scope, restricted by country or currency, blocked by a minimum-order rule, or hidden because a JavaScript error broke the Hyvä or Luma payment renderer. We trace which rule or error is removing it — checking config scope, the browser console, and the payment method’s isAvailable() logic — and bring it back at checkout.

It means Magento can’t reach the gateway’s API. cURL error 28: Operation timed out usually means a blocked outbound port or a slow firewall; cURL error 60: SSL certificate problem means an expired or missing CA bundle on the server; cURL error 6: Could not resolve host is a DNS issue. We confirm connectivity from the server, refresh the CA bundle, and re-open the outbound path so auth, capture, and refund calls succeed again.

Yes. Admin-side capture and refund failures usually trace to an expired API credential, a currency mismatch between the order and the gateway account, a transaction that was already settled / voided gateway-side, or a cURL connectivity error. We check the gateway transaction state, fix the credential or config, and confirm a clean capture and a partial refund both go through from the admin.

All the major ones: Stripe, PayPal / PayPal Express, Braintree, Adyen, Razorpay, Authorize.Net, Klarna, and Mollie, plus the official Magento payment integrations and most third-party gateway extensions. If you’re on a regional or custom gateway, send the module name in the booking form and we’ll confirm before any work starts.

We reproduce and develop the fix on staging wherever possible — payment code is too risky to edit blind on production. If there’s no staging, we’ll spin one up or work in a safe, isolated way using the gateway’s test mode. The final fix is deployed to live and verified with a small real transaction. We never edit core files — everything is done via plugins, observers, or config, so it survives upgrades.

Yes — this is the whole point of working through a payment specialist. We work via the gateway’s tokens and webhooks, never raw card numbers, so your PCI / SAQ-A scope stays intact. Changes go through staging, get regression-tested across auth / capture / refund / 3DS, and ship with a rollback plan. Your existing successful orders and customer data are never touched.

Emergency cases (a live store losing orders) get a first response within 4 hours and a same-day diagnosis on the Emergency tier. A typical single bug is reproduced, root-caused, and fixed within 24–48 hours. Every fix carries a 14-day warranty on the same bug — if the issue we fixed comes back in that window, we fix it again at no charge. Report it on this page, or if it’s a wider checkout problem see our Magento checkout bug fixing page or the emergency e-commerce bug fixing hub.