The store sold on subscription, which only works if billing is dependable. It ran on a single payment gateway, and that gateway was declining far too many cards. Every failed payment was a customer who either tried again, contacted support, or walked away. For a business that lives on recurring revenue, a high failed-payment rate is not a checkout annoyance. It is monthly churn arriving through the back door.

The back office made it worse. Refunds were processed by hand, and reconciliation meant someone exporting reports and matching them to bank settlements line by line. Orders in OpenCart did not always agree with what the gateway actually charged, so the team spent hours each week chasing the gaps. Mistakes crept in, and a refund occasionally got missed or doubled.

There was also a plain conversion problem. A meaningful share of buyers wanted to pay with PayPal or with a card the single gateway handled badly, and the checkout gave them no way to do it. Those people did not complain. They closed the tab. The owner could see the drop-off in analytics but had no way to recover it without adding real payment options and fixing the failures underneath.

The brief was direct. Cut the failed payments, give customers more than one trustworthy way to pay, and stop the manual reconciliation that was eating the team's week. All of it had to stay compliant with the card rules that apply when you take payments in Europe.

We scoped the work as a focused payment gateway integration on the existing OpenCart store rather than a rebuild. The platform was fine. The payment layer was the problem. We started by reading the failure data from the current gateway so the redesign was driven by why cards were actually declining, not guesswork.

We added Stripe and PayPal alongside the checkout and let the customer choose. Stripe covers card payments and Strong Customer Authentication. PayPal covers buyers who prefer to pay from a PayPal balance or linked account and never enter card details on the site. This is standard third party API integration work, but the detail is in how the two providers behave differently and how you present them so neither feels bolted on. Both run server-side through their official SDKs, so card data never touches the OpenCart server and PCI scope stays narrow.

Declined cards were the biggest single loss, so retry logic went in early. We separated hard declines, where the bank will never approve the charge, from soft declines like insufficient funds or a temporary issuer block, where a retry on a sensible schedule often clears. For the subscription renewals we added retries with backoff and clear messaging to the customer instead of a silent failure. That single piece of payment processing integration is where most of the failed-payment reduction came from.

The reconciliation fix was webhooks. We built signed, verified webhook endpoints for both providers and made every order and refund event update OpenCart directly. A successful charge marks the order paid, a refund in Stripe or PayPal writes back to the order, and a failed renewal flags the subscription. We made the handlers idempotent so a webhook that arrives twice is processed once, with retries and logging on our side so a missed delivery is caught and replayed rather than quietly lost. This is the part of payment processor integration most teams skip, and it is exactly what ends manual reconciliation.

Compliance was handled in the same pass, not bolted on later. SCA and 3DS run through Stripe, so when an issuer asks for authentication the customer gets the bank challenge inside the flow and the payment completes once they clear it. We tested the integrate payment gateway flow end to end in each provider's sandbox: successful payments, every decline code, full and partial refunds, 3DS challenge and abandonment, and duplicate webhooks, before any of it went near live keys. Our custom api integration work always ships with this kind of test pass because a payment integration that has not been tested against real failure cases is not finished.

Across the project the approach stayed the same. Use the official APIs, keep card data off the client's server, handle the failure paths as carefully as the happy path, and leave the team a payment integration solution they can run without a developer on call. The api development services side, the SDK wiring and webhook handlers, mattered less than the decisions about what to do when a payment goes wrong, because that is where the store was losing money.