Our security promise

The safest card data is the card data we never hold

PaymentHood is built on a single principle: reduce what can be lost. We do not store, process, or transmit cardholder data. Card details travel directly from your customer to your payment provider's certified infrastructure, and PaymentHood orchestrates every payment using tokens alone.

Minimise the blast radius

If sensitive data never enters a system, it cannot leak from it. Tokenization is our first control, not our last.

Isolate every merchant

Authorization is checked server-side on every request against your application and merchant scope, so one merchant's data is never reachable from another's session or API key.

Make everything provable

Signed webhooks and end to end audit logs mean security claims can be verified, not just trusted.

Security Architecture

Where Card Data Goes, and Where It Does Not

The unified customer token model. Follow the card and you will see it never reaches us.

  1. Customer Card Entered by your customer at checkout
  2. Provider Received by your provider's certified infrastructure
  3. Payment Token The provider returns a token. The card is never exposed
  4. PaymentHood Orchestrates and routes using the token only
  5. Encrypted Storage Token sealed with AES-256-GCM at rest

Card data flows only between your customer and your provider. Everything PaymentHood touches is a token — which means adding PaymentHood brings no cardholder data into your environment, and no new PCI obligation with it.

Data Flow & Tokenization

One Customer Reference, Many Providers

Your systems work with a customer ID and an amount. PaymentHood resolves everything behind it: which stored token to charge, which provider to route to, and in which currency.

  • Tokens are issued by the provider, never minted by us
  • Your integration never handles a PAN, CVV, or expiry date
  • Swap or add providers without re-collecting payment details
Traceability

Every Action, On the Record

PaymentHood records the full lifecycle of every payment: each status change, when it happened, who triggered it, and why, alongside every gateway interaction and webhook delivery attempt.

  • Complete payment lifecycle with actor and reason
  • Every gateway call and webhook delivery attempt
  • End to end tracing for any investigation
Encryption

Strong Cryptography at Every Layer

At rest, in transit, and in every notification we send.

AES-256 at Rest

Every merchant's payment provider credentials are sealed at rest with AES-256-GCM, and are decrypted only for the moment a provider call is made — never written back in the clear.

🗝️

Sealed Keys

The key ring that protects your credentials is itself sealed with AES-256-GCM authenticated encryption, under a master key supplied to the service at runtime and never stored beside the data it protects.

🔒

TLS in Transit

All traffic between your systems, your customers, and PaymentHood is protected with HTTPS/TLS. End to end, with no exceptions.

✍️

HMAC-SHA256 Webhooks

Every webhook is signed and timestamped, so you can verify each notification came from PaymentHood and was not tampered with or replayed.

Authentication & Access Control

Least Privilege, Enforced

Who can reach your account, and what they can do once they are in.

📱

Enforceable MFA

Sensitive account actions are protected by TOTP multi-factor authentication using Google Authenticator or any compatible app. Administrators can make MFA mandatory across their entire team.

👥

Role-Based Team Access

Invite your team with role-based permissions so every member is scoped to exactly what they need and nothing more.

🎫

JWT and OAuth 2.0

API and session access use industry standard JWT tokens and OAuth 2.0 flows for authentication and session management.

🎛️

You Control the Secrets

Generate and rotate your webhook signing secret at any time, or disable signing entirely. Add your own Authorization header when your endpoint requires one.

Fraud & Risk

Risk Signals, Watched Automatically

PaymentHood applies AI-assisted risk analysis to payment behaviour, so unusual activity surfaces without adding friction to ordinary checkouts.

Behaviour-based

Payment activity is assessed against how your customers normally behave, rather than against a fixed list of rules that never changes.

AI-assisted

Scoring is model-driven, so it keeps working as patterns shift instead of going stale the moment someone learns the rules.

Deliberately unpublished

We do not document our signals, weightings, or thresholds. Publishing them would hand the people we are defending against a map of exactly what to avoid.

Evaluating PaymentHood and need more than this? Talk to us and we will go further under NDA than we will in public.

Infrastructure & Availability

Built to Keep Running

Managed cloud infrastructure, asynchronous delivery, and isolated environments.

☁️

Managed Cloud Platform

PaymentHood runs on Microsoft Azure, with logs held in secure cloud logging under managed retention policies.

🔁

Resilient Delivery

Webhook events are queued and delivered asynchronously with automatic retries when your endpoint is temporarily unavailable, so a brief outage on your side never loses an event.

🧪

Isolated Environments

Sandbox and live are fully separated: separate credentials, separate configuration, no crossover. Going live is a credential swap, not a code change.

Compliance

Scope Reduction by Design

The most reliable way to satisfy a cardholder data requirement is to remove the cardholder data.

Cardholder data
Never stored, processed, or transmitted by PaymentHood
PCI scope
Card data is handled entirely within your payment provider's certified environment, and PaymentHood works only with provider-issued tokens. Adding PaymentHood introduces no cardholder data into your systems, so it adds nothing to whatever PCI obligation your own channels already carry.
Provider certification
Each connected provider maintains its own certifications for the card data it handles on your behalf.
Data residency and retention
Audit and delivery logs are retained on Microsoft Azure under managed retention policies.

Need documentation for a vendor review or security questionnaire? Contact us and we will work through it with you.

Who Is Responsible for What

Most security incidents happen at the seam, where each side assumed the other had it covered. Our Shared Security Responsibility Model draws that line explicitly across all seventeen CSA Cloud Controls Matrix domains — including a plain list of the things we do not do.

Incident Response

If Something Goes Wrong

How we detect, contain, and communicate.

1

Detect

Platform and gateway interactions are continuously logged, so anomalies surface against a complete record.

2

Contain

Provider credentials are stored encrypted and never logged, so a single issue does not expose them — and any credential can be replaced from your dashboard without redeploying anything.

3

Investigate

End to end audit trails let us reconstruct exactly what happened, when, and to which payments.

4

Notify

Affected merchants are contacted directly with what we know, what we have done, and what you should do.

Responsible Disclosure

Found a vulnerability? We want to hear from you before anyone else does. Report it privately and we will acknowledge your message, investigate, and keep you updated until it is resolved. Please give us reasonable time to fix an issue before disclosing it publicly, and avoid accessing or modifying data that is not yours while testing.

Security FAQ

Frequently Asked Questions

No. Card details go directly from your customer to your payment provider. PaymentHood receives only the token the provider issues in return.

Encrypted at rest with AES-256-GCM authenticated encryption. The key ring that protects them is itself sealed under a master key supplied to the service at runtime, so it is never stored alongside the credentials it protects. Provider credentials are decrypted only for the moment an outbound call is made, and are never written back in the clear or included in log output.

Yes. Administrators can make TOTP multi-factor authentication mandatory for every member of the account.

Every webhook is signed with HMAC-SHA256 and timestamped. Verify the signature with your secret, which you can rotate at any time.

Completely. Separate credentials, separate configuration, and no crossover between the two environments.

Events are queued and retried automatically. You can inspect every delivery attempt, including status, response code, and the exact payload.