Start by deciding what not to build
“Creating” a payment system rarely means writing one from scratch. Handling card data directly is demanding, regulated and a magnet for attackers, so most small and mid-sized merchants are better served by connecting their site to a regulated payment service and keeping as little sensitive data as possible on their own systems. The security goal is usually to reduce what you hold, not to defend it more heroically.
This guide describes general good practice. It is not legal, compliance or security advice, and requirements depend on your country, your payment partners and the card network rules that apply to you.
The building blocks
A typical online checkout has these parts:
- The storefront or checkout page, where the customer enters details.
- A payment gateway or processor, which sends the transaction for authorization.
- A merchant account or equivalent arrangement, through which funds are settled to you.
- Your own order system, which records what was bought and what was paid.
- Fraud controls and monitoring, which flag suspicious activity.
Each connection between these is a place where something can go wrong, so each deserves a deliberate choice rather than a default.
Keep card data out of your systems
The single most useful design choice is to avoid touching raw card numbers. Two common approaches do this:
- Hosted payment pages. The customer is sent to, or shown a form served by, the payment service. Card details go directly to that provider and never pass through your server.
- Tokenization. The provider returns a token, a stand-in value, for a card. You store the token if you need repeat billing, not the card number. The same idea underlies digital wallets.
Either way, never store the card security code after a transaction is authorized, and avoid keeping full card numbers unless you have a clear need and the controls to protect them. Industry rules for handling card data, known as PCI DSS, set expectations for merchants, and the burden generally gets lighter the less data you handle. Ask your provider which level and self-assessment applies to you.
Protect data in transit
Serve every page of your site, not just the checkout, over HTTPS so that data is encrypted between the customer’s browser and your server. Keep your certificates valid and renewed, and use current, supported versions of the encryption protocol. Mixed content, where a secure page loads scripts from insecure sources, can undermine this, and third-party scripts on payment pages are a known risk. Keep them to the minimum you truly need.
Add checks that fit the risk
Card payments online carry a higher fraud risk because the card is not physically present. Common layers include:
- Address and security code checks, which compare what the customer typed with what the issuer has on file.
- Extra cardholder authentication, often a step where the customer confirms the payment with their bank. This can shift some liability and reduce fraud, but may add friction.
- Velocity and pattern rules, such as flagging many attempts from one device or unusually large first orders.
- Manual review for orders that look odd, such as mismatched billing and shipping details with a high value.
Every extra check can turn away legitimate customers, so it is worth watching your conversion rate and cart abandonment alongside fraud numbers. Too little screening leads to losses and disputes; too much costs sales.
Secure your own accounts and systems
Many payment incidents start with a compromised login, not a clever attack on the payment network.
- Use unique, strong credentials for your payment dashboard and require two-factor authentication on every account that can view or move money.
- Limit access by role. Staff who only fulfill orders do not need refund powers or full data exports.
- Keep your e-commerce software, plugins and server up to date, since software updates close known weaknesses.
- Back up data and test restoring it, following a backup strategy you trust.
- Remove access promptly when staff or contractors leave.
- Log administrative actions and review unusual activity.
Shop owners should also keep in mind that attackers often go after business email, so invoice fraud and phishing emails aimed at staff are relevant to payment security too.
Choose and check your providers
You rely on third parties for the core of your checkout, so third-party risk is part of the design. Look for:
- Clear documentation of what data they handle and where it goes.
- Stated compliance with the relevant industry standards.
- Straightforward fee, settlement and dispute terms.
- A support route for security problems.
- A way to export your data if you switch.
Read the contract terms on liability and on holds or reserves that may apply to new merchants.
Plan for disputes and refunds
Make your return policy easy to find and write your business name on statements so customers recognize charges. Keep order records, delivery proof and customer messages, because they help if a card chargeback is filed. Handle refunds through your payment service back to the original method, not by sending money some other way.
Prepare for the day something goes wrong
Decide in advance who to contact if you suspect a breach: your payment provider, your technical support, and possibly regulators or customers, depending on local rules. Having an incident response plan in place is much easier than writing one under pressure. Knowing how data breaches typically unfold helps you decide what to prepare.
Test before launch
Use your provider’s test mode to run through successful, declined and refunded payments. Check receipts and confirmation emails, test on a phone, and confirm that failed payments produce a clear message rather than a blank page. Then review the setup periodically; threats, plugins and rules all change.
No setup removes risk entirely. The aim is a sensible, layered approach that keeps sensitive data away from your own servers and limits the damage if something fails.