Taking cards for a high-risk business does not mean loosening the controls. This page says plainly what each control does — and what it does not do.
Card numbers never reach your servers or ours
Customers type their card into a payment window run by the card processor, not into a page we control. We never receive the card number, so it cannot leak from your site or from ours.
What we keep is the order: the amount, the currency, the status, the time, and the name, email address and mobile number the customer typed at checkout.
3-D Secure
A card payment can be sent to the customer's bank for approval before it is taken. That is what stops a stolen card early, rather than months later as a dispute.
For subscriptions it matters twice over: a card is only kept for renewals after a first payment that passed 3-D Secure.
A payment is only paid once the processor says so
We confirm every order directly with the card processor over an authenticated request, and only then mark it paid and send you the event. A browser landing on a success page proves nothing and is never treated as payment.
The same confirmation runs if the customer closes the tab, so an order is not lost because somebody's connection dropped.
Two-step verification on your account
Any account can turn on two-step verification in Settings: a code from any authenticator app, plus ten one-time recovery codes to print and keep. The admin area requires it.
Authenticator secrets are stored encrypted, so a copy of the database on its own does not hand over anybody's second factor.
Some actions ask you to prove it is you again if you have not done so in the last fifteen minutes — creating an API key, adding a webhook endpoint, or reading a signing secret.
Encryption in transit
The site, the dashboard, the hosted checkout and the API are served over HTTPS only, and browsers are told to refuse plain HTTP for the domain. Webhook endpoints have to be HTTPS too.
Signed webhooks
Every webhook delivery carries a signature made with your endpoint's own secret, over the event id, the timestamp and the exact body. Your server can check that a call came from us and is not a replay of an older one; our Node and PHP libraries do it in one line.
Endpoints must resolve to a public address, redirects are not followed, and a delivery that fails is retried on a widening schedule — eight attempts in all, spread over a little more than a day.
API keys
Secret keys are created in Dashboard → Developers and shown once. We store only a hash of the key, so nobody — including us — can read it back afterwards. A key you are unsure about is revoked and replaced, not recovered.
A record of what happened to your account
Sign-ins and failed sign-ins, two-step changes, password resets, API key and webhook changes and views of a signing secret are recorded with the time and the address they came from. You can read your own recent activity in Settings.
Secrets and request bodies are never written to that record.
Your verification documents
What you upload to get approved is stored privately and is read only by the people reviewing your application. It appears in no merchant-facing list, export or API response.
If your own auditors, or a platform you sell on, need an answer about how payments are handled here, ask us and we will answer specifically rather than point at a badge.
Think you have found a security problem? Write to sales@utopia-payments.com before disclosing it anywhere else.