Security
SubCharge stores payment tokens and the credentials to your provider account. We treat a breach of either as the most serious possible incident, and design around it accordingly.
Money never touches SubCharge
Every payment add-on is bring-your-own-account: your customers pay directly into your own PayFast, Paystack or Peach Payments merchant account. SubCharge never holds funds and never sees a card number.
Zero PCI scope, not just SAQ A
Hosted checkout only ever renders a redirect to your provider's own payment page — never a card-touching form or script embedded on our page. That keeps SubCharge out of PCI scope entirely, rather than relying on a lighter self-assessment tier.
Envelope encryption for every secret
Payment tokens and provider credentials are encrypted at rest with AES-256-GCM under a per-tenant data key, itself wrapped by a master key. Decrypted values exist only in memory for the duration of a single operation — never logged, never returned by any API response.
A trust boundary around every add-on
A payment add-on runs in-process but gets no database handle and no unrestricted network access — only a host-allow-listed fetch scoped to that one provider. Add-ons are first-party code we review; there is no third-party add-on marketplace.
Idempotent, exactly-once charging
A charge is initiated at most once per invoice attempt. An outcome we can’t confirm is resolved before anything is ever retried, and every automatic charge is bounded by guardrails and a kill switch — per tenant and platform-wide.
Multi-factor authentication for your team
Staff sign-in requires two-factor authentication (TOTP) before an add-on can be enabled or its credentials replaced. Every staff action against tenant data carries an actor and a tenant scope — a cross-tenant request always returns not found, never merely forbidden.
Reporting a vulnerability
A disclosure contact and process will be published here before launch. In the meantime, see our privacy policy for how to reach us.