The safest sensitive data is data Palyra never receives.
Non-custodial by designSecurity
Security starts with collecting less.
Palyra is designed for sanitized payment-operations evidence. Cardholder data and provider credentials do not belong in the product.
Data boundary
Bring operational evidence, not payment secrets.
Palyra limits its data boundary to what is needed to understand payment-route performance and operating exceptions.
Accepted
Sanitized operational evidence
Payment, fee, settlement, and exception records needed to understand route performance.
Not accepted
Card data and provider credentials
Palyra is not designed to receive PAN, CVV, payment credentials, API secrets, or authentication tokens.
Workspace evidence
Normalized inside the workspace
Imports are validated and normalized into tenant-scoped records. Raw files are not attached to walkthrough or feedback submissions.
Access and handling
Clear controls at every entry point.
Public forms, account creation, authenticated imports, and workspace operations follow separate validation and access paths.
Verified account access
Email verification, password sign-in, and workspace membership are required before persistent workspace records can be viewed.
Organization-scoped records
Workspace records are scoped to the current organization, with tenant boundaries enforced at the data layer.
Bounded inputs
Public and import-workspace inputs are validated, size-limited, and rejected when they contain recognizable card-data fields.
Server-held secrets
Provider secrets and privileged platform credentials are not part of browser-delivered configuration. Connections are designed around scoped, server-side secrets and least privilege.
Normalized-only import retention
The controlled import path validates content before commit and stores normalized evidence, provenance, mapping version, and content digests—not uploaded file bytes or raw provider payloads.
Immutable decision and action history
Route policies, approvals, action receipts, and evidence references are modeled as workspace-scoped records so an operational change can be reviewed after the fact.
Deletion and retention boundaries
Workspace evidence remains attached to its organization until an authorized removal or deletion process applies. Formal customer retention schedules are agreed before recurring production connections are activated.
No silent AI execution
Intelligence is limited to scoped evidence and explicit uncertainty. A model explanation cannot activate a routing, retry, payout, or provider change without the required approval path.
Data flow
The boundary stays visible from ingress to action.
Available and preview stages are labelled separately. A recurring provider connection or execution path is not treated as live until its mapping, access scope, and failure controls are verified.
01
Available
Sanitized source
Merchant-owned operational evidence enters through the controlled import bridge.
02
Available
Validate and scope
Sensitive fields are rejected; accepted records are normalized and tied to one workspace.
03
Available
Reconcile and explain
Deterministic systems compute lifecycle, settlement, fee, and exception facts before Intelligence interprets them.
04
Preview
Approve and act
Policies, approvals, limits, circuit breakers, rollback, and action receipts govern future execution.
Role and tenant boundary
Authenticated reads are checked against workspace membership. Operator actions require a stronger workspace role than viewing evidence.
Retention before activation
Palyra does not publish a one-size-fits-all production retention promise. Data classes, deletion procedure, and operational replay needs are agreed before recurring connections go live.
AI context minimization
Model-backed analysis is optional and receives only the scoped evidence required for the question. Deterministic calculations remain the source of payment facts.
Assurance
Claims stay within the controls we can evidence.
Palyra does not claim certifications it has not completed. Hosted access uses encrypted web transport and managed infrastructure, but customer-specific requirements, recovery objectives, data residency, retention, and independent assurance must be reviewed before production connections are activated.
Security contact
Report a security concern.
Send a concise description to hello@palyra.io. Do not include credentials, cardholder data, or customer records.
Review Palyra against your security requirements.
Discuss data handling, access boundaries, and deployment requirements before introducing customer data.