Data inventory
What nullpay. stores. What it doesn’t.
Every data field, which system holds it, how long it’s kept, and what third parties in the chain can see.
Payment system
Records who paid and how much. Does not record which service.
| Field | Stored | Retention |
|---|---|---|
| Customer ID (from payment processor) | Yes | Duration of service + legal requirements |
| Amount paid | Yes | Duration of service + legal requirements |
| Denomination breakdown | Yes | Duration of service + legal requirements |
| Timestamp (batch granularity) | Yes | Duration of service + legal requirements |
| Payment processor reference | Yes | Duration of service + legal requirements |
| Blinded token (for recovery) | Yes | Until token is redeemed or expired |
| Which service was chosen | No | — |
| Original (unblinded) token | No | — |
| User IP address | No | — |
Redemption system
Records which token was redeemed for which service. Does not record who redeemed.
| Field | Stored | Retention |
|---|---|---|
| Token hash (double-spend prevention) | Yes | Permanent (prevents reuse) |
| Service selected | Yes | Duration of service |
| Voucher code issued | Yes | Duration of service |
| Timestamp (batch granularity) | Yes | Duration of service |
| Customer identity | No | — |
| Payment reference | No | — |
| Card details | No | — |
| User IP address | No | — |
What third parties see
Each party in the payment and redemption flows has a limited view. No single party holds the complete picture.
Payment processor
Sees
- Card details (number, expiry, CVC)
- "NullPay SAS" as merchant name
- Amount charged
- Device fingerprint and IP (for fraud prevention)
Does not see
- Which service was chosen (selection happens at redemption, which the processor has no involvement in)
- Token data
Your bank / card network
Sees
- Your name
- "NullPay SAS" as merchant
- Amount and date
- Merchant category code (MCC)
Does not see
- Which specific service you subscribed to
- When you redeemed (separate flow)
CDN / hosting (payment side)
Sees
- IP addresses connecting to payment endpoints
- Request volume and timing
Does not see
- Decrypted request bodies (TLS termination at origin)
- Redemption traffic (separate infrastructure)
CDN / hosting (redemption side)
Sees
- IP addresses connecting to redemption endpoints
- Request volume and timing
Does not see
- Payment traffic (separate infrastructure)
- Who paid for the token being redeemed
The privacy service (voucher provider)
Sees
- A valid voucher code was activated
- Subscription is active
Does not see
- Who purchased the voucher
- That NullPay was involved
- Card details or customer identity
Server logs
Payment server
Application-level request logging for error diagnosis. No token content, no blinding factors, no service selection.
Redemption server
Configured to not log: IP address, User-Agent, Accept-Language, TLS session info, or any request headers beyond Content-Type. Timestamps stored at batch granularity only.