Card payments in Greek e-shops: where the bank redirect breaks
Most Greek e-shops take cards through a redirect: the customer leaves the store for a payment page run by the acquiring bank or a payment provider, passes 3-D Secure in their own bank’s app, and comes back. Every hop is a place where an order can be lost, and most of them fail silently.
The round trip
The store creates an order (pending payment in WooCommerce and Magento) and sends the customer to the payment page with the amount and an order reference. The customer enters the card, approves 3-D Secure in the bank app, and the payment page sends them back to a return URL on the store. Separately, the provider sends a server-to-server notification that the store uses to confirm the payment.
The plugin or module from the provider, or a third-party one, handles both ends. A change on either side, store or provider, can break one leg while the rest looks fine.
Where it breaks
The redirect itself: the payment page rejects the request because the merchant ID, shared secret or allowed return URL does not match, often after moving to a new domain or switching from test to live credentials. The customer sees an error on the bank’s page, not on yours.
The return: the customer comes back with a POST from the provider’s domain, and a session cookie with strict SameSite rules is not sent, so the store shows an empty cart or a login page although the payment succeeded. Page caching or a firewall on the return URL has the same effect.
The notification: it is blocked by a firewall or bot rule, points to an old URL, or fails signature checks, so the order stays pending although the money was taken. Customers then write in asking where their order is.
Installments, amounts and currency
Installment options are passed with the request and limited by the merchant agreement; a plugin setting that offers more installments than the agreement allows can make the payment page reject the request for some baskets only. Amounts must be sent in the format the provider expects, and rounding of VAT-inclusive prices can produce a mismatch on specific totals.
How to test it
Use the provider’s test environment and test cards for every change, then one small real payment with a real card after going live, refunded the same day. Watch the share of orders left in pending payment and compare paid transactions in the provider’s dashboard with orders in the store. A failing payment gateway and Magento orders stuck in pending payment cover each platform in depth.
An outside check that reaches the payment page on a schedule tells you when the redirect breaks. The free WooCommerce checkout checker and Magento checkout test walk the checkout up to that point in a real browser.
Common questions
Why does the customer see an empty cart after paying?
The return from the payment page did not carry the store session, often because of SameSite cookie settings, caching or a firewall on the return URL. Check whether the payment went through in the provider’s dashboard.
Why was the card charged but the order is still pending?
The provider’s server-to-server notification did not reach the store or failed its checks. Look at the callback URL, firewall rules and the plugin’s log.
How can I test card payments without charging customers?
Use the provider’s test environment and test cards for changes, and after going live make one small real payment yourself and refund it.