Introducing Stripe for Solidshop — one integration, every payment method

Adding a payment method to a store used to mean adding an integration. Cards were one. Then a shopper in Amsterdam asked for iDEAL, so that was another. Then Klarna, then Apple Pay, and each one arrived with its own plugin, its own settings tab, its own callback URL and its own way of going quiet at three in the morning. The result is a checkout page with a stack of logos on it and a merchant who is not entirely sure which of them still work.

Today we are releasing the Solidshop Stripe plugin at 1.0.0, and it takes the opposite approach. You integrate once. Every method you have enabled in your Stripe dashboard then appears at your Joomla checkout on its own — and the ones a given shopper cannot use simply do not render.

The Payment Element does the choosing

The plugin puts Stripe’s Payment Element on your checkout page. Rather than the plugin declaring a list of methods, Stripe decides what to show per visitor, based on their region, the order currency, the amount, and the device they are on. A shopper in the Netherlands sees iDEAL. One on an iPhone sees Apple Pay. One buying a €600 sofa sees Klarna; one buying a €6 mug does not.

In practice that covers cards with 3-D Secure, Apple Pay and Google Pay, Klarna, Affirm, Afterpay/Clearpay, iDEAL, SEPA Direct Debit, ACH, and whatever else you enable at Stripe later — including methods that did not exist when you installed the plugin. Turning one on is a toggle in your Stripe dashboard, not an update to your Joomla site.

Every currency Stripe supports works, and the amounts are converted using Stripe’s own zero-decimal and three-decimal currency lists rather than the ISO ones. Those two disagree about HUF and TWD, and following the wrong one charges a hundred times too much. It is the sort of detail nobody thanks you for getting right.

Payments that finish after the shopper leaves

Cards settle while the shopper is still looking at your page. SEPA Direct Debit and ACH do not — the debit is in flight, and the answer arrives hours or days later. A gateway integration that treats “not paid yet” as “failed” loses those orders outright.

Solidshop records the order, releases the shopper, and waits. When Stripe confirms the money actually moved, a signed webhook marks the order paid and then sends the confirmation email — so your customer is never told their payment succeeded before it has.

Redirect and BNPL methods have a related problem: the shopper leaves your site to approve the payment, and by the time they come back the checkout session may have expired. They return through a signed, order-specific URL instead of relying on that session, so an approval that takes twenty minutes still lands on the right order.

Refunds, from either end

Refund an order from the Solidshop order screen — in full or in part — and the money goes back through Stripe without you opening a second tab. Each refund carries an idempotency key tied to its position in the sequence, so a retry after a timeout cannot refund twice, while a genuine second partial refund still goes through.

The interesting half is the other direction. Refunds issued in the Stripe dashboard — which is where they often happen, because that is where support staff live — come back through a webhook and post themselves onto the Solidshop order. Your order history stays true even when nobody touched Joomla.

Knowing which charge is which

A Stripe Payments list full of anonymous rows is a small daily tax on running a store. Solidshop names every charge with your store name and the order reference, so you can match a payment to an order from the list view without opening either.

The reverse lookup works too: each capture is written to the order’s Activity Timeline in Solidshop, with the Stripe transaction ID underneath it, ready to paste into the Stripe dashboard search. Both the checkout confirmation and the webhook log there, and they deduplicate, so a payment reconciled twice appears once.

Test keys and live keys, at the same time

The plugin stores both key pairs simultaneously and a single Test mode switch picks which is in use. Running a test order does not mean pulling out your production secret and putting it back afterwards — and test mode defaults to Yes, so a fresh install cannot take a real payment by accident.

Keys live on the store, not globally, so a multi-store install can run a separate Stripe account per storefront. Stripe Connect is supported the same way: give a store a connected account ID and its charges are made on behalf of that account.

If the mode you are in has no keys saved, Stripe removes itself from checkout rather than showing a payment form that cannot initialise. A half-configured gateway should be invisible, not broken.

What the server checks

Payment code is worth being paranoid about, so: every request from the browser carries a signed order token, which is what stops one shopper from driving another shopper’s order through the payment endpoints. Webhooks are verified against your endpoint signing secret before a single field is read, and then checked against the store they claim to belong to.

A payment is accepted only when the intent, the currency and the amount all match the order. If someone edits an order’s total in admin after the payment intent was created, the older, smaller intent records a partial payment rather than quietly marking the order paid in full. And when the webhook and the browser both report the same success — which happens constantly — the second one is recognised as a replay. No duplicate email, no duplicate ledger entry.

Your secret key never leaves your server. The browser only ever receives the publishable key and a client secret scoped to that one payment.

Setting it up

Four steps, about five minutes:

1. Install plg_solidshoppayment_stripe.zip through System → Install → Extensions.
2. Enable Solidshop Payment — Stripe in the Plugin Manager. It installs disabled, so nothing changes at checkout until you do.
3. Open Solidshop → Stores, edit your store, and paste your keys on the Payments tab. Both pairs, if you have them.
4. Copy the Webhook URL shown on that same tab into Stripe, subscribe it to payment_intent.succeeded and charge.refunded, and paste the signing secret back.

That fourth step is the one to not skip. Without it, card payments still work — but bank debits never complete, and dashboard refunds never come back. The full walkthrough, including test cards and troubleshooting, is in the Stripe plugin documentation.

Requirements & availability

Stripe 1.0.0 needs Solidshop 1.3.1 or later, Joomla 6.0+, and PHP 8.4+ — the installer checks first, so it will not half-install against an older core. Core 1.3.1 shipped yesterday and is what carries the payment entries the plugin writes to the order timeline. Your storefront needs HTTPS, which Stripe requires for live payments regardless. Twenty-three admin locales ship in the package.

Two things it does not do yet, so you are not surprised: dispute and chargeback events are not reconciled into Solidshop — they live in your Stripe dashboard — and Stripe’s Link prompt appears whenever the Payment Element collects an email and phone number, which cannot be switched off from the Element.

It is $49, one-time, per domain, with 12 months of updates and support included; renewals thereafter are 30% off. Stripe’s own processing fees are between you and Stripe — we do not add a percentage, and there is no monthly platform fee waiting on top.