Ecommerce purchase-path audit

The store runs faultlessly and still nobody can pay in it.

An ecommerce audit focused on the cart, checkout and purchase path. I walk the store the way a customer does, from the homepage to payment selection. Every finding includes evidence, an address and instructions you can use to verify it yourself.

  • Evidence on every finding
  • No orders placed
  • A walkthrough, not a scan
An audit findingformat example

Same checkout, same cart, only the currency changed.

PLN2payment methods
EUR1payment method

The store had zero minutes of downtime during that period.

What a finding looks like

Not a sentence about a problem. The address where you will see it.

Below is the format every finding arrives in. The mechanism is real and comes from an audit that was carried out; the store name is withheld.

Finding

Selecting euro removes the only instant payment method from checkout

How it should be

2payment methods

The same number of payment methods regardless of the selected currency.

How it is

1payment method

After switching to euro, the gateway handling cards and instant transfers disappears from the list. A bank transfer is what remains.

How it was measured

An A/B test inside one browser session, same product in the cart, same checkout address. The only variable was currency. Checked against two delivery countries to rule out the country being the cause: under PLN the gateway is available even for delivery abroad, and under euro it disappears even for domestic delivery. The lists were read from the expanded select, not from its collapsed label.

What it costs

The store sold abroad, had a second language and a euro price list. Every customer who chose euro reached the final step and was offered an international bank transfer and nothing else. The availability statistic read one hundred percent throughout.

Check it yourself

  1. 1Put anything in the cart and open checkout.
  2. 2Expand the payment method list and count the entries.
  3. 3Switch the store currency in the header to euro.
  4. 4Go back to checkout, expand the list again and count once more.

How it differs

Four things you already have, and the question none of them answers

A purchase path audit replaces none of the below. It occupies the space none of them covers.

ToolWhat it answersWhat it will not see
Uptime monitoringWhether the server respondsA store at one hundred percent uptime where nobody can pay in euro
Free site auditWhich pages return an errorA store where every page returns a 200 and checkout still cannot be completed
PageSpeed, LighthouseHow fast the page paintsThree different totals for the same order on one screen
UX audits, A/B testingWhich layout wins on your trafficA failure affecting a segment too small for a test to ever reach significance

Evidence discipline

A hypothesis without evidence does not enter the report

The most expensive thing in an audit is not a missed finding. It is a false one: the client pays a developer to fix something that worked, and stops trusting the rest of the document.

19

findings in the report

each with evidence, an address and a way to check it yourself

9

hypotheses rejected

checked, refuted, never entered the report

3

would have been critical errors

they would have shipped as urgent failures had nobody verified them

The numbers come from one audit that was carried out and describe that audit, not an average across many.

Three hypotheses that looked like critical failures and were not

  • The terms and returns policy are missing in the English version

    Every document existed and was translated. The error was in my search pattern, not in the store.

  • The pickup point widget does not open at all

    The widget worked perfectly, with a map, search and filters. I measured the element height at the wrong moment and got seventeen pixels.

  • The listing price disagrees with the product page price

    It was the regular price struck through next to the promotional one. Consistent everywhere, confirmed in the page's structured data.

What you get

Three documents, because three different people read them

For you

Owner's report

Ordered by what each item costs rather than by audit phase. It opens with the answer to your question and closes with a repair order. No jargon, with pictures.

For your developer

Technical protocol

Reproduction steps, addresses, module names, response fragments. Everything a developer needs to see the failure on their own machine in fifteen minutes, without asking you anything.

For whatever system you work in

Task list

An importable file: one finding, one row, priority, owner, closing criterion. So the report does not end its life as a PDF attachment.

The process

How it runs

  1. 01

    Call and scope

    We establish what worries you, which markets you serve and whether the store has a B2B path. I ask for analytics access if you have it, because without it I can say something is broken but not how many customers it affects.

  2. 02

    The walkthrough

    I walk the store manually in four language and currency combinations, on desktop and on a phone. Every step is recorded and captured so a finding can be reproduced later.

  3. 03

    Verification

    Every hypothesis is checked separately, isolating one variable at a time. Anything I cannot confirm twice does not enter the report.

  4. 04

    Handover

    Three documents and an hour with you and your developer, walking the list and setting the order. After the fixes, an optional control pass.

No orders placed

The audit stops at the payment method selection screen. I do not finalise a payment, leave orders for you to cancel or fill your database with test accounts. If a finding needs the path taken further, we agree that separately and run it on your staging environment.

Honestly

What the audit will not do

These limits are real and I state them before signing, not in the report.

It cannot size anything without analytics access
Without access to your analytics I can name the mechanism and show the evidence, but not count how many customers it touches. That is the difference between a defect list and a priority list, which is why I ask for that access up front.
This is not a security test
I do not hunt for vulnerabilities, attempt to bypass authentication or test resilience under load. I check the purchase path the way a customer walks it.
This is not a redesign
You get a list of things that are broken or misleading, with the reasoning. You do not get mockups or a proposal to rebuild the store.
Your developer does the fixing
The report is written so it can be handed to an agency without translation. I do not go into your store's code myself.

Scope

Three scopes

Choose a standard scope and send the store URL. After a short call, we confirm the delivery date, access and fixed price in writing.

Basic

One market, one currency, guest path

PLN 1,900 net

  • Walkthrough from the homepage to the payment screen
  • Desktop and phone
  • Cart, checkout, delivery, payments
  • Owner's report and technical protocol
Send your store for an audit

Full

Full scope

Four language and currency combinations, guest and logged-in path

PLN 4,900 net

  • Everything in the basic scope
  • Four language and currency combinations
  • Logged-in B2B path, with a VAT number
  • Search, consent and legal documents in both languages
  • Importable task list
  • An hour of handover with you and your developer
Send your store for an audit

Control and activation

After the fixes: verification and a bridge to continuous monitoring

PLN 1,200 net

  • The same checks repeated
  • Status per finding: fixed, partial, unchanged
  • New findings, if a fix introduced a regression
  • Setup or import of one agreed checkout scenario
  • 30 days of Professional with no automatic renewal
Send your store for an audit

After the audit

You fixed eight things. Who tells you when one of them comes back?

Purchase path failures return because their causes return: a module update, a change in payment configuration, a new template version. Classic monitoring will not catch it, because the pages still respond correctly. Synthetic monitoring walks a recorded cart scenario in a real browser on a schedule and reports the exact step where it stopped.

See checkout monitoring

Common questions

What do you need from me to start?

The store address and permission to walk the purchase path. To size findings I also ask for analytics access, ideally read access to Google Analytics and to a session recording tool if you use one. I do not need admin panel or code access.

Will you place orders in my store?

No. The audit stops at the payment method selection screen. I do not finalise any payment and leave no orders for you to cancel. If a finding needs the path taken further, we agree that separately and run it on your staging environment.

How long does it take?

From the first call to handover, usually a few days to two weeks, depending on scope and on how quickly I get analytics access. The date is agreed before we start.

Which platforms does this work on?

All of them, because the audit is a walkthrough from the customer's side rather than an analysis of engine configuration. I have run it on PrestaShop, and the same mechanisms occur on WooCommerce, Magento and Shopify. The technical protocol names the modules and settings of whichever platform your store runs on.

An agency runs my store. Does this undermine their work?

No, and the report is written so it can be handed over without conflict. An agency that built the store lacks distance from it, not skill.

Can I check some of this myself?

Yes, and it is worth starting there. The five tests on our checkout self-test page are the five most common failures, written so they can be run without tools in ten minutes. If all five pass, the audit still has plenty to check, but you know you are not starting from zero.

Let us start from the question you want answered

Write what worries you about the store. I will tell you whether a purchase path audit is the right instrument for that question, including when it is not. The call is free and carries no obligation. After it, you receive the scope, delivery date and fixed quote in writing.