Engineered for clarity. Built for review.
A summary of the controls, classifications, and architectural decisions that define SnappyPay Systems’s operating posture. This page is intended both for customers asking how their data is protected and for reviewers evaluating the platform.
Operating classification and merchant identity.
| Legal entity | SnappyPay Systems |
|---|---|
| Merchant of record | SnappyPay Systems for every customer card transaction. |
| Product sold | One‑time digital redemption codes, delivered electronically at the moment of customer purchase. |
| Geographic scope | United States and Canada only. Orders outside this scope are rejected at order creation. |
| Card data scope | SAQ‑A. Card capture is performed by an external PCI‑DSS Level 1 service provider. |
Card details never reach SnappyPay Systems infrastructure.
Capture is performed by an external PCI‑DSS Level 1 tokenization service. SnappyPay Systems receives only an opaque token, never the raw card number.
What this means in practice: A compromise of SnappyPay Systems’s servers does not expose cardholder data. Card details exist only inside the external PCI‑DSS Level 1 tokenization service. SnappyPay Systems holds tokenized references that cannot be used to initiate a charge without the same authenticated request path.
Multiple, independent checks on every purchase.
Authorization combines acquirer‑side verification with an out‑of‑band cardholder confirmation, producing a strong record of intent.
3‑D Secure 2
Cardholder authentication through the issuing bank is supported on participating networks. Rollout is calibrated to acquirer guidance and cardholder experience.
AVS
Address Verification Service checks are performed against the cardholder’s billing address on every authorization, where supported by the issuer.
CVV verification
Card Verification Value checks are performed on every authorization. CVV is never stored after the authorization completes.
Out‑of‑band confirmation
Each purchase is confirmed by the cardholder through an independent link delivered to a verified email address or mobile phone number before settlement.
Geographic enforcement
Billing and shipping addresses are checked against the platform’s approved geographic scope (United States and Canada) before any card authorization is attempted.
Velocity controls
Transaction velocity is monitored at the customer, IP address, and gateway level. Patterns consistent with card‑testing or unauthorized activity trigger automatic throttling.
Layered defenses against unauthorized activity.
The platform combines network‑edge controls, gateway‑edge controls, and application‑edge controls. Each layer is independent.
Restricted gateway access
Acquirer gateway calls originate only from a tightly controlled set of authorized egress IP addresses. Traffic from any other origin is rejected at the network edge.
Velocity monitoring
Customer, IP, and gateway‑level velocity is tracked continuously. Configurable thresholds trigger throttling and blocking on patterns inconsistent with normal commerce.
Anomaly detection
Rule‑based anomaly detection flags transactions inconsistent with the cardholder’s prior pattern, the participating merchant’s pattern, or normal platform activity.
IP blocklisting
Persistent or repeated offenders are added to an IP blocklist that rejects new authorizations at the platform edge before processing begins.
Code lifecycle integrity
Each redemption code is uniquely tied to a single purchase. Codes are validated at the moment of application, invalidated immediately on successful redemption, and cannot be reused.
Customer blocklist
Customers with confirmed unauthorized‑use history or repeat dispute abuse are restricted from new purchases via a maintained customer blocklist.
An auditable transaction trail.
Every transaction event is recorded in an append‑only ledger. Original facts are never overwritten. Refunds, retries, and lifecycle changes are recorded as separate events linked to the original transaction.
This architecture produces a complete, time‑ordered audit trail for any transaction without requiring reconstruction from operational logs.
- Order creation records customer, amount, participating merchant, IP, and time.
- Card authorization events record acquirer, response code, and authorization identifier.
- Magic Link confirmation events record verification channel, time, and confirmation token.
- Code lifecycle events record issuance, application, and invalidation independently.
- Refund and dispute events are appended without altering original records.
How we align with industry standards.
- PCI DSS — SAQ‑A scope. Card capture and storage are managed by an external PCI‑DSS Level 1 service provider. SnappyPay’s scope is limited to the tokenized reference and the merchant’s own infrastructure.
- NACHA Operating Rules. Bank‑transfer (ACH) authorizations are taken in compliance with applicable NACHA standards. See our Terms of Service for full ACH authorization language.
- Cardholder data confidentiality. Personal information is collected and retained only as needed for transaction completion, recordkeeping, and dispute resolution. See our Privacy Policy.
- Geographic alignment. Customer purchases are accepted only from billing and shipping addresses in the United States and Canada.
For compliance review: A full underwriting package, including detailed transaction flow, redemption‑code lifecycle, control inventory, and disclosure language, is available to acquirer review teams upon request. Please contact Compliance@SnappyPay.com
Questions about controls or compliance?
Acquirer review teams and merchant compliance contacts can reach us directly.