What redirect payment flow means
In a redirect payment flow, OpenCart does not charge the card inside the store. The payment extension prepares the payment attempt and then transfers the customer to the secure Piraeus / Winbank ePay environment.
The store does not see card details and does not control the final bank payment UI. The bank shows the customer the amount, available payment options, and confirmation process according to the merchant's agreement.
Payment flow step by step
The basic flow has specific stages. The critical point is that OpenCart learns the result only when the bank correctly returns the confirmation data.
- 01
The customer is in checkout
The customer has products in the cart and is on the OpenCart checkout page.
- 02
The customer chooses card payment through Winbank ePay
The payment choice activates the extension that connects OpenCart with the ePay environment.
- 03
The extension requests a payment ticket
The extension communicates with Piraeus ePay and requests a ticket for the amount of this specific order.
- 04
Piraeus returns a reference
ePay returns a ticket or reference for this specific payment attempt.
- 05
OpenCart redirects the customer
When the customer completes the order, OpenCart transfers the customer to the secure bank environment with the ticket.
- 06
The customer is now outside the store
From this point, OpenCart does not know whether the customer will pay, cancel, fail, close the window, or abandon the process.
- 07
The bank shows the result
If the payment is completed or canceled, the result is shown inside the Piraeus / Winbank ePay environment.
- 08
Piraeus returns to the success URL
For the order to be updated, ePay must return the customer to the correct success URL and send the required POST data.
- 09
The extension checks the response
The extension reads the POST data, checks whether it is valid, and decides whether the order status should be updated.
- 10
The order is updated or remains open
If the response is valid and successful, the order is updated. If there is no valid return, OpenCart should not automatically assume that the payment was completed.
Payment flow diagram
This diagram shows which system controls each stage of the redirect payment.
- 01 Customer
Chooses card payment
The customer selects Winbank ePay in OpenCart checkout.
- 02 OpenCart Checkout
Requests payment preparation
The checkout calls the payment extension to prepare the payment attempt.
- 03 Winbank ePay Extension
Sends amount and order data
The extension sends the data required by ePay to create the ticket.
- 04 Piraeus / Winbank ePay
Returns payment ticket
The bank returns a reference for this specific attempt.
- 05 Customer
Confirms order completion
The customer confirms that they want to continue to payment.
- 06 OpenCart Checkout
Redirects with the ticket
The store transfers the customer to the bank environment.
- 07 Piraeus / Winbank ePay
Displays the payment page
The customer sees the amount, available options, and confirmation steps at the bank.
- 08 Customer
Completes or cancels
The customer pays, cancels, fails, or abandons the process.
- 09 Piraeus / Winbank ePay
Returns to the success URL
ePay must return the customer and POST data to the correct store URL.
- 10 Winbank ePay Extension
Checks the POST data
The extension updates the order only when it receives valid confirmation.
- 11 OpenCart
Shows success or returns to cart
If confirmation is valid, the customer sees the success page. If not, the order should not be changed arbitrarily.
Possible outcomes after the redirect
The same initial payment attempt can lead to different order visibility in OpenCart depending on whether the bank response returns correctly.
The order is updated
ePay sends a valid POST to the success URL and the extension changes the order status according to the result.
The order does not change
If POST data is missing or cannot be verified, the extension should ignore the request.
It may remain a missing order
If the customer closes the window or does not return correctly, OpenCart may not receive a result and manual checking is needed.
Why missing orders appear in OpenCart
OpenCart may create or hold the order temporarily before payment is confirmed. This allows checkout to have an order reference while the customer is transferred to the bank.
If the customer leaves for ePay but does not return correctly to the store, OpenCart does not receive the final confirmation and cannot reliably change the order status.
- The order may exist in the database.
- It does not necessarily mean the customer paid.
- It does not necessarily mean the payment failed.
- It means the store did not receive the final valid confirmation.
- The administrator must check the ePay environment or the bank confirmation email.
Why the store does not always know the payment result
After the redirect, the customer is in the bank environment. OpenCart is no longer running the payment process and has no access to what the customer does there.
If the return to the success URL does not happen correctly, the store does not receive the POST request with the result. In that case, it cannot automatically know whether the payment was completed, canceled, or abandoned.
What the success URL is and why it matters
The success URL is the OpenCart address where Piraeus returns after the payment process. ePay sends the response data there so the extension can check the result.
If the URL is wrong or a technical layer changes the request, OpenCart may not receive the confirmation correctly even when the customer completed the process at the bank.
- The success URL must be the correct live URL of the store.
- It must accept POST requests without losing data.
- It must use a valid SSL certificate.
- The payment callback or success route must not be cached.
- Redirects from HTTP to HTTPS, non-www to www, or another canonical path can break the return if they lose POST data.
Demo and live environments
Piraeus usually requests test payments in the demo environment to confirm that the flow works correctly. When live credentials are provided, the technical flow remains the same, but the live URLs must be registered correctly.
Problems often appear when moving from demo to live changes the domain, credentials, or routing without the ePay environment being updated accordingly.
- Demo URLs may still be registered in the live environment.
- The live domain may be different from the demo domain.
- The store may have changed domain or checkout route.
- A new firewall, cache, CDN, or redirect rule may block the return.
- The success URL may not accept POST requests correctly.
Can a double payment happen?
In a normal flow, one payment attempt corresponds to one specific ticket or reference and one specific amount shown in the Piraeus environment.
The extension does not charge cards directly. The final charge happens in the bank environment after the customer sees and confirms the amount.
It is not accurate to say that a double payment can never happen. If the customer starts two separate orders or two separate payment attempts, there may be two separate transaction attempts because they are different processes.
- For each attempt, the customer sees the amount at Piraeus before confirming.
- OpenCart cannot charge a card without the process being completed in ePay.
- If there is any doubt, the administrator checks the ePay admin or the bank confirmation email.
What to check when the order is not updated
When a payment exists at the bank but the order does not look completed in OpenCart, checks should be done in order.
- Check whether there is a successful transaction in the ePay admin.
- Check the Piraeus confirmation email.
- Check whether the order exists in OpenCart as a missing order or without status.
- Check whether the success URL is correct.
- Check whether the POST request reaches the store.
- Check extension logs, if available.
- Check server error logs.
- Check whether firewall, CDN, Cloudflare rule, ModSecurity, or security extension blocks the request.
- Check whether there is a redirect from HTTP to HTTPS, non-www to www, or another canonical redirect that loses POST data.
- Run a new demo payment with the official Piraeus demo credentials.
- If URLs or domain changed, ask the bank to confirm that they have been updated correctly.
Short explanation for clients
With Winbank ePay payments, the customer is transferred from OpenCart to the secure Piraeus environment to complete payment. While the customer is there, the store does not yet know whether payment was completed. The order is updated only when Piraeus returns the customer to the correct success URL and sends the required confirmation data. If the customer closes the window or does not return correctly to the store, the payment may have been made, but OpenCart may not receive the confirmation. In that case, the ePay environment or the bank confirmation emails must be checked manually.
Technical terms in plain language
- Redirect
- The transfer of the customer from OpenCart to the secure bank environment.
- Payment ticket
- The reference that corresponds to one specific payment attempt.
- POST request
- The way ePay sends result data back to OpenCart.
- Success URL
- The store URL where the bank returns after the payment process.
- Callback / return URL
- A general term for the URL that receives the return or notification from the payment gateway.
- Missing order
- An order that exists in OpenCart but has not received a final valid status update.
- Order status
- The order state, such as successful, pending, canceled, or without final update.
- Demo credentials
- Test credentials used to check the flow without live production operation.
- Live credentials
- Production credentials used by the real store.
Important security note
The payment extension must not change the order status unless it receives a valid response from ePay. If someone calls the success URL directly without correct POST data, the extension should ignore the request and must not update any order.
Winbank ePay and missing orders FAQ
Why does the order appear as a missing order?
Usually because OpenCart created or held the order before receiving final valid confirmation from ePay.
Does that mean the customer paid?
Not necessarily. The ePay admin or the bank confirmation email must be checked.
Does that mean the payment failed?
Not necessarily. OpenCart may simply not have received the bank return correctly.
Why was OpenCart not updated?
The return to the success URL may not have worked correctly, or the POST request may have been lost because of wrong URL, SSL, cache, firewall, redirect, or server error.
What happens if the customer closes the window after payment?
The payment may have been completed at the bank, but OpenCart may not receive the confirmation. Manual checking is required.
Who controls the payment page?
The final payment page is controlled by Piraeus / Winbank ePay, not by OpenCart or the extension.
Can the extension see card details?
No. Card details are entered in the secure bank environment.
Can a double charge happen?
In a normal flow, one payment attempt has one specific ticket and amount. Two separate attempts or orders may create separate transactions, so the ePay admin should be checked.
What should I do if payment exists in Piraeus but there is no completed OpenCart order?
Check the transaction in ePay admin, confirmation emails, extension logs, and whether the success URL accepts POST requests correctly.
When should demo payments be repeated?
After changing domain, checkout route, payment extension, credentials, SSL, firewall, CDN, cache, or redirect rules.