A Gift Shop Site Whose Checkout Jumps to an Unbranded Page

The site

A gift shop in a seaside town sells local pottery, cards, candles and jewellery, and its website lists about two hundred products with good photographs and a smooth cart.

Many online orders come from summer visitors who found the shop in person and order again from home, often as presents.

At checkout the shopper enters a shipping address and presses Pay. The browser lands on a plain white page at a different address, asking for a card number, expiry date and security code.

There is no logo, no shop name, no order summary and no link back to the cart. The only name on the page belongs to a payment company the shopper has never heard of.

The inference a visitor makes

The shopper stops. Every page until now looked like the shop; this one looks like something else, and it wants her card number.

She has been warned about fake payment pages, so she checks the address bar, which shows a name that is not the shop's. Nothing tells her whether this is the shop's real payment page or a trap.

The careful choice is to close the tab, and perhaps phone the shop later. The shop never learns which happened, because the order simply shows as an abandoned cart.

What the jump takes away

Sending shoppers to a payment company's own page is common and sensible. This one, though, arrives unannounced and stripped of everything that told the shopper where she was.

• The shop's name and logo, which carried the trust built on every earlier page.
• The order summary, so she cannot see what she is paying for, or how much.
• A warning on the cart that payment would happen elsewhere.
• A way back to change the order or simply check it.
• A name she recognises, both on the page and later on her card statement.

Each of these can be put back without moving card details onto the shop's own site.

No name, no logo

Most payment companies that host a payment page let the merchant customise it: a logo, the shop's colours, a heading, sometimes a line of text above the card fields.

Those settings are often skipped when the account is opened, because the first goal was a test payment that worked. The plain default has been live ever since.

Adding the logo and the shop's name answers the shopper's first question, whose page this is, before she has to ask it.

No order summary

A page asking for a card number without showing the amount looks odd to anyone careful. The shopper wants to see the total, shipping included, at the moment she types the number.

Hosted pages can usually show the amount and a description passed from the shop's cart. If the cart sends only a bare amount, the page has nothing more to display.

Passing the order number and a short description with the total makes the page read as the last step of this order, not a free-standing form.

No warning and no way back

One line on the cart page, above the Pay button, removes the surprise: card details are entered on our payment company's secure page, and you return here for your receipt.

On the payment page, a cancel link back to the cart offers a way out other than the back button, which after a submitted form can show an error or ask to resend.

After payment, the shopper should land on the shop's own confirmation page, with its name and the order details, rather than stay on the payment company's receipt.

On a phone it looks worse

Default payment pages are often laid out for a computer screen. On a phone the fields arrive tiny, and the page looks even less like the shop she just left.

Many payment companies offer a version of the hosted page sized for phones, sometimes as a separate setting. It is worth checking which one the account uses.

Visitors who found the shop on holiday often order from the phone in their pocket, so test the whole checkout there as well as on a computer.

The name on the card statement

The same doubt can return a week later. If the card statement shows the payment company's name, or an abbreviation of the shop's legal name, the customer may not recognise the charge.

Ask the payment company what name statements show, and whether it can match the shop's trading name. Then say on the confirmation page and in the receipt what the charge will look like.

A worked example

The gift shop's owner heard about the problem from a regular customer, who phoned in an order because the payment page had looked wrong to her.

Her developer added the logo, the shop's colours and a heading with its name in the payment company's settings, and the cart now passes the order number and a description with the total.

The cart page gained one sentence above the Pay button explaining the step, and the payment page a cancel link back to the cart. After paying, shoppers return to the shop's own confirmation page.

The account was switched to the payment company's phone-sized page, and a test order was placed on a phone and a computer.

The payment company confirmed that statements could carry the shop's trading name, and the receipt email now says so. Card details still never touch the shop's own server.

The counter-case within the site

The hosted payment page is not the problem, and moving card entry onto the shop's own pages would be the wrong fix.

Keeping card numbers on the payment company's page keeps them off the shop's server entirely, which is safer for customers and keeps the shop's card security obligations much lighter.

The fault is the presentation: an unexplained jump to an unbranded page with no way back. Keep the hosted page, and make it look and behave like part of the shop.

What to change

1. Place a test order as a shopper would.
2. Add the logo and name to the hosted payment page.
3. Pass the order details and total to that page.
4. Explain the step above the Pay button.
5. Add a cancel link back to the cart.
6. Return shoppers to the shop's own confirmation page.
7. Check the statement name and mention it in the receipt.

Step four costs nothing and can go up today. One sentence on the cart turns an alarming surprise into an expected step.

Which card security questionnaire a shop fills in, and why a hosted payment page keeps it short, is covered in the payment page decides which card questionnaire you fill in.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.