Payment persistence needs field-level protection

What the public implementation shows

The PostgreSQL package includes encryption converters and an encryption helper alongside transaction, ISO message, response, and status persistence.

Field protection is implemented in the persistence layer while application services continue to work with typed domain values. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleAuditability and confidentiality must be designed together in the data model.

The decision behind the mechanism

Central conversion reduces the chance that one write path stores a sensitive value in plaintext while preserving queryable non-sensitive control fields.

Encrypting an entire record can destroy operational usefulness; encrypting nothing turns a diagnostic database into a concentration of sensitive data. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Keep encryption keys outside application configuration files.
• Use stable converters for every protected write and read path.
• Leave only required lookup fields searchable.
• Apply authorization and masking after decryption.

How the control should be operated

Data classification should decide which fields are encrypted, hashed, masked, retained, searchable, and exposed by operational APIs.

The store can support reconciliation and incident review without unnecessarily exposing participant or party data. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.