Security and Privacy at Nexa OFS

Security is not a feature page on Nexa OFS; it is a set of constraints the platform is built inside. Card data is handled by the payment gateway rather than stored in the marketplace. Every database record is protected by access rules evaluated per request. Staff see only what their role allows. This page explains, in plain terms, how the protections work and what they mean for shoppers and sellers.

Key takeaways

  • Full card numbers are not stored in the marketplace application.
  • Payment data is transmitted over encrypted connections to the payment gateway.
  • Database access is enforced per row, per user, on every request.
  • Sellers control staff permissions granularly.
  • Personal data is collected for order fulfillment and support, not sold.

How payment data is handled

When a shopper enters card details at checkout, those details travel over an encrypted connection to the payment gateway that performs the authorization. The marketplace application does not retain full card numbers. What the platform keeps is what it needs to service the order: the transaction reference, the approval status, the amount, and a masked descriptor such as the card brand and last four digits.

This design matters because the most effective way to protect card data is to not hold it. Refunds, captures, and recurring charges are performed by referencing the gateway's transaction record rather than by re-submitting stored card numbers from our systems.

Account and access security

Accounts are protected by standard authentication with password strength requirements and support for social sign-in. Sessions are scoped and can be ended by signing out. Sensitive actions in seller and administrative areas require an authenticated session with the right role, checked on the server rather than in the browser.

Row-level security
Access rules are enforced in the database itself, per row and per request, so a user can only read or change records that belong to them even if a request is crafted by hand.
Role-based permissions
Roles such as owner, staff, and administrator carry defined capabilities. Roles are stored separately from user profiles so they cannot be modified by editing a profile field.
Server-side verification
Every privileged action is authorized on the server. Nothing important is trusted because the browser said so.
Scoped staff access
A store owner can grant a staff member exactly the capabilities they need — fulfillment and labels, for example — without exposing revenue or payout settings.

What data the platform collects

The platform collects the information required to run commerce and support the people using it. That falls into a small number of categories, and each has a purpose tied to delivering the service.

  • Account information: email address, name, and authentication details used to sign in and recover access.
  • Order information: items purchased, shipping and billing addresses, and order status needed to fulfill and support the sale.
  • Payment metadata: transaction references and masked card descriptors, not full card numbers.
  • Merchant information: business and banking details supplied for underwriting and funding.
  • Usage information: activity needed to operate, secure, and improve the service, such as error reports and aggregate analytics.
  • Optional content: photos a shopper uploads for virtual try-on, retained for that shopper's own gallery and removable by them.

What the platform does not do

  • It does not sell personal information to data brokers.
  • It does not store full card numbers in the marketplace application.
  • It does not expose seller cost data, payout details, or gateway credentials to shoppers or other sellers.
  • It does not allow AI assistants to read data outside the permissions of the person using them.

How AI features handle your data

The shopping assistant reads public catalog information — products, prices, availability — and the conversation you are having with it. The seller assistant reads that seller's own business data. Neither can reach across into another account's records, because the same access rules that protect the dashboard also protect the assistant's queries. AI features are used to answer questions and generate content for the account that requested them.

Ongoing security practice

Security is maintained rather than achieved once. The platform runs automated scanning against its database access rules and application dependencies, and findings are triaged and resolved. Error monitoring surfaces runtime failures quickly, which matters because an unnoticed failure is often the first step in a security incident.

Practical advice for shoppers and sellers

  • Use a unique, strong password and enable social sign-in if you prefer not to manage another credential.
  • Sellers: grant staff the narrowest role that lets them do their job, and remove access when someone leaves.
  • Check that the address bar shows the correct Nexa domain before entering payment details.
  • Review order confirmations and report anything unexpected promptly — early reports resolve faster.

Frequently asked questions

Short, direct answers to the questions people most often ask about this topic.

Continue through the Nexa OFS Knowledge Center.

Core pages across the Nexa ecosystem.

Looking for something else? Browse the full Nexa AI Knowledge Center.