PDP (Product Detail Page)

A product detail page, or PDP, is the page about one item. It carries the images, the name and the price. It also carries the options, the delivery promise and the button that starts the purchase. Every other page in a shop exists to get someone here. This is where browsing turns into intent and where a shopper decides whether to go any further, and it earns more attention than almost any other page in the shop for exactly that reason.

The PDP matters to payments as well, which is less obvious. The price shown here sets the amount that will be approved, and the delivery promise here sets when the money should be taken. The payment logos here tell a shopper whether the option they want exists, long before they reach the payment step. Get these wrong and the failure shows up later at checkout, where it looks like a payment problem and is not one.

What A PDP Has To Answer

Four questions need answering quickly: what is this, does it suit me, what will it cost in total, and when will it arrive. Anything that does not help with one of those is noise. Shoppers scan instead of reading, so the order matters as much as the words. The questions people cannot answer here become the ones they ask support, or the reason they leave without asking anyone at all.

The Total Price Problem

A price that grows between the PDP and the payment step is a reliable way to lose a sale, and delivery charges, taxes and currency swaps are the usual causes. Where a shopper is buying in a currency other than the shop's own, currency conversion needs showing early and not at the end. Being plain here costs a few clicks and saves more of them: the people who drop out would have dropped out later anyway.

Payment Signals Belong Here

Showing which methods you take is not noise either. A shopper who uses a given mobile wallet wants to know it is there before spending time on the page, and the same goes for a local method. Deferred options count too, since buy now pay later changes the monthly figure and that is a buying choice, not a payment detail. Listing the right alternative payment methods for the shopper's market is a small change with a direct effect.

Delivery Promises Have Legal Weight

What a PDP says about delivery carries weight beyond marketing. In the UK, where no period is agreed, section 28 of the Consumer Rights Act 2015 applies, and it treats the contract as including a term that the trader must deliver without undue delay and within 30 days. Rules on delivery, cancelling and refunds differ by market, so a shop selling across borders needs the promise to match the local position instead of running one global line everywhere.

Structured Data And How Machines Read It

Search engines, marketplaces and assistants all try to read a PDP. Marking the page up in a shared vocabulary makes that steady rather than hopeful, and the schema.org Product type sets out fields for offers, price, stock and product codes. Keeping them true matters as much as having them at all. A page that claims an item is in stock when it is not costs more in cancelled orders than it wins in clicks.

Stock, Options And The Buy Button

Variants are where PDPs get messy. Size, colour and quantity all change the price and the stock, and each change has to flow through to the amount that gets approved. A button that stays live for a variant with no stock creates an order the business must then cancel and refund. That costs twice over: the refund costs money and the cancelled order costs trust.

Mobile Changes The Order

On a phone the page is a column, so everything competes for the same few inches. Images push the price down, long descriptions push the delivery promise past the fold, and a payment button that appears only at the bottom gets missed. The usual fix is to move the price, the stock line and the delivery promise up, and let the detail sit below them. Testing this on a real handset, not a narrow browser window, tends to change a few opinions.

Measuring The Page

Look at the funnel rather than the page on its own. Track the conversion rate from PDP to basket, basket to checkout, and checkout to paid, and keep those three apart. A rising bounce rate on the PDP normally points at price, stock or delivery before it points at design. Test changes one at a time, which is what A/B testing is for. A redesign that moves three things at once tells you nothing about which one worked.

What To Fix On The Page

Show the total cost as early as it can honestly be shown. Put the delivery promise near the price, not at the foot of the page. List the payment options a shopper in that market will know by sight. Keep the stock state and the buy button in step with each other. Mark the page up properly and keep the markup true. And test one change at a time. This look at how payment friction affects abandonment covers the downstream effect. This piece on ecommerce payment strategy covers the wider plan.

‍