Voltage Security: SOC 2, Payment Controls, and Production Readiness

Give Your Security Team Something It Can Verify

A payment integration has to pass more than an engineering test. Your security team needs to understand access. Finance needs a reliable record of funds. Compliance needs to know which checks happen and who handles exceptions.

We make that review concrete: SOC 2 Type II status, published security controls, documented access boundaries, and a public service-status history. Here is what those mean for a Voltage deployment.

SOC 2 Type II Is a Starting Point

Voltage has achieved SOC 2 Type II, with the status available in our Trust Center.

Type II addresses how controls operated over an audit period. It is not a promise that a system can never fail, and it does not make every customer's business compliant by association.

For procurement, ask our security team for the latest report and confirm its review period, covered services, exceptions, and customer responsibilities against the product you plan to use. Those details belong in the review, not behind an assumption that a badge answers everything.

Security Controls With a Clear Purpose

Our published controls cover the areas an enterprise should expect to examine:

• Encryption of sensitive customer data at rest and in transit over public networks.
• Restricted privileged access to production systems, databases, and encryption keys.
• Access removal when employees leave.
• Vulnerability-management and system-monitoring procedures.
• Third-party web application security scans on a semiannual basis.
• Business continuity and disaster recovery plans tested at least annually.

These controls help protect the service. Your implementation also needs the right permissions and a recovery plan suited to the way you use it.

Know Which Credential Controls What

There is no single credential that should do every job.

In our access model, team permissions govern human dashboard access. Payments API keys govern application access within one environment. Infrastructure API keys manage supported hosted-node workflows. Direct LND access uses separate node credentials and macaroons, which authorize specific node operations.

That separation matters. A service reading payment status does not need the same access as a service sending funds or a person managing node recovery.

There is an important detail for security reviews: Payments API keys are environment-scoped, but human dashboard permissions are team-level. Separate staging and production API keys do not, by themselves, isolate a person's dashboard access. Use a separate team boundary when that human-access separation is required. The Payments access guide explains the distinction.

Production keys should stay in a secrets manager, carry the narrowest necessary permissions, and use IP restrictions where practical. Webhook signing secrets are separate credentials and should be handled accordingly.

Custody Depends on the Operating Model

The node-backed path uses a customer-controlled node and reserve. Node credentials, recovery material, funding, and liquidity responsibilities need named owners. Follow the node security guidance for credential separation and the supported recovery process.

The credit-backed path lets eligible businesses use the Payments API without operating the underlying Lightning node. It has its own funding and contractual arrangement. It should not be described as identical to customer-controlled node custody.

We work through that choice before launch. Hosting, payment access, and control of funds are related, but they are not interchangeable.

Compliance Tooling Supports Your Program

Voltage provides Lightning risk checks and access to payment records that can support your compliance workflow.

Our risk-management documentation explains the Amboss Reflex checks for invoices, node public keys, and Lightning addresses, including sanctions-related checks where the relevant data is available. It also describes how to access transaction data and integrate other compliance tools.

A check can pass, fail, be skipped, or return an error. Your team needs an explicit policy for each outcome. A skipped check is not the same as a clean result.

Screening does not replace customer due diligence, licensing analysis, or your broader compliance obligations. Define those responsibilities for your business, jurisdictions, and payment flow with your compliance team.

Availability Should Be Visible

Our public status page reports service availability and incident history by component. On Sep 17, 2026, it displayed 100.0% uptime for the Payments group across its displayed 90-day window.

That is an observed status-page figure, not a guarantee of future availability or a claim that every attempted payment succeeds. API availability, payment completion, and downstream bank settlement measure different things.

Review the current history and the service commitments in your agreement. Confirm the covered components, support escalation path, maintenance terms, and incident responsibilities before launch.

A Production Launch Is a Shared Readiness Check

Before moving live, agree on five things:

1. Who can administer the account, move funds, and access recovery material.
2. How the application verifies payment completion and reconciles its ledger.
3. What happens when screening fails or cannot complete.
4. How balances, transaction limits, and liquidity will support expected volume.
5. Who responds to an incident, and how the business continues operating.

Test those decisions in staging, then validate the approved production flow with controlled transactions. That gives security, engineering, and finance a shared basis for saying the integration is ready.

Book a strategy session to review your deployment. For security diligence, reach us at security@voltage.cloud.