Online shops
A plugin that installs in minutes and a checkout that does not lose customers.
In an online shop every extra checkout field costs orders. That is why tokenisation and one-click payment move the number more than almost any other change.
Refunds are issued from the shop's own admin, and incoming payments are matched to orders automatically.
What you get
Ready plugins
WooCommerce, PrestaShop, Magento, OpenCart.
One-click payment
Returning customers pay with a single button.
Deferred payment
BNPL for the larger orders.
Refunds from admin
No separate panel to log into.
Automatic reconciliation
The payment is linked to the order.
40+ methods
Cards, wallets and local methods.
Where orders are actually lost
An abandoned basket dies in a few typical places, and each one needs different treatment.
The first is the shock of the total. The customer saw a product price and at the final step delivery, a fee and sometimes rounding appear. That has nothing to do with payment, but payment gets the blame.
The second is forced registration. Creating an account in order to spend thirty euro is a step a large share of people refuse. Guest checkout is an hour of work to fix.
The third is the payment itself: a long form, no wallet, no saved card, a 3-D Secure flow that misbehaves on a phone. From here on it is our job, and it is exactly what we fix.
The fourth is trust. An unfamiliar domain, missing terms and a phone nobody answers stop a payment that had already been decided.
Plugin or API
On WooCommerce, PrestaShop and OpenCart the plugin is the right answer. Install it, paste the keys from the panel and choose which methods to show. Refunds are issued from the shop admin, without being in two panels for one operation.
On a bespoke platform or a non-standard basket the REST API gives you control. JSON requests, stable error codes, idempotency keys against double charges, and webhooks instead of polling.
Either way the test environment has cards for every scenario, including declines, expired cards and interrupted 3-D Secure. The whole flow is verified before a single real payment.
Payment methods: which earn their place and which just distract
More methods do not automatically mean more sales. A cluttered payment screen confuses and slows.
Essential for this market: card, Apple Pay and Google Pay. The first covers everyone; the other two cover the phone, which is where most traffic comes from.
Strongly advisable depending on the product: instalments where the average order is above a hundred euro, and Open Banking above a few hundred, where the saved card fee is real money.
A saved card for returning customers. In a shop with repeat purchases that is the cheapest conversion gain available to you.
Everything else is judged on data rather than on a list of what competitors show.
Refunds that do not eat your day
Online retail has returns, and that is a normal part of the cost rather than an exception. The question is how much administrative work each one takes.
Full and partial refunds are issued from the shop admin or the panel and are offset in the next settlement. No separate request, no waiting.
If you also run a physical shop on the same account, returning an online order in store is one operation. On two separate accounts it is a manual transfer and a conversation with accounts.
How it looks to the customer matters too: a refund usually appears on their card within a few business days. Saying that clearly in the confirmation saves phone calls on day three.
The numbers worth watching every month
Payment success rate. How many started payments complete. A low figure here usually means a technical problem or over-strict rules rather than a lack of interest.
Share of mobile payments and mobile conversion against desktop. A large gap means the mobile checkout has a problem invisible on a big screen.
Decline reasons. Separate the temporary from the final. The first are recoverable with a retry or an invitation to the customer; the second are not.
Average order value by payment method. This is where you see whether instalments genuinely lift the basket or merely move the same orders to a dearer method.
What each method brings
A rough guide, refined afterwards against your own data.
| Method | When it is worth it | What to watch |
|---|---|---|
| Card | Always | Payment success rate |
| Apple Pay and Google Pay | Always, if you have mobile traffic | Mobile conversion against desktop |
| Saved card | On repeat purchases | Share of returning customers |
| Instalments | Average order above €100 | Average value on instalments against card |
| Open Banking | Orders above a few hundred € | Share of turnover and fees saved |
More methods do not mean more sales. Each added method is judged on data after a month, not on what a competitor displays.
A quick audit of your checkout
Go through your own shop from a phone, as a customer, and note the answers.
- Can someone buy without registering
- Are Apple Pay and Google Pay visible before the card form
- Is the total with delivery shown as early as the basket
- Does a numeric keypad open on the card field
- Does the basket survive a failed payment
- Are a phone number and terms visible on the payment page
Questions about this
How long does it take to launch the plugin?
About an hour, including test transactions. With an approved account already in place you take real payments the same day.
Does it work with a multilingual or multi-currency shop?
Yes. We accept cards in the main European currencies and settle in euro to the company account. The payment page follows the shop's language.
What if the payment succeeds but the order is not recorded?
That is exactly what the webhook is for, and it is retried on failure. With correct handling the order closes itself once your server is back. It is one of the things we check during integration.
Can I take payment on social media too?
Yes, with a payment link sent in a message. It suits selling through Instagram or Facebook, where there is no basket.
Will I need PCI certification?
With a plugin or hosted checkout you fall under the lightest questionnaire, SAQ A. The heavy requirements apply only if you decide to accept card numbers directly on your own server, which almost no shop does.
How do I tell whether the problem is payment or something else?
By the payment success rate. If a high share of started payments complete but sales are low, the problem sits before payment: in the price, the delivery or the trust. If the rate is low, the problem is technical and shows in the decline codes.
Ready to start accepting payments?
Send us an enquiry and you will get a concrete quote with calculated fees for your business, usually within one business day.