Security & Trust
at Every Layer
Industry-Leading Compliance
All data processed, transferred, and stored by SensePass adheres to PCI DSS and SOC 2 standards — across every integration path: in-store POS, e-commerce, SDK, and token migration workflows.
Payment Card Industry Security
The global framework for organizations that handle card payments. Level 1 is the highest tier, required for the largest volume processors.
- Cardholder data never stored post-authorization
- Secure card intake via iFrame & tokenization
- Network segmentation for cardholder data environment
- All data encrypted during transfer and at rest
- Sensitive payment data handled per PCI DSS requirements
Service Organization Controls
SOC 2 Type II audits evaluate the operational effectiveness of security controls over time — not just a snapshot. Our report is available to enterprise customers under NDA.
- Trust Service Criteria: Security & Confidentiality
- Report available upon request for enterprise integrations
- Controls tested over a 12-month period
- Annual third-party audit cycle with continuous monitoring
- SOC 2 controls covering security, availability, and confidentiality
Defense in Depth — Security at Every Layer
SensePass is designed with multiple independent security controls — so a single compromised layer never results in a breach.
Transport Encryption
All API communication uses TLS 1.3. WebSocket connections between SensePass devices and cloud services use Secure WebSocket (WSS) protocol, preventing man-in-the-middle attacks on every payment message route.
API Authentication
Three scoped authentication mechanisms (Device ID, Location API Key, Merchant API Key) ensure each integration point has only the minimum permissions it needs. Frontend SDKs use read-only client IDs — never full API keys.
HMAC Webhook Verification
Every server-to-server callback and webhook is signed using HMAC-SHA256. Merchants verify the signature before acting on any payment notification, preventing fraudulent callback injection.
Payment Tokenization
Raw card data is replaced with opaque tokens at point of capture. Merchants store and transmit tokens — never raw PANs — reducing PCI DSS scope and eliminating card data exposure risk throughout the transaction lifecycle.
SDK Privilege Separation
The JavaScript UI SDK enforces a strict two-tier security model: the client-side frontend uses a limited client ID with no payment capture permissions. Payment capture requires a backend call with a full server-side API key.
Device Pairing & Audit Logs
Each physical payment terminal undergoes a cryptographic pairing process before it can communicate with SensePass cloud services. All device events, connection states, and payment messages are logged with automatic transmission for audit trails.
HMAC Signature Verification
Every callback notification SensePass sends to your server is cryptographically signed. You must verify this signature before processing any payment update.
SensePass Signs the Payload
When sending a callback to your callbackURL, SensePass creates an HMAC-SHA256 signature using a shared secret and the raw request body.
Signature Delivered in Header
The computed signature is sent in the X-SensePass-Signature request header alongside the callback payload.
Your Server Verifies Before Processing
Recompute the HMAC on your side using the raw body and your secret. Compare with the header value using a constant-time comparison to prevent timing attacks.
Applies to All Callback Types
HMAC verification is implemented consistently across POS in-store callbacks, e-commerce callbacks, and the general Callback/Webhook API — ensuring the same trust guarantee everywhere.
Scoped API Authentication
SensePass uses purpose-specific authentication credentials — each scoped to the minimum permissions required for its use case. This limits the blast radius of any compromised key.
Device ID
Each physical POS terminal is uniquely identified by a Device ID generated during the cryptographic pairing process. The device cannot communicate with SensePass servers before pairing is complete.
Location API Key
The Location API Key identifies a specific merchant and location. It is the recommended authentication method for all e-commerce integrations, offering location-level permission scoping.
Merchant API Key
The Merchant API Key provides merchant-wide authentication and requires an additional branchNumber field to specify the target location. Deprecated in favor of Location API Keys for new integrations.
Payment Tokenization
SensePass replaces sensitive card data with secure tokens throughout the payment lifecycle. Raw card numbers never travel through merchant systems — eliminating one of the largest attack surfaces in payments.
Secure Token Migration
Migrate existing customer payment tokens to SensePass with full data encryption at every step. Merchants submit tokens via a structured encrypted file — raw card data never transmitted over open networks.
Merchant-Specified Token Continuity
If you have existing tokens from another processor, SensePass can map them directly — providing seamless migration without changing your token structure or disrupting recurring billing.
Reduced PCI DSS Scope
By handling raw card data exclusively within SensePass's PCI DSS certified environment, merchant systems never touch sensitive card data — dramatically reducing your compliance burden and liability.
Frontend SDK Security Model
The SensePass JavaScript UI SDK is architected so that sensitive payment operations never occur in the browser — they're committed server-side, where your credentials are safe.
Frontend: Client ID Only
The browser-facing SDK is initialized with a Client ID that has no permission to capture or modify payments. Even if a Client ID is exposed in browser source code, no unauthorized payments are possible.
clientId → SDK init only · No capture permissionsBackend: Commit Requires API Key
Payment capture must be called from your server using a Device ID, Merchant API Key, or Branch API Key. These credentials never exist in the browser, ensuring payment finalization requires server-side trust.
deviceId / apiKey → Server-side commit onlyiFrame Isolation
The SensePass Elements SDK renders the payment form inside an isolated iFrame served from SensePass's PCI-scoped domain. Card data entry never touches your DOM, preventing skimming attacks.
js.sensepass.com · PCI-scoped domainWebSocket Communication
Physical POS devices communicate with SensePass cloud services via Secure WebSocket (WSS). Connections are authenticated by Device ID with exponential backoff reconnection.
WSS · api.sensepass.com · Device ID authReport a Security Vulnerability
Security researchers and partners are encouraged to report vulnerabilities responsibly. We investigate every report and aim to remediate critical findings within 24 hours.
Responsible Disclosure Policy
SensePass is committed to working with security researchers to identify and resolve vulnerabilities. We ask that you give us a reasonable opportunity to investigate and remediate before any public disclosure.
- Report the vulnerability to security@sensepass.com
- Include a detailed description and reproduction steps
- We acknowledge receipt within 24 hours
- We investigate and provide an estimated resolution timeline
- We notify you when the issue is resolved
- Coordinate public disclosure date with our team
Security Contact
Vulnerability reports & security inquiries
PCI DSS & SOC 2 report requests
Developer security documentation
Ready to Build on a Secure Foundation?
Get in touch to request our SOC 2 Type II report, discuss PCI DSS compliance requirements, or speak with our security team.
New York Office
260 Madison Ave Suite 8018 New York NY 10016
