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. Behavioral changes 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 are not to be captured on a recording.

Credit card details are contributor PII that is NEVER to be recorded or asked for.

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 neither require integration with a back-end system nor impact your 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 have already built out a functional design, 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 that has an address and payment information already saved, and have the contributor log in to that account. 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 the chat feature in your web conference tool to share the details.

Lastly, you can suppress error-checking and enable contributors to enter fake information. If you can’t—or don’t want to—suppress error-checking, you'd still want to provide the fake information the contributors should enter; asking contributors to fabricate 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, so the contributor does not have to enter any information. This is a good solution because you can set up this account in the back end to cancel or put on hold an order so that actual payment systems and inventory are not affected.

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

Lastly, provide any details, such as login credentials, 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 a better path for the team to take since using a gift card/code makes it easier to reconcile charges, and avoids having to provide company credit card details.

Have separate cards or codes for each contributor. This ensures 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. How to Launch a Prototype Test Prototype Testing with InVision Understanding Personally Identifiable Information (PII) Want to learn more about this topic? Check out our University courses. How to Test Purchase Transactions