Security reporting

What to include

• A clear summary of the concern and the affected area (product surface).
• Steps that would help us understand and reproduce the issue, without unnecessary risk.
• Your assessment of impact, if you can share it in general terms.
• Contact information so we can follow up if we need clarification.

Testing guidelines

Please avoid testing that could impact availability, privacy, or customer data. Use test accounts and synthetic data when possible. Do not access or retain data that does not belong to you.

• Do not perform destructive testing against production systems.
• Do not disclose an issue publicly before we have had a reasonable opportunity to review it.
• Stop testing if you encounter sensitive customer data and report only what is needed to describe the issue.

Examples of reports we want to hear about

• Authentication or session handling weaknesses in Payra applications.
• Authorization flaws that could expose another customer’s data.
• Injection or data validation issues in public APIs or web surfaces.
• Misconfigurations that materially weaken transport or storage protections.

Out of scope

• Theoretical issues without a plausible path to impact.
• Reports from automated scanners without a specific, reproducible finding.
• Social engineering of Payra employees or customers.
• Third-party services outside Payra’s control, unless they clearly implicate our integration in a novel way.

Response process

After you submit a report, we aim to acknowledge receipt. We may ask follow-up questions. Timelines depend on severity, impact, and current workload. We do not guarantee a specific response time for every report.

This page describes responsible disclosure. A formal paid bug bounty program, if offered, would be described separately in official Payra policy. Do not assume compensation unless we confirm it in writing.