Reback is built to keep your account, your money and your data safe. Here is how we protect them, described honestly — including the areas we are still formalising.
1. Our approach to security
Reback handles money and sensitive identity data, so security is fundamental to how we build. We follow security best practices across our applications and infrastructure, apply defence-in-depth, and design money-moving flows to fail safely. This page describes the measures we have in place. It is a plain-language summary, not an exhaustive specification, and our controls evolve over time.
2. Encryption
- In transit: traffic to and from Reback is protected with TLS/HTTPS. In production, non-secure origins are rejected.
- At rest (files): uploaded documents and evidence are stored in private cloud storage with server-side encryption (AES-256).
- Credentials: passwords and PINs are never stored in plain text. They are hashed with bcrypt and are never returned by our APIs.
The full scope of encryption at rest for the primary database and backups, and any field-level encryption of specific data categories, is [to be confirmed by security/compliance].
3. Authentication and access controls
- Account sign-in uses signed tokens (JWT) with expiry, and sign-in with Google is supported.
- Sensitive actions require step-up authentication — for example a PIN and a one-time passcode when adding a payout destination or withdrawing funds.
- Buyers use a dedicated PIN with lockout after repeated failures.
- Payouts use a maker-checker (four-eyes) control: the person who requests a withdrawal cannot be the one who approves it.
- Access to functionality is governed by role- and relationship-based authorization.
4. Payment and card data security
Card payments are handled by our PCI-DSS-compliant payment processors. Reback does not store your full card number. Card details are captured and tokenized by the processor; we retain only a token and limited metadata such as the card brand and the last four digits, which reduces the sensitivity of the data we hold. Bank and mobile-money payout destinations are verified with our partners before use, and the account name is resolved by the provider rather than accepted from the client.
Reback’s own PCI-DSS scope and SAQ type are [to be confirmed by compliance]. We do not claim any specific certification for Reback here until it can be verified; card data is handled by processors that maintain PCI-DSS compliance.
5. Escrow and fund handling
Funds held in escrow are separated from a seller’s available balance and are not withdrawable until the transaction reaches a released state (see our Terms). Fund movements — escrow holds, releases and refunds — and dispute decisions are written to an append-only, tamper-evident audit ledger that is enforced at the database level and is not editable or deletable after the fact. Before any payout leaves the platform, the beneficiary is screened against sanctions and watchlists, and the payout is blocked if screening cannot be completed.
6. Fraud and abuse prevention
- Device-GPS location is required for certain money-moving actions and is compared with IP-based location as a fraud signal.
- Sanctions and watchlist screening runs on the money-out path and fails closed (a payout is blocked if it cannot be screened).
- Money-moving API requests use idempotency controls to prevent duplicate charges or payouts on retries.
- Suspicious activity can trigger holds, additional verification, or account restrictions.
7. Application and infrastructure security
- Secrets management: credentials and API keys are stored in a managed secrets service (AWS Secrets Manager) rather than in source code, and secret access is logged.
- Private storage: file storage uses private buckets with public access blocked; documents are served through short-lived, signed URLs rather than public links.
- SSRF protection: outbound requests to user-supplied URLs pass through a guard that blocks access to internal and private-network addresses.
- Origin controls: cross-origin access is restricted to an explicit allowlist, and session cookies are set with the Secure, HttpOnly and SameSite attributes.
- Input and query safety: user-supplied sort and query parameters are validated against allowlists to prevent injection.
8. Logging, monitoring and auditing
We maintain audit logs of security-relevant and financial events, including an immutable ledger for fund movements and dispute outcomes, and generate alerts for events such as a blocked, sanctioned payout. We monitor our systems for errors and anomalies.
Details of our security monitoring, incident-response process, and breach-notification commitments are [to be confirmed by security/compliance].
9. Availability and resilience
Reback runs on managed cloud infrastructure. Our specific backup, disaster-recovery, and availability (uptime) commitments are [to be confirmed by operations/compliance].
10. Your role in security
Security is shared. Please use a strong, unique password, keep your PIN and one-time codes private, keep your devices and email account secure, and be alert to phishing. Reback will never ask you for your password or full one-time code. If you notice anything suspicious about your account, contact us immediately through the support portal.
11. Responsible disclosure
We welcome reports from security researchers. If you believe you have found a vulnerability, please report it to us privately and give us a reasonable opportunity to investigate and fix it before any public disclosure. Please do not access, modify or delete data that is not yours, degrade the service, or violate the privacy of others while testing.
- Or report through the Reback support portal.
A formal vulnerability-disclosure policy, safe-harbour terms, and any bug-bounty scope are [to be confirmed by security/compliance].