Taking Payment Without Handling Card Details

The principle

The safest card details are the ones you never have.

Every reputable arrangement for taking payment online is built around that idea. The customer's card information travels from their browser to the payment company directly, and your site is told only whether it worked.

You get a confirmation and a reference. You never get the number, which means you cannot lose it, cannot store it wrongly, and cannot be the source of a breach involving it. That last point is the one that matters most.

How the arrangements differ

• Redirect, where the customer goes to the provider's page to pay and comes back afterwards.
• Embedded fields, where the payment form appears on your page but the fields belong to the provider.
• Full integration, where your server handles the card data directly.

The first two keep card details away from your site. The third does not, and it brings substantial security obligations that no small business should take on.

Almost every platform defaults to one of the first two, which is why this is mostly a matter of not overriding a sensible default.

What the obligations actually are

There is a card industry standard governing anybody who handles card data, and the level of scrutiny depends on how you handle it.

A business using a hosted arrangement faces a short self-assessment. A business whose server touches card numbers faces a substantially longer one, with technical requirements it will not meet by accident.

That difference is the practical reason for the whole design. It is not that hosted payment is safer in some abstract sense; it is that it moves the obligation to a company equipped to carry it.

A worked example

A small retailer whose developer built a custom checkout with card fields on their own site, because it looked more professional than a redirect.

It worked and the customer experience was good.

What nobody had considered was that their shared hosting account was now in scope for requirements it could not meet, and that their site was storing partial card data in server logs without anybody intending it.

Their payment provider identified this during a routine review and gave them thirty days to change it.

The fix was moving to the provider's embedded fields, which took a day and looked almost identical to the customer.

The three months before that had been a genuine exposure that nobody in the business knew existed.

The counter-case

Where a redirect is worth avoiding.

Redirects lose some customers. Leaving the site mid-purchase creates a moment of doubt, particularly if the destination looks unfamiliar or the branding changes abruptly.

Embedded fields solve that without taking on the obligations, which is why they have become the usual arrangement.

So the case against a redirect is real, and the answer is embedded fields rather than full integration.

Which provider

The considerations that actually matter for a small business.

What the transaction fee is, as a percentage plus a fixed amount. For low-value orders the fixed amount dominates and is worth comparing carefully.

How long until money reaches your account. Some pay out in two days, some in a week, and cash flow at small scale notices the difference.

Whether they hold funds in reserve, which some do for new accounts in certain categories.

And what happens in a dispute, because chargebacks are handled by the provider and the process varies considerably.

Saved cards and subscriptions

Where the principle still holds, with a wrinkle.

If customers save a card for next time, the card is stored by the provider and your site holds only a token, which is meaningless to anybody who steals it.

That is a good arrangement and it is worth confirming rather than assuming, particularly on an older site or a custom build.

The question to ask whoever built it: does anything on our server ever see or store a card number. The answer should be a straightforward no.

What you should keep

The other half of the question, and it is easy to over-collect.

Keep what you need to fulfil and account for the order: what was bought, where it went, the amount, the date, and the provider's reference.

Do not keep card numbers in any form, including partial ones written into notes or emails. Do not accept card details by email or over a form, which happens more often than it should.

If a customer emails you a card number, the right response is to delete it and ask them to pay through the proper route, rather than using it once and deleting it afterwards.

What the customer needs to see

Trust at the payment step is partly design rather than security.

The padlock and a secure address are the minimum, and by now their absence is alarming rather than their presence reassuring.

What helps beyond that: the total including shipping stated on the same screen, a recognisable payment provider name, and a clear indication of what happens after paying.

What hurts: an unexpected change in visual style, a page that looks unfinished, and any request for information that seems unnecessary at that stage.

Somebody abandoning at the payment step is frequently not worried about security in a technical sense. They are hesitating because something felt off, and that is usually presentation rather than encryption. The technical side is nearly always fine; the impression frequently is not.

Checking your own setup

1. Buy something from your own shop and watch what happens at payment.
2. Note whether you leave the site or the fields are embedded.
3. Ask your provider which self-assessment applies to you.
4. Ask whoever built the site whether any card data touches your server.
5. Check your order records for card numbers that should not be there.
6. Check your email for the same.

The last two find problems more often than people expect, usually from a period when somebody took a payment manually and made a note of it, intending to delete it later.

What the customer sees at that step is part of the same experience as the shipping cost, covered in showing shipping cost before checkout.

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.