WooCommerce account and checkout pages, explained

WooCommerce does not treat the customer account and checkout as ordinary WordPress pages.

They appear under Pages inside WordPress, but behind those pages WooCommerce adds its own routing, endpoints, sessions, customer data, order handling and payment workflows.

This is why a WooCommerce store can have pages such as:

/cart/
/checkout/
/my-account/

while also supporting URLs such as:

/checkout/order-pay/123/
/checkout/order-received/123/

/my-account/orders/
/my-account/view-order/123/
/my-account/downloads/
/my-account/edit-address/
/my-account/payment-methods/
/my-account/edit-account/

Most of those URLs are not separate WordPress pages.

They are WooCommerce endpoints attached to a parent page.

Understanding this distinction is important when configuring WooCommerce, troubleshooting broken account URLs, customizing checkout, migrating URLs, configuring caching, or trying to understand why deleting one apparently simple WordPress page can suddenly prevent customers from completing an order.

The official WooCommerce Pages documentation explains the core pages created by WooCommerce and how they are assigned to store functions.

This guide explains how the WooCommerce Cart, Checkout and My Account pages work, how WooCommerce endpoints extend those pages, how Blocks differ from legacy shortcodes, and which parts of the system require special treatment.

The core WooCommerce pages

A standard WooCommerce installation creates several pages required by the store.

According to the official WooCommerce Pages documentation, the core store pages include:

• Shop;
• Cart;
• Checkout;
• My Account.

WooCommerce can also create a draft Refund and Returns Policy page, while a Terms and Conditions page can be assigned separately.

The three pages most important to the customer transaction and account flow are:

Cart
Checkout
My Account

These pages should be understood as application components rather than ordinary editorial pages.

These pages have different responsibilities

Conceptually, the purchasing journey looks like:

Product
↓
Cart
↓
Checkout
↓
Payment
↓
Order
↓
Order received

After the purchase, a registered customer may follow another flow:

Customer
↓
My Account
↓
Orders
↓
View Order
↓
Downloads / Addresses / Payment Methods

Although these areas are connected, WooCommerce assigns different responsibilities to each one.

The WooCommerce Cart page

The Cart page shows the products currently stored in the customer’s cart.

Depending on the store configuration, it can display:

• products;
• quantities;
• prices;
• discounts;
• coupon controls;
• shipping information;
• order totals;
• the action for continuing to checkout.

Modern WooCommerce installations normally use the Cart block for this page.

The official WooCommerce Cart and Checkout customization documentation explains how the modern Cart and Checkout blocks are structured and customized.

The Cart page is therefore more than a page containing static content.

Its output depends on the customer’s current cart state.

The WooCommerce Checkout page

The Checkout page is where WooCommerce turns the customer’s intended purchase into an order and coordinates the information required to complete the transaction.

Depending on the store, checkout can collect or display:

• billing information;
• shipping information;
• shipping methods;
• order contents;
• discounts;
• taxes;
• order totals;
• payment methods;
• terms and conditions;
• additional checkout fields;
• account creation options.

WooCommerce documents the modern checkout experience in its Cart and Checkout block documentation.

Because checkout combines customer information, orders and payment-related operations, it should also be treated as a security-sensitive workflow rather than just another frontend form.

The WooCommerce My Account page

The My Account page is the customer’s account area.

The official WooCommerce My Account documentation explains how customers can use this area to access orders, downloads, addresses, saved payment methods and account details.

It also participates in authentication-related workflows.

For example:

Logged-out visitor
↓
My Account
↓
Login or registration

Logged-in customer
↓
My Account
↓
Customer dashboard

Because the account area is connected to customer authentication, it should also be considered alongside the broader practices discussed in A WordPress Login Hardening Checklist.

Where WooCommerce assigns these pages

WooCommerce needs to know which WordPress page represents each core store function.

The assignments are available under:

WooCommerce
→ Settings
→ Advanced
→ Page setup

The official WooCommerce Advanced Settings documentation describes the assignments for:

• Cart page;
• Checkout page;
• My Account page;
• Terms and Conditions page.

You do not necessarily have to keep the exact pages WooCommerce originally created.

A replacement WordPress page can be created and assigned to the appropriate WooCommerce function.

Cart, Checkout and My Account must remain separate

Do not assign the same WordPress page to several core WooCommerce functions.

For example:

Cart:
Store

Checkout:
Store

My Account:
Store

is not an appropriate configuration.

WooCommerce expects separate pages because their routing and application responsibilities differ.

The official WooCommerce Pages documentation explains that using the same page for Cart, Checkout and My Account can result in incorrect redirects and broken payment gateway functionality.

What is actually inside the Checkout page?

This depends on whether the store uses the modern block-based checkout or the classic shortcode checkout.

Modern installations normally use:

WooCommerce Checkout block

Older stores may instead contain:

[woocommerce_checkout]

The official WooCommerce Page Shortcodes documentation documents the classic checkout shortcode.

If you first need the underlying WordPress concept, see WordPress Shortcodes Explained for Beginners.

Cart and Checkout Blocks are the modern default

Starting with WooCommerce 8.3, Cart and Checkout Blocks became the default experience for new installations.

The modern architecture generally looks like:

Cart WordPress page
↓
Cart block
↓
WooCommerce cart interface

and:

Checkout WordPress page
↓
Checkout block
↓
WooCommerce checkout interface

WooCommerce maintains current guidance for these components in its Cart and Checkout customization guide.

The legacy Cart shortcode

The classic Cart page uses:

[woocommerce_cart]

The shortcode displays the customer’s cart and associated cart controls.

It remains documented in the official WooCommerce page shortcode reference.

The legacy Checkout shortcode

The classic Checkout page uses:

[woocommerce_checkout]

This renders WooCommerce’s traditional checkout workflow.

Many older extensions, themes and customizations were built around this architecture.

Blocks and shortcodes are not identical internally

A customization written for the classic checkout may depend on:

• PHP hooks;
• traditional checkout templates;
• specific HTML structures;
• classic checkout JavaScript behavior;
• legacy field filters.

The Checkout block uses a different architecture.

Therefore:

Works with [woocommerce_checkout]
≠
automatically works with Checkout block

This is an important compatibility question when updating an established store.

Changes of this type should normally be tested on staging first. See WordPress Staging Site Best Practices and Building a Staging-First WordPress Update Workflow.

What is inside the My Account page?

WooCommerce’s classic My Account implementation uses:

[woocommerce_my_account]

The official WooCommerce shortcode documentation identifies this shortcode as the standard shortcode for displaying the customer account area.

The rendered experience depends on:

• whether the visitor is logged in;
• which account endpoint is being requested;
• the customer’s account data;
• orders and downloads;
• WooCommerce settings;
• extensions modifying the account area.

Logged-out My Account behavior

When a visitor who is not authenticated opens My Account, WooCommerce normally presents a login interface.

Depending on the store configuration, account registration can also be available.

The relevant options are under:

WooCommerce
→ Settings
→ Accounts & Privacy

The official WooCommerce Accounts and Privacy documentation explains the current registration and guest-checkout settings.

Because My Account participates in authentication, changes to login security should be tested against WooCommerce customer behavior too. See WordPress Brute-Force Attacks, Explained for the wider authentication threat model.

Logged-in My Account behavior

Once authenticated, the account area becomes a customer dashboard.

WooCommerce normally provides sections such as:

• Orders;
• Downloads;
• Addresses;
• Payment methods;
• Account details;
• Log out.

The exact interface can vary depending on the active theme and installed extensions.

WooCommerce does not create a WordPress page for every account section

This is where WooCommerce endpoints become important.

You normally do not need separate WordPress pages called:

Orders
Downloads
Payment Methods
Edit Account
View Order

Instead, WooCommerce attaches endpoints to the My Account page.

The official WooCommerce developer documentation on endpoints explains this routing model.

What is a WooCommerce endpoint?

A WooCommerce endpoint is an additional part of a URL that WooCommerce detects and uses to display different content.

For example:

https://example.com/my-account/

is the main account page.

Appending:

edit-account

produces:

https://example.com/my-account/edit-account/

WooCommerce detects that endpoint and renders the account-details interface.

Endpoints are not ordinary WordPress child pages

The conceptual model is:

WordPress page:
/my-account/

        +

WooCommerce endpoint:
orders

        =

/my-account/orders/

The resulting URL looks hierarchical, but orders does not need to exist as a separate WordPress page.

This is why WooCommerce can provide a relatively complex customer application while maintaining only one main My Account page.

Default My Account endpoints

The official WooCommerce endpoint documentation currently identifies account endpoints including:

/orders/
/view-order/{ORDER_ID}
/downloads/
/edit-account/
/edit-address/
/payment-methods/
/lost-password/
/customer-logout/

Each endpoint changes what WooCommerce renders within the account area.

The Orders endpoint

The URL:

/my-account/orders/

displays the customer’s order history.

The official WooCommerce My Account documentation explains the actions available to customers from their order history.

Depending on order state and store configuration, a customer may be able to:

• view an order;
• pay an eligible order;
• cancel an eligible order;
• repeat certain orders.

The View Order endpoint

A specific order can use a URL such as:

/my-account/view-order/1234/

where:

1234

identifies the requested order.

The presence of an order identifier in the URL must not itself grant access.

The security model needs to remain:

request order
↓
identify current customer
↓
verify authorization
↓
display permitted order

This follows the same general authorization principle discussed in WordPress REST API Security Basics: knowing a resource identifier is not the same as being authorized to retrieve the resource.

The Downloads endpoint

Stores selling downloadable products can expose customer downloads under:

/my-account/downloads/

The available files depend on the customer’s purchases and download permissions.

These URLs therefore represent customer-specific functionality rather than ordinary public media links.

The Edit Address endpoint

WooCommerce uses:

/my-account/edit-address/

for customer address management.

Depending on configuration, this can include billing and shipping addresses.

The Payment Methods endpoint

The URL:

/my-account/payment-methods/

can display stored payment methods supported by compatible payment gateways.

Customers may be able to:

• review saved payment methods;
• remove supported methods;
• set a default method;
• add another payment method.

The exact implementation depends on the payment gateway.

Saved payment methods depend on the payment provider

WooCommerce does not imply that every gateway stores complete payment credentials directly inside WordPress.

Gateway implementations often rely on tokens or provider-managed payment methods.

Always verify the architecture of the specific gateway being used.

This is also relevant to the broader topic covered in WordPress Privacy and Third-Party Requests, because payment providers necessarily introduce third-party infrastructure into the purchase flow.

The Account Details endpoint

The URL:

/my-account/edit-account/

allows customers to modify their account information.

The current functionality is documented in the official WooCommerce My Account guide.

The Lost Password endpoint

WooCommerce integrates password recovery through:

/my-account/lost-password/

This provides a storefront-oriented recovery flow connected to the underlying WordPress user account.

Password recovery should be considered part of the site’s login security rather than a completely separate WooCommerce feature. See A WordPress Login Hardening Checklist.

The Logout endpoint

The account area also provides:

/my-account/customer-logout/

for ending the current customer session.

If plugins or custom code change login and logout behavior, test this endpoint to make sure customers are not redirected incorrectly.

WooCommerce also has Checkout endpoints

The Checkout page has its own endpoint system.

The official WooCommerce endpoint documentation identifies checkout-related endpoints including:

/order-pay/{ORDER_ID}
/order-received/
/add-payment-method/
/delete-payment-method/
/set-default-payment-method/

These represent different transaction and payment states.

The order-pay endpoint

An order that already exists but still requires payment can use a URL such as:

/checkout/order-pay/1234/

This allows WooCommerce to present payment for an existing order instead of creating another order through the standard cart checkout.

This may be relevant to workflows involving:

• failed payments;
• pending payments;
• customer payment links;
• manually created orders.

The order-received endpoint

After checkout, customers commonly reach a URL involving:

/checkout/order-received/1234/

This is the WooCommerce order-confirmation or thank-you state.

It can display information such as:

• order number;
• order details;
• payment information;
• customer details;
• gateway-specific instructions.

WooCommerce generates this state through the Checkout page and endpoint system rather than creating a separate WordPress page for every order.

Why WooCommerce uses endpoints

Without endpoints, WooCommerce could require separate pages for:

My Account
Orders
Downloads
Addresses
Edit Account
Payment Methods
Lost Password
View Order
Order Pay
Order Received
...

Instead, endpoints allow WooCommerce to maintain a smaller set of parent pages while dynamically selecting the correct application state.

The official WooCommerce endpoint guide explicitly describes this as a way to show different content without requiring multiple installed pages and shortcodes.

Where endpoint slugs are configured

WooCommerce endpoint settings are available under:

WooCommerce
→ Settings
→ Advanced

Endpoint values such as:

orders
downloads
edit-account

can be customized.

The official WooCommerce endpoint customization documentation explains how these values can be changed.

Endpoint slugs must remain unique

Do not assign the same slug to multiple endpoints.

For example:

Orders:
account

Downloads:
account

Edit account:
account

creates routing ambiguity.

WooCommerce’s endpoint URL documentation specifically recommends keeping these values unique to avoid conflicts.

Changing endpoint slugs changes customer-facing URLs

If:

orders

becomes:

my-orders

the account URL changes from:

/my-account/orders/

to:

/my-account/my-orders/

That can affect:

• bookmarks;
• custom links;
• emails;
• theme customizations;
• plugin integrations;
• documentation;
• cached URLs.

When changing established URL structures more broadly, see How to Migrate WordPress URLs Safely.

Flush permalinks after endpoint changes

If WooCommerce endpoints unexpectedly return 404 errors after routing changes, refresh WordPress rewrite rules.

A standard troubleshooting step is:

WordPress
→ Settings
→ Permalinks
→ Save Changes

You normally do not need to change the permalink structure itself.

The official WooCommerce endpoint troubleshooting documentation and WooCommerce Pages Not Displaying guide both recommend refreshing rewrite rules when endpoint URLs produce 404 errors.

Do not repeatedly flush rewrite rules

Refreshing permalink rules should be a deliberate administrative operation.

Custom code should not flush rewrite rules on every request.

Plugins registering custom endpoints should normally refresh them only when the routing configuration actually changes.

What happens if the Checkout page is deleted?

WooCommerce needs an assigned Checkout page.

If that page is deleted, unassigned or incorrectly configured, customers may be unable to complete purchases.

Symptoms can include:

• checkout links pointing somewhere incorrect;
• 404 errors;
• empty checkout output;
• redirect problems;
• payment gateway failures;
• broken endpoint URLs.

The official WooCommerce troubleshooting documentation explains how to diagnose missing or incorrectly configured store pages.

What happens if the Cart page is deleted?

The cart itself may still exist in the customer session, but the standard Cart page flow can stop working correctly because WooCommerce no longer has the expected page assigned.

Cart and Checkout assignments should therefore be treated as store configuration, not disposable page content.

What happens if the My Account page is deleted?

WooCommerce can lose the parent page used for customer account routing.

That can affect:

• login;
• registration;
• orders;
• downloads;
• addresses;
• payment methods;
• account editing;
• password recovery;
• logout URLs.

WooCommerce can recreate missing pages

If default WooCommerce pages are missing, WooCommerce provides a built-in tool under:

WooCommerce
→ Status
→ Tools
→ Create pages

The official WooCommerce Pages documentation explains that this tool creates missing default pages.

After recreating them, verify page assignments under:

WooCommerce
→ Settings
→ Advanced

You can also create replacement pages manually

A WooCommerce page does not have to remain the exact page created during installation.

You can create another page and assign it to the relevant WooCommerce function.

For example:

Old Checkout page:
ID 42

New Checkout page:
ID 981

WooCommerce Settings:
Checkout page → ID 981

The official WooCommerce page troubleshooting guide explains how missing pages can also be recreated manually with the appropriate WooCommerce block or shortcode.

Do not identify WooCommerce pages only by their slug

WooCommerce uses configured page assignments.

This means the Checkout page does not necessarily need to use:

/checkout/

It could use another permalink if that WordPress page is assigned as the Checkout page.

The same principle applies to My Account and Cart.

Custom development should therefore prefer WooCommerce functions and assigned page information rather than assuming hardcoded slugs.

The Shop page behaves differently

The Shop page is the main product archive.

The official WooCommerce Pages guide describes it as the primary page where store products are displayed.

It therefore behaves differently from Cart, Checkout and My Account, which are primarily customer-state and transaction-oriented interfaces.

Checkout is stateful

A normal informational page behaves approximately like:

request
↓
retrieve content
↓
render HTML

Checkout is considerably more complicated.

A simplified transaction can involve:

customer session
↓
cart contents
↓
billing / shipping information
↓
shipping calculation
↓
tax calculation
↓
payment method
↓
order creation
↓
payment processing
↓
order status
↓
order received

That statefulness affects caching, deployment and testing.

Do not cache Cart and Checkout like ordinary pages

Cart and Checkout contain dynamic customer-specific information.

The official WooCommerce troubleshooting documentation specifically notes that Cart and Checkout should typically be excluded from page caching because their content is session-specific.

A cache that does not understand WooCommerce can otherwise serve stale transactional state or prevent checkout changes from appearing correctly.

My Account is customer-specific too

The account area depends on the authenticated customer.

Two users visiting:

/my-account/orders/

must not receive the same account output.

Full-page caching systems therefore need appropriate rules for authenticated users and customer-specific WooCommerce interfaces.

WooCommerce sessions matter to Cart and Checkout

The customer’s cart needs to survive navigation between pages.

Conceptually:

Add product
↓
cart state changes
↓
visit another page
↓
cart persists
↓
checkout receives current cart

If caching, cookies, CDN behavior or custom code interferes with this state, checkout can become inconsistent.

Modern WooCommerce also uses APIs for customer-facing commerce

Modern WooCommerce is not implemented exclusively through traditional PHP page rendering.

WooCommerce provides a Store API for customer-facing cart, checkout and product functionality.

The official WooCommerce API documentation distinguishes the Store API from the authenticated WC REST API.

This is particularly relevant when working with modern Cart and Checkout Blocks or custom JavaScript commerce interfaces.

Because WooCommerce builds on WordPress APIs, broad attempts to disable WordPress REST functionality should be tested carefully. See WordPress REST API Security Basics.

Guest checkout and account checkout are different workflows

WooCommerce can permit guest purchases.

In that case:

customer
↓
checkout
↓
order
↓
existing account not required

Alternatively, a store can require or encourage account creation.

The current behavior is controlled through WooCommerce’s Accounts and Privacy settings.

WooCommerce can create accounts during checkout

WooCommerce currently provides several account creation options, including account creation during checkout or after checkout, depending on configuration.

This creates a relationship between:

Checkout
+
Customer account
+
Order history

The resulting customer can later access eligible order information from My Account.

Guest orders are still WooCommerce orders

An existing registered account is not required for an order to exist.

Conceptually:

Registered checkout
→ order associated with customer account

Guest checkout
→ order exists without normal registered account ownership

This distinction matters when implementing customer account tools, order lookup mechanisms and integrations.

Account pages must protect customer-specific data

A URL such as:

/my-account/view-order/1234/

contains an identifier that can be seen by the customer.

The security model must not be:

customer knows order ID
→ customer may access order

Instead:

request order
↓
identify customer
↓
verify authorization
↓
return permitted data

This authentication-versus-authorization distinction is also central to WordPress REST API Security Basics.

WordPress user roles still matter around WooCommerce

WooCommerce introduces roles such as Customer and Shop Manager into the broader WordPress capability system.

Administrative and customer workflows should therefore be tested using realistic permissions.

For the underlying WordPress model, see WordPress User Roles and Capabilities, Explained.

Sequential identifiers are not access control

Even if an order identifier can be predicted, authorization must prevent customers from viewing orders they do not own.

A secure application should assume that identifiers can become known.

Access control should protect the underlying data regardless.

Checkout is security-sensitive

Checkout handles information associated with:

• customer identity;
• billing;
• shipping;
• orders;
• payments;
• account creation.

The store should use HTTPS and follow the security requirements of the installed payment gateway.

Third-party services involved in checkout should also be included in privacy and data-flow reviews. See WordPress Privacy and Third-Party Requests.

Do not customize checkout by editing WooCommerce core files

Changes made directly inside the WooCommerce plugin directory can disappear during updates.

Use supported extension mechanisms instead, including:

• WooCommerce hooks;
• filters;
• supported block extension APIs;
• template overrides where appropriate;
• custom plugins;
• child themes for presentation-level modifications.

For the wider maintenance implications of modifying or avoiding plugin updates, see The Risks of Not Updating WordPress Plugins.

Template overrides require maintenance

Classic WooCommerce customization can involve copying templates into a theme.

Once overridden, that copy may diverge from newer versions supplied by WooCommerce.

After major WooCommerce updates, test important overrides rather than assuming old template code will remain compatible indefinitely.

A staging-first process is particularly important for an e-commerce site because a compatibility problem can affect orders rather than merely presentation. See Building a Staging-First WordPress Update Workflow.

Plugins can add My Account endpoints

The WooCommerce endpoint architecture is extensible.

Extensions can introduce additional account URLs such as:

/my-account/subscriptions/
/my-account/memberships/
/my-account/licenses/
/my-account/rewards/

WooCommerce itself offers a My Account Page Editor extension designed to add and customize account endpoints. Its behavior is documented in the official My Account Page Editor documentation.

Custom endpoints need unique routing

Custom endpoints should avoid conflicts with:

• WooCommerce core endpoints;
• other plugin endpoints;
• WordPress pages;
• other rewrite rules.

If endpoint routing changes, permalink rules may need refreshing.

Be careful when multiple systems control customer redirects

A WooCommerce store can have several systems modifying the same navigation flow:

WooCommerce
+
membership plugin
+
authentication plugin
+
checkout extension
+
custom code

Conflicts can result in:

• redirect loops;
• customers landing on incorrect pages;
• checkout interruptions;
• failed account flows.

These interactions should be included in the wider testing process described in Preparing a WordPress Site for Launch.

Checkout endpoints are application states, not normal editorial pages

URLs representing:

• order payment;
• order confirmation;
• customer account data;
• account editing;

are application states rather than ordinary editorial landing pages.

They should not be treated as independent content pages merely because they have unique URLs.

This distinction is related to the broader URL concepts covered in WordPress Canonical URLs, Explained.

The Cart page is also not normal SEO content

Cart contents depend on the visitor’s current session.

The page does not represent stable editorial content intended to rank independently in search engines.

The same principle generally applies to Checkout and customer account states.

Do not hardcode customer-specific endpoint URLs

Custom development should avoid manually constructing URLs such as:

/checkout/order-pay/
/checkout/order-received/
/my-account/orders/

when WooCommerce provides an API for generating the correct destination.

The official WooCommerce endpoint URL documentation specifically documents helper methods such as:

$order->get_checkout_payment_url()
$order->get_checkout_order_received_url()

This protects integrations from assumptions about endpoint or page configuration.

Hardcoded URLs become especially fragile during migrations

A store can change:

• domain;
• directory;
• page slug;
• endpoint slug;
• permalink structure.

Hardcoded links can silently retain the previous value.

For wider migration precautions, see How to Migrate WordPress URLs Safely.

Checkout needs special consideration during maintenance

A customer can be halfway through a transaction when maintenance begins.

For example:

Cart
↓
Checkout
↓
payment provider
↓
maintenance begins
↓
payment callback returns

If the store becomes unavailable at the wrong point, order and payment state can become difficult to reconcile.

This is why e-commerce maintenance needs more planning than temporarily replacing the homepage. See WordPress Maintenance Mode Best Practices.

Staging is especially important for WooCommerce changes

Checkout modifications should be tested away from production before deployment.

See:

• WordPress Staging Site Best Practices;
• Distinguishing Staging from Production in WordPress;
• Building a Staging-First WordPress Update Workflow.

WooCommerce introduces an important complication:

production continues receiving transactional data while staging exists.

The live store may receive:

• orders;
• new customers;
• payment changes;
• refunds;
• inventory changes;
• subscription events;
• other extension-managed data.

Do not overwrite current production data with an old staging database

Imagine staging was copied Monday morning.

Production then receives:

Monday:
12 orders

Tuesday:
18 orders

Wednesday:
9 orders

If Wednesday’s deployment replaces the production database with Monday’s staging database, those newer production transactions can be lost.

This is why the difference between configuration export and actual recovery is important. See Settings Export vs. Full Backup: What’s the Difference?.

Create and verify backups before major WooCommerce changes

A backup is useful only if it can actually be restored.

Before high-risk changes, verify the recovery workflow rather than merely checking that a backup file exists somewhere.

See How to Test a WordPress Backup Restore.

Test more than a successful checkout

A WooCommerce checkout audit should cover several customer paths.

At minimum, test:

• guest checkout where enabled;
• logged-in checkout;
• account creation during checkout;
• successful payment;
• failed payment;
• pending payment where relevant;
• coupon application;
• shipping calculation;
• tax calculation;
• order creation;
• transactional emails;
• order received page;
• My Account order visibility.

Test the order-pay flow separately

A successful standard checkout does not prove that:

/checkout/order-pay/{ORDER_ID}/

works correctly.

If the store supports payment for existing unpaid orders, test that workflow separately.

Test My Account as a real Customer

Administrator access can hide problems experienced by customers.

Use an actual Customer role and verify:

• login;
• orders;
• view order;
• downloads;
• addresses;
• payment methods;
• account details;
• password changes;
• logout.

For the underlying role system, see WordPress User Roles and Capabilities, Explained.

Test while logged out too

The same My Account URL behaves differently depending on authentication.

Verify both:

Logged out
→ authentication / registration

Logged in
→ customer dashboard

A test performed only while authenticated covers only part of the account workflow.

Test mobile checkout carefully

Checkout should be tested on realistic mobile devices and viewport sizes.

Verify:

• form fields;
• shipping selection;
• payment controls;
• order summary;
• validation errors;
• terms acceptance;
• place-order button;
• touch interaction;
• mobile keyboards.

Test with production-like caching enabled

A staging test with every cache disabled does not prove the production configuration works.

Verify the actual cache configuration correctly handles:

• Cart;
• Checkout;
• My Account;
• authenticated customers;
• WooCommerce sessions;
• dynamic customer-specific requests.

The official WooCommerce page troubleshooting documentation specifically identifies caching as a possible cause of broken core store pages.

Test payment callbacks separately from browser redirects

A payment provider may communicate with WooCommerce independently of the customer’s browser.

Therefore:

customer reached thank-you page
≠
every payment integration component worked correctly

and:

customer closed browser
≠
payment necessarily failed

The exact lifecycle depends on the payment gateway.

Test webhooks and server-to-server callbacks according to that gateway’s documentation.

A practical WooCommerce page map

Area	Typical URL	Purpose
Shop	/shop/	Main product archive
Cart	/cart/	Review current cart
Checkout	/checkout/	Complete purchase
Order Pay	/checkout/order-pay/{ID}/	Pay an existing order
Order Received	/checkout/order-received/{ID}/	Order confirmation
My Account	/my-account/	Customer dashboard
Orders	/my-account/orders/	Order history
View Order	/my-account/view-order/{ID}/	Specific order details
Downloads	/my-account/downloads/	Customer downloads
Addresses	/my-account/edit-address/	Billing and shipping addresses
Payment Methods	/my-account/payment-methods/	Saved payment methods
Account Details	/my-account/edit-account/	Customer account information
Lost Password	/my-account/lost-password/	Password recovery

Common WooCommerce account and checkout mistakes

Deleting an apparently empty WooCommerce page

The page may be assigned to an important WooCommerce function even if its editor content appears minimal.

Using the same page for Cart, Checkout and My Account

These functions require separate page assignments.

Assuming every account URL is a WordPress page

Most account sections are WooCommerce endpoints.

Creating separate WordPress pages for every account endpoint

This is normally unnecessary.

Hardcoding /checkout/

The assigned Checkout page can use another permalink.

Hardcoding /my-account/

The same principle applies to My Account.

Hardcoding endpoint slugs

WooCommerce allows endpoint values to be changed.

Changing endpoint names without refreshing rewrite rules

This can result in 404 errors.

Caching Checkout like static HTML

Checkout is session-specific and transactional.

Caching My Account publicly

Account output is customer-specific.

Assuming Blocks and classic shortcodes are identical

Customizations and extension compatibility can differ.

Editing WooCommerce core plugin files directly

Updates can overwrite those modifications.

Ignoring template override maintenance

Old overrides can become incompatible with newer WooCommerce versions.

Testing checkout only as Administrator

Use realistic Customer and guest states.

Testing only successful payments

Failed and pending transaction states matter too.

Testing only desktop checkout

Mobile checkout needs dedicated testing.

Assuming order IDs provide authorization

Customer permission must still be verified.

Deploying an old staging database over production

This can overwrite real orders, customers and other transactional data.

Ignoring webhooks during maintenance

Payment systems can continue communicating with the store independently of the customer’s browser.

WooCommerce account and checkout audit checklist

• Verify the Cart page exists.
• Verify the Checkout page exists.
• Verify the My Account page exists.
• Check WooCommerce > Settings > Advanced page assignments.
• Keep Cart, Checkout and My Account assigned to separate pages.
• Verify the Cart block or appropriate legacy shortcode.
• Verify the Checkout block or appropriate legacy shortcode.
• Verify the My Account shortcode and account area.
• Know whether the store uses Checkout Blocks or classic checkout.
• Check extension compatibility with the current checkout architecture.
• Understand WooCommerce endpoints.
• Verify the Orders endpoint.
• Verify the View Order endpoint.
• Verify the Downloads endpoint.
• Verify the Edit Address endpoint.
• Verify the Payment Methods endpoint.
• Verify the Edit Account endpoint.
• Verify the Lost Password endpoint.
• Verify customer logout.
• Verify the Order Pay endpoint.
• Verify the Order Received endpoint.
• Keep endpoint slugs unique.
• Refresh permalinks after relevant endpoint changes.
• Do not flush rewrite rules on every request.
• Avoid hardcoded WooCommerce page URLs.
• Avoid hardcoded endpoint URLs where WooCommerce helpers are available.
• Review Cart caching.
• Review Checkout caching.
• Review My Account caching.
• Verify WooCommerce session persistence.
• Test adding products to the cart.
• Test changing quantities.
• Test removing products.
• Test coupons where enabled.
• Test shipping calculations.
• Test tax calculations.
• Test guest checkout where enabled.
• Test logged-in checkout.
• Test account creation during checkout where enabled.
• Test successful payments.
• Test failed payments.
• Test pending payments where relevant.
• Test order creation.
• Test order confirmation.
• Test transactional emails.
• Test payment callbacks and webhooks.
• Test the order-pay workflow.
• Test customer order history.
• Test order authorization.
• Test downloadable products where applicable.
• Test address editing.
• Test saved payment methods where supported.
• Test account details.
• Test password changes.
• Test password recovery.
• Test login.
• Test logout.
• Test registration where enabled.
• Test as a real Customer role.
• Test while logged out.
• Test desktop checkout.
• Test mobile checkout.
• Test validation errors.
• Test payment controls on touch devices.
• Review customizations after WooCommerce updates.
• Review template overrides.
• Test plugin-added account endpoints.
• Check redirect behavior.
• Test with production-like caching enabled.
• Test WooCommerce changes on staging first.
• Do not overwrite current production orders with stale staging data.
• Create a current backup before major changes.
• Verify that the backup can actually be restored.
• Run a production checkout smoke test after deployment.

Related guides

• WordPress Shortcodes Explained for Beginners
• WordPress Staging Site Best Practices
• Building a Staging-First WordPress Update Workflow
• WordPress User Roles and Capabilities, Explained
• Settings Export vs. Full Backup: What’s the Difference?
• Preparing a WordPress Site for Launch

Final recommendation

Treat WooCommerce Cart, Checkout and My Account as application components, not ordinary WordPress content pages.

The basic architecture is:

WordPress pages
↓
assigned to WooCommerce functions
↓
WooCommerce blocks or shortcodes
↓
WooCommerce routing and endpoints
↓
customer-specific application state

The Checkout page manages the transactional path from cart to order and payment.

The My Account page acts as the main customer account container, while endpoints such as:

orders
downloads
edit-address
payment-methods
edit-account

allow WooCommerce to display different customer states without requiring a separate WordPress page for each one.

Checkout endpoints use the same routing concept for workflows such as:

order-pay
order-received

This architecture is flexible, but apparently simple changes can have significant consequences.

Deleting an assigned page, caching Checkout incorrectly, changing endpoint slugs, hardcoding URLs, applying an incompatible shortcode-based customization to Checkout Blocks, or overwriting live transactional data from staging can break important parts of the purchasing journey.

The safer approach is:

keep core WooCommerce pages correctly assigned
↓
understand which URLs are endpoints
↓
use WooCommerce helpers instead of hardcoded URLs
↓
protect customer-specific data
↓
exclude transactional pages from inappropriate caching
↓
test guest and authenticated customer flows
↓
test successful and failed payments
↓
test account endpoints
↓
test changes on staging
↓
protect current production data
↓
verify production with a complete purchase workflow

For configuration and troubleshooting, use WooCommerce’s official WooCommerce Pages documentation, endpoint documentation, Cart and Checkout documentation, and My Account documentation as primary references.

Once pages, endpoints, sessions, customer permissions and transaction states are understood as separate layers, WooCommerce account and checkout behavior becomes much easier to customize and troubleshoot without breaking the workflows that turn a cart into a completed order.