How to think about data protection (anonymization and encryption)
For developers and operators who store and process, on their own infrastructure, data retrieved from ReceiptRoller.
The data you retrieve from ReceiptRoller includes sensitive information such as a store's sales information and consumers' purchase history. Rather than "it's fine because ReceiptRoller encrypts it", it is the integration app developer's responsibility to protect it properly on your own infrastructure once you have received it.
Three layers of protection
| Layer | Measure |
|---|---|
| In transit | TLS 1.2 or higher, HTTPS enforced, HSTS |
| At rest | DB encryption (AES-256), disk encryption, backups encrypted too |
| Processing | Access control, log masking, least privilege |
Minimizing the data you retrieve
Retrieve only the data you need. Just because you can read all of receipt.* does not mean you need to store every field. For example, if the purpose is aggregation, you can decide to store only the amount, date/time, and store ID and discard the line items if they are not needed.
Anonymization and pseudonymization techniques
Pseudonymization
Replace the customer ID with a separate ID inside your own system and store that. Manage the mapping table to the original ID separately, so the original ID is not visible from the analysis environment.
// ReceiptRoller's cus_xxx → your own internal_user_yyy // Manage the mapping table in a separate DB with separate access permissions
Hashing
For information such as email addresses or phone numbers that you use for matching but do not need to hold in plaintext, hash it with SHA-256 or similar and store that.
Differential privacy
If you only need to produce aggregate values, add noise to make individuals unidentifiable. For academic / large-scale data.
Choosing the right encryption approach
| Purpose | Method |
|---|---|
| Whole DB | TDE (Transparent Data Encryption) |
| Specific columns (email, etc.) | AES-256-GCM at the app layer |
| Backups | SSE-KMS on cloud storage |
| Files in transit | PGP / age |
Manage keys separately in a secret management service. Do not put them in the same repository as your code.
Log masking
To keep personal information out of operational logs and error logs, apply masking at output time.
// Masking an email "user@example.com" → "u***@example.com" // Partially masking an ID "cus_abc123def456" → "cus_abc***456"
Deletion policy
- Delete once the purpose is served: aggregate data whose analysis is complete, users who have left
- Responding to deletion requests: physically delete within 30 days (backups on a separate policy)
- Automatic TTL: set an expiry on DB records and auto-delete once it passes
- Audit: keep a deletion log and record deletion completion