In the planning stage it seems obvious that when a customer clicks on Place Order/Submit/Proceed Payment/Whatever-it’s-called button it should result in immediate Thank you/Order success page. And the only thing left is for your customer support managers to take care of the order. Let’s not assume all is good and well, just because we’ve seen that infamous success page.

In the intense world of E-commerce web development, each online checkout process should pass a thorough QA check of engineers who will not let even the slightest bug pass unnoticed.

So, what are the possible outcomes in the checkout process on Magento?

And, a quick note: the article will be helpful for ecommerce QA engineers and those who know the specifics of Magento checkout. If you are new to Magento, you can start with reading our another article on Magento 2 checkout and official user guide, and then get back to this material.

Successful checkout

Let’s imagine you took into account all the tips on making the checkout experience better, the order was accepted and a Thank you\Success page appeared just as planned. Let’s look through all the possible variants in the checkout process in Magento and what to look out for when going through all the steps:

Scenario 1: Checkout as a Guest

checkout as guest photo










Here are some issues you have to pay special attention after the checkout is completed:

  • The Thank you page/Success page opens informing the customer that the order was successfully created, and diplays the order number.
  • There are no products left in the customer’s Shopping Cart.
    NOTE! We musn’t forget to check both the Shopping Cart page and the Shopping Cart popup in the header to make sure there are no leftovers.
  • The order was created in the admin panel (Sales => Orders) note it and check that all the information specified at checkout has been saved, and is now displayed properly as well made available for the admin to edit.
  • The customer (you) got an Order Confirmation email containing the order number, and all the data specified at checkout.
    NOTE! If the email wasn’t received – there’s no need to report a bug immediately. In some cases emails are sent in accordance with Cron settings. Clarify this with a project manager and/or a developer. If the email hasn’t been received for a long time, it’s time to report a bug.
  • Activate the option of CC’ing the website admin. To test this functionality, enter your email address in System => Configuration => Sales => Sales Emails tab => Order => Send Order Email Copy To field (in Magento 1). In Magento 2 this path starts with choosing Stores in the side menu.
  • NOTE! After testing of the live site is complete, it’s imperative(!) that the website owner’s/admin’s email address be put back in the system configuration. The ideal solution is to enter your email address in addition to the admin email address separated by a comma.

Scenario 2: Checkout as a registered user

Here is also a bunch of issues you have to check to ensure that registered user correctly placed the order, and there are no interruptions in the order processing workflow. 

  • Verify the login when checking out as a registered user besides the purchase check only. If there were some products in the Shopping Cart of the already registered customer – they also have to be added to the order.
  • After order placement the Thank You page opened. An order number for an authorized user is concurrently a link to View Order details in a customer account (My Account). It’s obligatory to click this link!

thank you page magento 2 photo












  • There are no products left in the customer’s Shopping Cart.
  • The order has been created in the admin panel. All the data is saved and displayed properly.
  • A Confirmation Email is received by the customer.
  • The website admin received a copy of the Confirmation Email (if this option is preselected in the settings).

Registration during the checkout

The workflow of registration during the checkout in Magento 1 and Magento 2 differs a lot. In the first case, you are offered to select one of the options: proceed as a guest, login or create an account. With Magento 2, it is considered right away that you want to checkout as a guest and only after placing an order you have an option to create an account. 

Anyway, there are also several issues you have to thoroughly check after placing an order regardless the version of the platform:

  • The Thank You page opened. The order number is a link to order details in customer’s account.
  • The customer is registered and is able to enter My Account without a preliminary log-in.
  • There are no products left in the customer’s Shopping Cart.

Registration during the checkout photo

  • The order has been created in the admin panel. All data is saved and displayed properly.
  • A Confirmation Email is received by the customer.
  • The website admin received a copy of the Confirmation Email (if this option is preselected in the settings).

Checkout with the redirect to external payment systems pages

It’s not a rear case that after clicking the Place Order button at the payment step your customers are redirected to the payment system’s page where they have to enter their card details and/or login to their account for making payments (for instance, PayPal).

After successful payment the customer then sees the Thank You page of the seller’s website. Further testing is performed in accordance with all the above listed steps.

Actual Result. Examples of imperfection

According to testing premises, a bug is defined as a discrepancy between the actual and expected results; that is, any deviation from the above listed points has to be reported as a bug.

The examples of deviations below were the most impressive ones that our QA team has encountered. 

After getting to Payment System’s page an error is displayed

A Barclay Card was used as a payment method which is not a default Magento payment method. To make it work we installed an external module Barclays Payment Gateway. The error had nothing to do with Magento, but after getting back to the website, an empty Shopping Cart page opened.

Therefore, the customer would have to essentially start their buying and shopping experience all over again, from scratch. Of course, in this example, the customer would have to start shopping all over again. In reality, if the product isn’t one of a kind, the customer will leave the website to buy it somewhere else as a result of a poor customer experience.

The same is true for address errors, etc., that don’t allow a customer to proceed and pay with PayPal (the system blocks a payment, until the customer corrects all the errors they made while filling in checkout forms). Usually, the customer is redirected to the checkout page.

A customer got back to the site without paying for an order

Let’s say after getting to the payment page, the customer needs to add some more products to the Shopping Cart, or remove/replace some of the already chosen ones. The easiest way to return is to click the “Back” button on your browser.

However, for increased customer experience, the best solution would be to create a button to redirect customers to the Shopping Cart page, where they are able to proceed purchasing necessary products using “Continue Shopping”, or “Edit/Delete Product” functionalities.

If you are being redirected to any other page (Homepage, Category Page, My Account. etc.) – it’s more like a usability issue, not a bug. You should report this but note that it’s not critical to do so.

NOTE! You need to check that all the products are still in the Shopping Cart so that users won’t need to look for them again. It’s a critical point to address to ensure that users aren’t redirected to an empty Shopping Cart page, or any other page, where the Shopping Cart is empty.

Payment failed on the payment system’s page

For instance, a message may suggest that a user’s account has insufficient funds to process the order. In this case all the above listed steps are applicable.

Despite successful payment, an order wasn’t created in the admin panel

That same Barclays Gateway extension, but after some fixes made.

    • Payment was successful.
    • Correct order amount of money was written off the user’s credit card.
    • The money was received by the seller.

BUT! Order in the admin panel wasn’t created. That means the customer was left with neither money or their order, and the seller isn’t aware of what’s happening.

What’s our point? Our point is that developers and QA engineers can’t be responsible for the quality of other systems, modules, code, etc but must ensure that there are no issues with the website we created. In this case all bugs have to be fixed by third-party code authors.

And finally, an experience as a buyer, not as a seller.

So, these were the major tips on what to consider when testing the order process, hopefully you won’t encounter any of the issues while testing. But we all know the ugly truth – it’s almost zero chance. Check it thoroughly.