Tell shoppers before the handover that they will pay on a secure page run by your payment provider, brand that page with your logo and colours, and say which name will appear on their card statement.

The page after the pay button

A shopper has chosen a product, typed an address, picked a delivery option and pressed the button to pay.

The next page is plain and grey, with a logo they have never seen and a web address that is not yours.

Nothing has gone wrong. The store hands payment to its card processor, which is common and sensible. But the shopper does not know that, and the last step is where doubt costs most.

Some carry on. Others go back to check the site, or close the tab to think it over, which usually means the order is gone.

What changes at the handover

The second is the one that stops people. A shopper who has spent ten minutes with your brand meets a stranger's name at the moment they are asked for a card number.

Why the handover exists

The jump has a good reason behind it. On a hosted payment page, the card number goes into the provider's system and never passes through your website or server.

That keeps the most sensitive data off a site full of plugins and other people's code, and it shrinks the security work the card industry's rules expect of a store.

So the answer is rarely to bring card fields onto your own pages. It is to make the handover expected, familiar and easy to trust.

Say it before it happens

The simplest fix is a sentence on the last page of your own checkout, beside the button.

Name the provider, say payment happens on its secure page, and say the shopper returns to your site afterwards. They are about to see that name anyway.

Label the button for what it does. Continue to secure payment prepares people for a new page; Place order makes the new page look like a mistake.

A shopper told what will happen reads the change as proof that things are working.

Make the payment page look like yours

Most hosted payment pages have settings for a logo, colours, the store name and a line describing the order. Many stores never fill them in, because the setup screen was skipped at launch.

Use the logo from your site, match the main colour, and show your trading name rather than the legal name on the merchant account.

Some providers also offer card fields that sit inside your own checkout while the number still goes straight to them. The look stays yours, though it takes a developer to set up and maintain.

The name on the card statement

The second surprise arrives weeks later, with the statement.

The charge may show a legal name, a numbered company, or the provider's name and a code. A customer who bought from a shop with a friendly name sees a charge from a stranger.

Some phone the bank and dispute it. A dispute pulls the money back while it is investigated, usually adds a fee, and takes time to answer even when the sale was genuine.

Ask the provider what name your charges carry and whether it can be your trading name. The field is short, so choose words a customer will recognise at a glance.

Then tell customers, on the payment step and in the confirmation email, exactly how the charge will appear.

A worked example

An e-bike shop in a suburban industrial unit sells bikes, conversion kits and batteries from its showroom and online, often to buyers hours away.

Its checkout handed payment to a hosted page with the provider's logo, no mention of the shop, and the owner's numbered company listed as the merchant.

For a purchase in the thousands of dollars, that was too much doubt. The shop took calls asking whether the website was genuine, and one buyer disputed a charge listed under the numbered company.

The mechanism was simple: at the moment of greatest commitment, every familiar signal disappeared at once.

The fix took an afternoon. A sentence beside the button names the provider, the hosted page carries the shop's logo and colours, and statements show the trading name, repeated in the confirmation email.

A test order on the owner's own card found one more gap: after paying, buyers landed on the home page rather than a confirmation.

The trip back

After paying, the shopper should land on your own confirmation page, which repeats the order, says when it ships or can be collected, and gives a phone number.

Hosted pages have to be told where to send people, after payment and after a cancelled attempt. Left blank, many drop the shopper on a bare receipt.

Underneath, the store should mark an order paid because the provider reports it, not only because the shopper's browser came back. Someone who pays and closes the tab has still paid.

Your own pages need HTTPS too

The pages before the handover collect a name, an address, an email and a phone number, so they need HTTPS as much as the payment page does.

Chrome already labels plain HTTP pages with card fields Not secure. Chrome 62, due next month, extends that warning to any page where a visitor types into a form.

A shopper who sees the warning while typing an address is unlikely to trust a jump to another company's page a minute later.

The counter-case

Some stores feel this less. Where the provider is a name most shoppers already know and use, its page can reassure rather than alarm.

Stores selling mostly to repeat trade customers, or taking small amounts, see less hesitation at the last step, because the buyer already trusts them.

And a plain hosted page still beats moving card fields onto your own server for the sake of looks, which brings security duties most small stores should not take on.

For everyone else: explain the handover, brand the page and name the charge.

Before the next order

  1. Add a sentence naming your payment provider.
  2. Relabel the button to say where it goes.
  3. Upload your logo and colours to the payment page.
  4. Ask what name appears on card statements.
  5. Change it to your trading name if you can.
  6. Set the return page to your own confirmation.
  7. Place a test order on a phone with your card.

Step four is the one most stores have never asked about. It costs nothing to check, and a charge the customer recognises is a dispute that never starts.

Bringing back shoppers who still stop before paying is covered in abandoned cart emails.

Frequently asked questions

Why does my checkout go to another website?

Many stores use a hosted payment page, so card numbers go into the payment provider's system and never pass through the store's own website.

Is the hosted payment page the problem?

Not the arrangement itself. The problem is surprise: an unexplained change of name, address and look at the moment a shopper is asked for a card number.

How do I prepare shoppers for the handover?

Put a sentence beside the button naming the provider and saying they will return to your site, and label the button Continue to secure payment.

Can the payment page carry my branding?

Usually. Most hosted pages accept a logo, colours, a store name and an order description, and some providers offer card fields embedded in your own checkout.

Why do customers dispute charges they made?

Often because the statement shows a legal name, a numbered company or the provider's name, which they do not recognise weeks later. Ask for your trading name instead.

What should happen after payment?

The shopper returns to your own confirmation page, and the store records the paid order from the provider's report, even if the shopper closed the tab.

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.

Checkout ending on a stranger's page?

Send us your store address. We will walk through your checkout as a customer and list every screen that needs work.

Start a Conversation