Card data

The card form encrypts card details in the shopper’s browser before sending them. Live card and bank numbers are encrypted at rest with keys held in hardware security modules. Bias stores a card number only while a merchant needs to charge the card again, and deletes it when that need ends. The CVC is never stored.

The dashboard and API never show a full card number. Card fingerprints let merchants recognize a repeat card without seeing its number.

Secure connections

Bias serves its API, dashboard and checkout only over HTTPS, with TLS 1.2 or later and HSTS.

Account security

Dashboard users sign in with a passkey or a one-time code sent by email, not a password. Owners and admins choose what each team member can do. The request log records every change made through the API or dashboard, with who made it and when.

Sandbox and live API keys are separate, and merchants can replace either at any time. Bias stores API keys, login codes and session tokens only as hashes.

Merchant separation

Each merchant’s API keys and dashboard sessions reach only the merchants they belong to. The backend refuses requests for any other merchant’s data, and card numbers are encrypted with the owning merchant bound in, so they decrypt only for that merchant. Automated tests try to reach one merchant’s data as another on every backend change, and a deploy goes out only after they pass.

When Bias support acts in a merchant’s dashboard, Bias records which staff member made each change.

Infrastructure

Only named administrators can change production, and every change they make is logged and posted to a security channel. Production audit logs can’t be edited and are kept for at least a year.

Code and infrastructure changes are reviewed before they reach production. Releases are scanned for known vulnerabilities before they deploy, running systems are scanned regularly, and an approved scanning vendor (ASV) scans the network every quarter.

People

Everyone at Bias is screened before getting access, takes security awareness training on joining and every year after, and signs in to internal systems with multi-factor authentication. Engineers also take secure coding training every year.

PCI DSS

The Terms of Use set out which parts of PCI DSS Bias is responsible for and which stay with the merchant. Merchants can ask security@biaspay.com for Bias’s compliance status and a list of the requirements that are Bias’s, theirs, or shared.

Merchants can test their own integrations against their sandbox accounts at any time. A penetration test that reaches live accounts or Bias’s systems is arranged in advance by email to security@biaspay.com, with the scope, dates, the testing firm and the addresses tests will come from. Bias confirms the rules of engagement before the test starts.

Reporting a vulnerability

The security team accepts reports through the report form or by email at security@biaspay.com. Email reports can include attachments such as proof-of-concept code or screenshots.

Report a vulnerability

A useful report includes:

• A description of the vulnerability and its impact
• Steps to reproduce it
• Your contact information

The security team acknowledges reports within 24 hours and keeps the reporter updated until the issue is resolved.

Safe harbor

Bias considers research under this policy authorized and won’t take legal action against it. Research stays under this policy when it:

• Uses sandbox accounts the researcher owns, and accesses no more of anyone else’s data than the vulnerability requires to show
• Avoids degrading the service, including through denial of service or high-volume automated testing
• Stays in scope
• Keeps findings private until Bias has fixed them

Scope

In scope: Bias web applications, APIs, the dashboard, and Bias-owned domains.

Out of scope: Third-party services that Bias integrates with, social engineering, physical attacks, and denial of service.