Security on a payment page works in two directions at once. One is technical. Can card data leak, can a stolen card get through, can anyone tamper with the amount? The other is perceived: whether the buyer believes the page is safe enough to type a card number into. Shops tend to invest heavily in the first and ignore the second. Then they wonder why the checkout loses people.
Both matter, and they are not the same work.
Where card data should live
The single biggest decision is whether card numbers touch your servers at all. If the payment form is hosted by the provider, they do not, and your compliance burden shrinks to almost nothing. If the form sits in your checkout, it does, and the requirements grow accordingly.
There is a middle path that most shops end up on. The form looks like part of your page, yet the fields themselves belong to the provider. The buyer sees one seamless checkout while the sensitive data never reaches you. How this is set up sits in our processing documentation.
Whichever you pick, decide it before building rather than after. Moving from one model to another means rewriting the checkout.
Authentication without killing conversion
European rules require strong customer authentication for most online payments. Exemptions exist for low-value and low-risk transactions. Whether your provider uses those exemptions decides how often buyers get interrupted by a banking app.
Applying authentication to everything is the lazy setting. It protects the provider and shifts liability away from you. However, it costs conversion on every order, including ten-euro ones with no material risk. A risk-based setup authenticates where the signals justify it and lets the rest through. That is better for everyone except the person configuring it.
What the buyer actually notices
Perceived safety is built from small, boring details. The padlock and the domain name are the obvious ones. Yet the things that move conversion sit elsewhere.
Buyers look for the price in their own currency and a delivery date. They also want a visible refund policy and a contact that looks human. They notice when the checkout jumps to an unfamiliar domain and back. Equally, they notice when the page design changes mid-flow. None of that is security in the technical sense. Still, all of it answers one question: will I get my money back if something goes wrong?
Which payment methods you offer feeds into this too. A familiar method is itself a trust signal, while its absence reads as a warning.
What breaks silently
Three technical mistakes show up repeatedly, and none of them announce themselves.
The amount is decided in the browser. If the checkout sends a price the page calculated, someone will eventually change it before it is sent. Prices belong on the server, and the server confirms what was actually charged.
Notifications are trusted without verification. A payment confirmation arriving at your endpoint has to be verified as genuine. Otherwise anyone who learns the address can mark orders as paid.
Refunds are available to everyone with admin access. This becomes a problem exactly once, and the loss is whatever the person decided to refund to themselves.
What to check after launch
Security settings drift because nobody owns them after the project ends. Three checks, done quarterly, cover most of the risk.
Look at how many payments required authentication and how many were abandoned. A rising abandonment rate usually means the rules got stricter without anyone deciding so. Look at who still has refund rights in the admin panel, since access tends to accumulate. And look at whether the refund and delivery texts still match what the business actually does. That is the first thing a bank reads during a dispute.
If you also send money out, the same discipline applies to payouts. Approval rights there deserve the same quarterly glance.
Questions that come up repeatedly are collected in our FAQ.
What to ask before signing
Ask who holds the card data and under which certification. Ask whether authentication is applied by rule or blanket. Ask how webhook authenticity is verified, since the answer tells you how seriously they take integration security. And ask what the buyer sees during authentication. That screen belongs to your brand experience whether you designed it or not.
Our side of the review is on the merchant accounts page, including what the acquirer checks on your site. The account opens from 5 days once documents are complete.
Rates for middle-risk retail start from 1.8%, with the structure on the pricing page.
The order of steps is set out on how it works.
If you remember one thing from all this, let it be the order. Decide where card data lives before anything else gets built. After all, every other choice depends on that one. Everything afterwards — authentication rules, trust signals, access rights — can be adjusted later without touching the checkout.
Connection from 5 days. Fees from 1.8% — transparent terms, no hidden charges. Leave a request or book a consultation. We will put together the right setup for your niche and risk profile.
Read next
- How to Choose the Best Crypto Payment Gateway for Your Online Business
- SaaS Payment Gateway: What a Shop Gateway Cannot Do for You
- Gambling Payment Gateway
- How To Tell Whether The Website’s Connection Is Secure
- Ecommerce Payment Integration: The Order of Work That Saves Weeks
- Recurring Billing for Business: Setup, Costs and What Breaks