Skip to content

ithappens / SmoothReturns security

SmoothReturns security

This page describes the infrastructure and data processing in SmoothReturns. AMED uses a different technical architecture and is not covered by this page.

This is a translation provided for convenience. The Norwegian version at ithappens.no/sikkerhet is the legally binding text.

In short

  • Each merchant is isolated in the database at schema level, not only in the queries.
  • Sensitive settings are encrypted with AES-256-GCM before they are stored.
  • Sign-in uses short-lived tokens and httpOnly cookies, not passwords held in clear text.
  • A data processing agreement is available on request and is signed before we start.
  • Storage of return data is inside the EEA. Two supporting services, outbound email and administrator sign-in, run from the USA on the basis of the EU Standard Contractual Clauses.
  • We are not ISO 27001 certified and not SOC 2 certified. See the section on certifications for what we offer instead.

Isolation between merchants

The portal is multi-tenant: several online shops share the same application and the same database. That makes isolation the most important security control in the system, and it is built in two layers.

Every database query goes through a shared function that forces in the merchant's tenantId. In addition, hooks on the data models themselves block any write or any read that lacks a valid tenantId. A developer who forgets to scope a query therefore does not get data from the wrong merchant: the query fails instead. The value "default" is explicitly forbidden as a tenantId.

Encryption

In transit: all traffic runs over HTTPS/TLS. The portal sends HSTS, and API calls to Shopify, carriers and the warehouse system run over TLS.

At rest: sensitive merchant settings, meaning API keys, carrier agreements and integration secrets, are encrypted with AES-256-GCM using a random initialisation vector and an authentication tag per value, before they are written to the database. The encryption key lives in environment variables, never in the code base.

Access and authentication

  • Administrator sign-in uses an access token with a 15 minute lifetime and a refresh token stored in an httpOnly cookie, so the token cannot be read from JavaScript.
  • The end customer's return flow requires the order number combined with the email address on the order. There is no account and no password to leak.
  • All administrator endpoints pass through shared authentication middleware that sets the merchant context before any business logic runs.
  • Only one person has production access today. See "Operational continuity" below.

Where the data lives

All storage of return data takes place within the EEA. The application, the database and error monitoring are in the EU/EEA. Two supporting services are operated from the USA on the basis of the Standard Contractual Clauses.

ComponentSupplierRegion
ApplicationHeroku (Salesforce)EU, Ireland
Database and backupsMongoDB AtlasEEA, Stockholm, Sweden
Error monitoringSentryEU, Germany
Outbound email to the end customerSendGrid (Twilio)USA, transfer on the basis of the Standard Contractual Clauses
Sign-in for administratorsStytchUSA, transfer on the basis of the Standard Contractual Clauses. Applies to the merchant's own staff users, not to end customers.

In concrete terms: your return data is stored in Sweden. When the portal sends an email to the customer, for example a return confirmation or a shipping label, the name and email address pass through SendGrid in the USA on the basis of the EU Standard Contractual Clauses. That is the only routine transfer of end customers' personal data out of the EEA.

Photos that a customer uploads with a warranty claim are stored as files in GridFS inside the same MongoDB database in Sweden. They do not go to a third-party image CDN.

MongoDB Atlas takes daily automatic backups, stored in the same region as the database. Retention period and recovery objectives (RPO/RTO) are specified in the data processing agreement.

Sub-processors

We keep a complete, dated list of all sub-processors, with country, which data they receive and their own certifications, on a separate page:

See the full list of sub-processors →

Existing customers are notified at least 30 days before we start using a new sub-processor, and you can object within that period. The terms are set out in the data processing agreement.

What personal data the portal processes

Only what is needed to complete a return: name, email address, delivery address, order number, order lines, return reason, and for warranty claims any photos the customer uploads. The portal does not store card numbers or other payment details. Refunds are carried out by Shopify against the original payment.

Certifications

ithappens is not ISO 27001 certified and not SOC 2 certified.

The following documentation is available:

  • A signed data processing agreement before we start, with the sub-processor list as an annex.
  • Written answers to your security questionnaire. We complete supplier assessment forms.
  • A walkthrough of the specific measures above together with your IT lead.
  • A reference to existing customers who have run the same assessment.

If formal certification is mandatory, SmoothReturns is not currently a fit.

Operational continuity

One person has production access today. Continuity is handled as follows:

  • All source code and infrastructure configuration is under version control and can be transferred.
  • The system is built on standard components, Next.js, MongoDB and Shopify's API, not on bespoke infrastructure that requires specialist knowledge to operate.
  • You own your own data and can ask for a full export in machine-readable format at any time.
  • The integrations with Shopify and the carriers use your own agreements and your own keys, which you can revoke without any involvement from us.
  • We are happy to agree an escrow or transfer clause in the contract if that matters to you.

Incidents and notification

If we discover a breach of security affecting personal data, we notify affected customers without undue delay and at the latest within 24 hours of becoming aware of it, as committed in clause 10 of the data processing agreement. That deadline is deliberately shorter than your own 72 hour deadline under Article 33 of the GDPR, so that you have real time to assess whether to notify the supervisory authority. The notification describes what happened, which data is affected and what we are doing about it.

If you have found a vulnerability, report it to henrik@ithappens.no. We reply within two working days and we do not take legal action against anyone who reports in good faith.

Requesting documentation

For the data processing agreement, the sub-processor list or a completed security questionnaire, send an email to henrik@ithappens.no and you will have it within two working days. See also the privacy policy and the data processing agreement.

The contracting entity is SillySanta AS, org. no. 916 896 050 MVA, Lilletorget 1, 0184 Oslo, Norway.

Questions about this?Talk directly with the person who builds the products.