How we protect it

Encryption, sign-in, roles, logs and the other locks around your data.

The path to your data

Think of it as a building with a locked door on every floor. Every request has to pass all of them.

1. An encrypted connection
Everything between a browser and REASONBACK travels over HTTPS, so nobody in between can read it.
2. REASONBACK’s server checks who you are
On every single request, the server checks that you’re signed in, which brand you belong to, and whether your role allows that action. It doesn’t trust anything the browser says about this.
3. A locked database
Every table is locked to browsers. Only REASONBACK’s server holds the key, so the database can’t be reached around the checks above. Each brand’s rows are kept apart by brand.

Shopify and Bosta keys: Encrypted (AES-256) before they’re saved, with a secret key kept outside the database. They’re only unlocked at the moment of talking to Shopify or Bosta, and never shown back to anyone.
Shopify access: Uses short-lived keys that renew themselves about every hour. If Shopify refuses them, the owner and admins are alerted to reconnect.
Messages from Shopify and Bosta: Checked before anything is read: Shopify’s signature must match, and Bosta must send our secret. Anything else is turned away.
Passwords: Stored only in scrambled (hashed) form by the sign-in service. You can also sign in with an email link instead of a password.
Two-step sign-in: A code from an authenticator app, on top of the password. Always required for the REASONBACK team. It’s built for owners, admins and finance too, but isn’t switched on for brand accounts yet.

Only finance (and managers, admins and the owner) can send a refund, and only after the box has been checked.
Only the owner and admins can connect Shopify, because it copies your customers’ details in, and change where a refund is sent.
Only the owner and admins can invite people or change roles.
A button your role can’t use is greyed out, and the server refuses it anyway if someone tries another way.

Every change to a request is written on its timeline: who, what and when. Edits list the old and new value, with InstaPay numbers shortened to the last three digits and bank accounts to the last four.
Refunds record who sent them, when, the reference and the proof.

The one refund REASONBACK sends itself, through Shopify, so it has extra checks.

Off until you switch it on, in Return rules → Refund methods.
Only offered when the money can really go back. REASONBACK checks the order’s payment with Shopify before showing it to a customer, and again when they submit. Cash on delivery, manual payments like a bank deposit, and gifts never get it.
Never more than Shopify can refund. The amount is worked out by REASONBACK, not typed, and refused if it’s more than is left on the order.
Never sent twice. A one-time lock is taken before Shopify is asked, so a double-click or a retry can’t send it again.
Refused means nothing was sent. The lock is released and the reason is written on the timeline.
An unclear answer keeps the lock. The timeline says to check the order in Shopify first, and the REASONBACK team sees it on our own error list too.
Only after the box is checked, and only by finance, managers, admins or the owner, like every refund.

A customer only sees an order after giving both its order number and the phone or email on it.
Too many wrong guesses and the portal makes them wait, so nobody can try order numbers one after another.
Photos are checked to be real images (JPG, PNG or WebP) from the file itself, not just its name.
A New request link your teammate opens only works for that teammate, while signed in, for 2 hours.

Found a problem?

If you think something isn’t as safe as it should be, message the REASONBACK team straight away. We’d much rather hear it from you.