The short answer
Never send card numbers, security codes, bank account details or passwords by email or in a support ticket. Tell us through the support form that your details need updating, and we give you a secure way to enter them yourself. Keep your billing contact current, and if a payment fails, check your bank first and then tell us.
Why you must never send card details by email or ticket
Email feels private, but it is not. A message passes through several systems on its way, and copies stay in your sent folder, the recipient's inbox, backups and anyone else's inbox who is copied or forwarded to. A card number sitting in an old email can be found by anyone who later gains access to that mailbox. Phishing and mailbox takeovers are common enough that the safe assumption is: anything in an email can eventually be read by someone you did not intend.
There is also an industry reason. The Payment Card Industry Data Security Standard, known as PCI DSS, is the global security standard that applies to anyone who stores, processes or transmits card data. Businesses that take payments normally avoid having card numbers pass through their own systems at all, by using payment pages that send the details straight to the payment provider. A card number in a ticket or an email is the opposite of that approach.
So the rule is the same for everyone: do not send full card numbers, security codes or bank account numbers by email, chat or ticket, to us or to anyone. We will never ask you to. We also never ask for passwords, and you must never send one. See access and logins for how we handle access without a password.
If someone claiming to be from Webtec asks for card details by email or chat, do not reply. Report it through the support form. Genuine requests never need the numbers in a message.
What is safe to share, and what is not
| Item | Safe in an email or ticket? | Why |
|---|---|---|
| Last four digits of a card | Yes | Identifies a payment without enabling a charge. Stripe's security guide lists the last four digits and expiry date as non-sensitive card data. |
| Card type, for example Visa | Yes | Not sensitive on its own. |
| Full card number | No | Enough to attempt payments. |
| Security code on the back | No | Never needed in a message. |
| Bank account number or IBAN | No | Can be used to set up debits against the account. |
| Invoice number and amount | Yes | Needed to answer questions, and not a payment credential. |
| A password or login link | No | We can reset access without seeing a password. |
The safe process, in general terms
The details can vary by situation, but the shape is always the same: you ask, we give you a secure way, and you enter the details yourself.
- 1Send a short request through the support form, category Billing or plan question, saying that your payment details need to change. Say whether it is a new card, a new bank account or a new company.
- 2A person on our team replies with a secure way to enter the details. This is a page where you type them straight into the payment system, not a message where you paste them.
- 3Check that you are on the right page before entering anything. Look at the address in the browser and the padlock. See ssl padlock warning if you want to know what the padlock means.
- 4Enter the details yourself. Confirm that the account or card you added is the one you meant, using the last four digits.
- 5Ask for a confirmation that the update was received, naming the last four digits, and keep it with your records.
Whether your plan is paid by card, bank debit or another route is a detail of your arrangement. Your proposal and invoices show how you pay, and a person on our team can explain how to change it.
How recurring card payments and mandates work in general
When a payment recurs, you give a standing permission once and the provider uses it each cycle. For cards, that permission is stored by the payment system as a token, not as the number in your hands or ours. For bank debits, the permission is called a mandate: a signed or accepted authorization that lets a company take payments from your account.
Stripe's documentation on SEPA Direct Debit, a bank debit scheme in the euro area, gives a good picture of how mandates work in practice. The customer must accept a mandate before the first debit. The customer can ask for a mandate to be cancelled at any time, either through the company or through their bank, which invalidates future debits taken under it. The company must notify the customer of each debit, and customers can dispute a debit through their bank, with a longer window for debits they did not authorize.
This is general information about one scheme, shown to explain the idea. It does not describe how your plan is billed. Your proposal and your invoices show that. If you do want to cancel a bank mandate, tell us as well as your bank, so that nobody assumes the payments will continue.
What to do when a payment fails
A failed payment is usually a small problem with a simple cause. The common ones are an expired card, a card replaced after loss or fraud, insufficient funds, a limit on the card, a bank blocking an unfamiliar debit, or bank details that changed. For bank debits, Stripe's documentation notes that failures often arrive some business days after the attempt, because the bank has a window to refuse the payment.
- 1Look at the message or notice you received. It often says why the payment failed.
- 2Check with your bank or card issuer. They can see the reason on their side, and many failures are resolved with one call.
- 3Check whether the card has expired, been replaced or been blocked.
- 4If the details need updating, use the safe process above. Do not send them in a reply.
- 5Tell us through the support form, naming the invoice, the date and what your bank said. A person on our team will go through what happens next with you.
We do not state here what happens after a failed payment, or when. That is written in your proposal, and a person on our team will go through it with you.
Keep your billing contact current
Invoices and payment notices go to a named contact. When that person leaves or changes role, the notices keep going to an inbox nobody reads, and a missed notice is the most common reason a small problem becomes a larger one. Put a review in your calendar twice a year.
- Use a shared mailbox such as accounts@yourcompany.com, rather than one person's address, if you can.
- Add your accountant as a second recipient if they handle payment.
- When anyone changes role, send us the new contact through the support form.
- Tell us which company name and address should appear on invoices. See invoices and receipts.
- Check spam and filtered folders for notices after any change of email address or domain. If your email changes with a domain move, see email and your domain.
Example: a card replaced after a bank alert
Example: The safe version
A retailer's card is reissued after her bank flags a suspicious transaction elsewhere. A week later she receives a notice that a payment did not go through. She does not reply with the new card number. She sends a support request: 'My card was replaced by my bank. I need to update my payment details. The old card ended 2290 and the new one ends 6613. The notice referred to invoice 2026-0377.' A person on our team replies with a secure way to enter the new details. She enters them, checks the last four digits and keeps the confirmation. At no point did the full number pass through an inbox.
When to ask us
Ask us whenever your payment method changes or a payment fails. Use the support form, category Billing or plan question. Send the invoice number, the date, the last four digits of the old and new methods, and what your bank told you. Do not send full numbers, security codes or bank account numbers. A person on our team will give you a secure way to update them and go through next steps with you.
