How to Test Purchase Transactions


At a Glance

This article discusses how to test purchase transactions without asking contributors to spend their own money. We’ll first address challenges when testing purchase transactions, then explore how to overcome those challenges.


Testing purchase transactions provides you with valuable insight into a customer’s full transaction journey. You can test these kinds of transactions with UserTesting.

When collecting feedback on these experiences, it is important to remember that you can’t have contributors pay with their own money. Behavior changes due to anxiety may arise if contributors believe their own money is at risk during a test. 

Also, credit card numbers are Sensitive Personally Identifiable Information (PII) and cannot be captured on a recording.


One type of PII to never use is a contributor’s credit card information


Image description: Person holding a credit card while at a laptop.

Here are five ways to overcome these challenges when testing purchase transactions:

Use Prototype Designs

The first solution is to use prototype designs. 

Prototypes make it easy to get feedback on your page designs without the risk of recording the contributor’s address or credit card number. 

Prototypes don’t require integration with a back-end system and don’t impact your real data. You can even force error messages and get feedback, whereas with live designs, contributors might not encounter those messages. 

Even if the prototypes aren’t interactive, you can show the first purchase page to the contributor and have them explain the elements on the page. Then repeat that process with each subsequent page in the purchasing process.

Use a Test Environment 

The second solution is to use a test environment. 

If you already have functional designs built out, provide contributors a link to a staging (or test) environment where they can enter the login credentials you provide. 

In the test environment, create an account with saved address and payment information that the contributor can log in to. Or provide the details the contributor should enter—name, address, credit card details—in the text of your task so that they can simply copy the information. 

If you are moderating the test, use chat in your web conference tool to share the details.

Lastly, you can suppress error checking and enable contributors to enter completely fake information. If you can’t—or don’t want to—suppress error checking, then provide the fake information the contributors should enter. Asking contributors to make up fake information on their own can lead to confusion and error messages.

Use a Live Site Until Checkout

When testing in a live environment, test to the point of checkout.

Provide contributors the goal of finding a product and adding it to their cart, but instruct them to stop before entering any information on the checkout pages.

This works well for projects where contributors are evaluating the steps of finding products, reviewing product details, comparing products, and adding them to the cart.

However, it doesn’t allow you to collect feedback on messaging during checkout and post-checkout.

Provide an Account 

Alternatively, on a live site, provide the information for the contributor to enter. This is similar to pointing the contributor to the staging environment (see above).

Before launching the test, set up an account the contributor can log in to, with address and payment information already saved. This is a good solution because you can set up this account in the back end to cancel or put on hold any order, so that actual payment systems and inventory are not affected.

Or provide the name, address, credit card, along with other details the contributor should enter so that they can simply copy the information. This can be fake information or real information that sends the product to your office and charges a company credit card.

As mentioned above, in an unmoderated test, provide this in the text of the task. In a moderated session, use chat in your web conference tool to share the details.

Lastly, provide any details, such as login credentials or purchasing details, at the point in the test when the contributor needs that information. Don’t expect contributors to remember these details from the beginning of the test.

Use a Gift Code or Gift Card

One last solution to testing purchase transactions on a live site is to provide a gift code or gift card for the purchase.

Follow the same guidelines as when providing the contributor the details to enter, but provide the gift code or gift card details, rather than credit card details. This may be an easier path for the team, because it simplifies the reconciling of charges and prevents providing company credit card details.

Have separate cards or codes for each contributor. This will ensure each contributor has the correct balance for the purchase.

  • One approach is to run a separate test for each contributor, changing the details in each test.
  • Another approach is to launch the test to one contributor at a time (or run individual live sessions with each contributor).

A final consideration is to provide clear instructions to the contributor about the amount available on the gift card. Tell the contributor an amount that is slightly lower than what is actually available, to account for taxes, shipping, or other fees.

For a deeper dive into testing purchase transactions and example task wording, see our course How to Test Purchase Transactions.


Learn More

Need more information? Read these related articles.

Want to learn more about this topic? Check out our University courses.

Was this article helpful?
0 out of 0 found this helpful