What your software vendor should tell you about card payments

Every piece of software a service business runs takes a card. Most vendors say almost nothing about what happens to it, and the ones that do usually say "bank-level security", which means nothing at all.

Here are the questions worth asking, and what a good answer sounds like. They apply to any vendor, not only this one.

Where is the card number actually typed?

There is one answer that matters: on the payment provider's own page, not the vendor's.

When checkout is hosted by Stripe, Adyen or similar, the number goes straight from your browser to them. The vendor's servers never see it, so there is nothing for them to lose. When a vendor builds its own card form, the number passes through their systems, and now their security is your problem.

You can usually tell by looking. If the address bar changes to the payment provider when you pay, the vendor is out of the path. If you stay on the vendor's own domain with their own form, ask them directly.

What do they keep afterwards?

A good answer is short: the card brand and the last four digits.

That pair is what appears on a receipt, and it exists so you can tell two cards apart when you are reconciling. Nothing else is needed to show you a payment history. If a vendor keeps more, ask why, because the list of reasons is short and none of them are about showing you a receipt.

What nobody should keep: the full number, the expiry, or the CVC. The CVC in particular is not permitted to be stored after a payment by anyone, under any circumstances.

What happens when a payment fails?

This is the question that separates vendors who have thought about it from vendors who have not, because failure is routine. Cards expire. Banks decline. People change accounts.

Ask three things:

1. Will you be told, and how? Silence is the bad answer. A failed payment discovered when your account stops working is a failure of the vendor's process, not your bank's.
2. What does the product do in the meantime? Turning a business off the moment one payment bounces is aggressive. Most decent vendors retry over a week or two and tell you what is happening.
3. Will you be told the reason? "Payment failed" is useless. "Insufficient funds" and "card expired" need different actions from you, and the payment provider supplies the distinction. A vendor that hides it has thrown away the only fact that helps.

What should a payment request look like?

If a vendor ever emails you a link to pay something, the email itself should tell you three things before you click anything:

• the amount, in figures;
• what it is for, in words you recognise;
• how long the link is good for.

An email that says "you have a payment due, click here" and nothing else is shaped exactly like a phishing attempt, and the fact that it happens to be genuine does not make it safe to click. Vendors that send those are teaching their customers a habit that will eventually cost them.

A legitimate request also survives scrutiny: hovering the link shows the payment provider's domain, and the amount on the page matches the amount in the email.

Who can ask you for money?

Inside a vendor's own team, the ability to raise a charge against your account should be limited and recorded. It is fair to ask: who at your company can create a payment request, and is it logged?

The answer you want is that it is restricted to specific people, that each request records who made it and why, and that you can see the request itself. A vendor where anybody with a login can bill you an arbitrary amount is a vendor with one disgruntled employee between you and a problem.

Can you get your invoices without asking?

Your accountant will want PDFs. If getting them means emailing support every month, that is a small tax on you for ever.

The reasonable answer is a billing screen listing every invoice, its period, whether it was paid, and a link to the document. It costs a vendor very little and saves you an email every month.

Frequently asked questions

Is it safer to pay by bank transfer?

For large or irregular amounts, often yes, because nothing is stored to be stolen later. For recurring subscriptions a card is usually more convenient and gives you a dispute route a transfer does not. Neither is dangerous when the vendor keeps the number out of their own systems.

Should I use a dedicated card for software?

It makes reconciling easier and limits the damage from any one vendor's mistake. Many small businesses use one card for all software subscriptions for exactly this reason.

What if a vendor asks me to email my card details?

Do not. There is no situation where that is the right way to pay, and a vendor that asks has told you what you need to know about the rest of their handling.

What Frontiva does here

Checkout happens on Stripe's own pages, so your card number never reaches us. We hold the brand and last four digits, which is what your receipt shows, and nothing else.

Your invoices and payments are on your Billing screen with links to the Stripe-hosted invoice and its PDF, so your accountant can help themselves. When a payment fails, the reason the bank gave is recorded and shown rather than flattened into "failed".

Payment requests, when we send one, state the amount and what it is for above the button, carry a date, and record who at Frontiva raised them and why.

Two honest limits. Billing is not switched on yet, so there is nothing on your screen to look at today; the above is how it behaves when there is. And taking deposits from your customers is a different job and is not available either. The deposit amount on your Bookings page is shown to your customers but is not charged.