Card payments in your online store: what to know before launch

In short

• The customer enters the card details on the payment processor's page, not on the store's server.
• In the European Union, online payments usually require strong authentication: 3-D Secure, with a confirmation in the bank's app.
• The order is confirmed after the processor reports the payment, not when the customer reaches the “thank you” page.
• The total is calculated on the server, from your prices, not from what the browser sends.
• Before launch, you test with the processor's test cards.

Who does what

• The store holds the products, prices, cart and orders.
• The payment processor (for example Stripe or a bank's processor) receives the card details, talks to the bank and transfers the money to you.
• The customer's bank approves or declines the payment and asks for authentication.
• The invoicing software issues the invoice and, for stores in Romania, submits it to RO e-Factura (the Romanian national e-invoicing system).

The safest setup is for card details never to pass through your server at all: the customer is sent to the processor's secure page, or fills in a field loaded directly from the processor. That way the store neither stores nor sees the card number, and most of the security obligations for card data stay with the processor.

3-D Secure and strong authentication

The European Payment Services Directive (PSD2) requires strong customer authentication for most online payments: on top of the card details, one more confirmation, usually in the bank's app or with a code sent to the customer's phone. For cards, this is done through 3-D Secure.

For the store, two things matter: the payment flow must support 3-D Secure, and a payment still waiting for confirmation must not be treated as paid.

The order is confirmed when the payment arrives

The “thank you” page the customer lands on after paying is not proof of payment: the customer may close the window before reaching it, and the page's address can be opened without paying. The right way is for the processor to notify the store's server, through an automatic notification (webhook), that the payment went through. Only then does the order become paid, the confirmation email go out and the invoice get issued.

The price is calculated on the server

The customer's browser can be modified by anyone who knows a little programming. That's why the store must not accept the price or total sent from the cart: it receives only which products and what quantities the customer wants, and calculates the total on the server, from its own price list. The price on the page is for display only.

Testing before launch

Processors have a test mode, with separate keys and test cards published in their documentation. Try at least:

• a successful payment;
• a payment that requires 3-D Secure;
• a declined card;
• a card with insufficient funds;
• a payment abandoned halfway: the cart must stay, and the order must not show as paid.

After each test, check the order status in the store, the email the customer received, the invoice and what the processor shows in its dashboard.

What stays your responsibility

• The processor's keys live only on the server, in a file visitors cannot read, and are never sent by email or chat. If a key ends up somewhere it shouldn't, you change it from the processor's dashboard.
• The SSL certificate must be active across the whole website (here's why).
• Refunds and returns also go through the processor, and the credit note through the invoicing software.
• Processor fees vary from one provider to another; factor them into your prices.

The rest of the pre-launch steps for stores in Romania — legal pages, SAL, e-Factura — are in the launch checklist for an online store. For hosting, stores start from the Store plan, with 3 websites, 30 GB and unlimited email (web hosting).