Salewise

Seguridad at grounding

Ang tiwala ay mekanismo,
hindi badge.

Ang page na ito ang ebidensya: ano ang ipinapatupad ng system, ano ang iniimbak nito, sino ang makakaabot dito, at ano ang hindi pa namin nabuo.

Magtanong tungkol sa seguridadBasahin ang abiso sa privacy

Contact para sa seguridad

support@salewise.co.uk

Isama ang reproduction steps. Pakiusap na huwag i-access ang data ng ibang merchant o abalahin ang serbisyo.

Kasalukuyang kalagayan

  • Walang SOC 2 o ISO 27001 certification.
  • Wala pang independent penetration test.
  • Walang card data na hawak.

Ang maikling bersyon

Apat na claim, at kung saan nakatira ang ebidensya.

Hindi marketing adjective. Mga desisyon sa disenyo na may code sa likod.

01

Hindi kayang magtakda ng presyo ang modelo.

Tumatakbo ang retrieval bago ang generation. Pumipili ang modelo mula sa candidate ID; vine-validate ng server ang mga ito at mismo ang nagre-render ng presyo, stock at variant.

Basahin ang mekanismo

02

Naka-encrypt at rest ang provider secret.

AES-256-GCM, random IV bawat record, at additional authenticated data na nag-uugnay sa bawat ciphertext sa provider, account at integration record nito.

Basahin ang mekanismo

03

Walang card data na pumapasok sa Salewise.

Walang checkout at walang PAN storage. Nagpapasya ang mamimili sa telepono at nagbabayad sa kasalukuyang kahera ng merchant.

Basahin ang mekanismo

04

Naka-scope ang access, hindi ibinabahagi.

Sinusuri ang pagmamay-ari ng tindahan sa bawat store route. 15 minuto ang access token; ang refresh token ay naka-hash at nire-rotate kapag ginamit.

Basahin ang mekanismo

Nakaangkla mula sa pagkakabuo

Pumipili ang modelo. Nagre-render ang server.

Tumatakbo ang retrieval bago ang generation. Pumipili ang modelo mula sa mga kandidato; ang server ang gumagawa ng arithmetic at rendering.

01

Retrieval muna

Kinukuha ng server ang mga kandidatong produkto mula sa katalogo ng merchant bago tanungin ang modelo. Hindi kailanman naghahanap ang modelo sa open web.

02

Pumipili ang modelo. Ang server ang nagre-render.

Ang mga presyo, stock, variant at alok ay nire-render sa server mula sa mga talaan ng katalogo. Ang numerong nasa prosa ng modelo ay hindi kailanman ang source of truth.

03

Bine-validate ang mga ID

Bawat produktong pinipili ng modelo ay dapat umiiral sa nakuha na kandidatong set. Itinatapon ang mga invalid na ID bago makarating ang sagot sa mamimili.

04

Tapat na pagtanggi

Kung wala ang sagot sa katalogo, sinasabi ito ng agent at nag-aalok ng handover. Kapag walang naka-configure o hindi available ang modelo, sinasabi ng assistant na hindi ito makakasagot; puwedeng subukan ulit ng mamimili o magtanong sa staff.

Ano ang napupunta sa modelo

  • Ang tanong ng mamimili.
  • Isang set ng nakuha na kandidato mula sa katalogo.
  • Mga setting ng tindahan at ang relevant na teksto ng patakaran.

Ano ang hindi kailanman napupunta sa modelo

  • Card data o payment credential.
  • Password, API key o ang Salewise master key.
  • Tool na kayang magsulat sa POS.

Control ledger

Control ledger, hindi trust badge.

Pinangalanan ng bawat row ang kontrol, ang mekanismo sa likod nito, at kung saan ang hangganan. Kung kailangan ng questionnaire ng mas detalyadong sagot, magtanong.

Nakaangkla na sagot

Ang katalogo ang source of truth.

Kinukuha ng server ang kandidatong produkto bago tumakbo ang modelo. Maaari lang pumili ang modelo ng ID mula sa set na iyon. Itinatapon ang invalid na ID, at ang presyo, stock, variant at alok ay nire-render sa server. Kung walang sagot ang katalogo, sinasabi ito ng agent at nag-aalok ng handover.

Credential at rest

Naka-encrypt, naka-bound at may version ang secret.

Gumagamit ang provider credential ng AES-256-GCM na may random na 96-bit IV bawat record. Ini-uugnay ng additional authenticated data ang ciphertext sa provider:{providerId}:account:{accountId}:credentials, kaya nabibigo ang pag-decrypt ng record na kinopya sa ibang tenant. Sinusuportahan ng keyVersion ang key rotation; kapag nabigo ang decrypt, fail closed ito kaysa magbalik ng secret.

Mga request ng Salewise

May pirma, hindi bearer-only.

Ang mga request sa Salewise master API ay may HMAC-SHA256 signature sa method, path, timestamp, nonce at SHA-256 ng body. Inihahambing ang signature sa constant time at nililimitahan ng replay window. Nasa server-side ang master key, isang beses na naka-configure, naka-encrypt at rest at hindi kailanman ibinabalik sa browser.

Account at role

Ang merchant account ay hindi server admin.

May merchant at server-admin role ang Sage. Gumagamit ang password ng scrypt na may per-account salt. Nag-expire ang access token pagkatapos ng 15 minuto; ang refresh token ay naka-store bilang hash, nire-rotate kapag ginamit at nag-expire pagkatapos ng 30 araw. Nag-expire ang invite pagkatapos ng 7 araw at naka-bound sa inanyayahang email.

Tenant isolation

Ang store lookup ay ownership check.

Bawat store route ay nireresolba ang tindahan at sinusuri na pag-aari ito ng authenticated account bago magbalik ng data. Naka-scope ang repository method ayon sa account at tindahan, at ang SQL ay nasa likod ng repository layer, hindi sa route handler.

Card data

Walang payments, walang PAN.

Hindi tumatanggap ng bayad ang Salewise at hindi nag-iimbak ng card data. Walang checkout ang shopper PWA, at nananatili ang transaksyon sa POS ng merchant. Hindi namin inaangkin ang PCI DSS scope para sa card payment dahil hindi kami nagpoproseso ng card payment.

Retention

Naka-configure, hindi walang hanggan.

Ang reference deployment ay naka-configure sa 180 araw para sa session transcript at 365 araw para sa event record, itinakda ng environment at ng DPA. Ang merchant-specific retention ay pinagkakasunduan sa DPA, at ang deletion ay hinahawakan kapag hiniling. Wala pang scheduled purge na inaangkin ngayon.

Audit trail

May record ang security-relevant event.

Ang registration, sign-in, failed sign-in, invite, setup at pagbabago ng integration credential ay nakasulat sa audit log. Naka-hash ang email sa audit detail kaysa naka-store nang raw. Internal ang log ngayon; wala pang merchant-facing audit screen.

Hangganan ng modelo

Minimum lang ang ibinibigay sa modelo.

Natatanggap ng modelo ang tanong ng mamimili, mga nakuha na kandidato mula sa katalogo, setting ng tindahan at relevant na teksto ng patakaran. Hindi nito natatanggap ang password, API credential o card data, at wala itong tool na kayang magsulat sa POS.

Ang “Built” ay nangangahulugang umiiral na ang kontrol sa produkto ngayon. Hindi ito nangangahulugang na-independently audit ang bawat kontrol. Nasa ibaba ng page na ito ang listahan ng agwat.

Credential at request

Naka-encrypt at rest. May pirma sa transit.

Ang dalawang mekanismong karaniwang unang hinihingi ng security reviewer.

Credential at rest

Algorithm
AES-256-GCM, authenticated encryption.
IV
12 random na byte bawat record, hindi kailanman inuulit.
Pag-binding
AAD provider:{providerId}:account:{accountId}:credentials. Nabibigo ang pag-decrypt ng kinopyang record.
Pag-rotate
keyVersion sa bawat record; tinatanggap ang dating key habang nagro-rotate.
Pagkabigo
Fail closed ang failed decrypt. Hindi ito nagre-retry gamit ang lumang secret.

Mga request ng Salewise

Ang master key ay isang beses na naka-configure sa server setup. Bawat request ay may pirma nito; ang signature ay hindi bearer token.

canonical =
  method + "\n" +
  path + "\n" +
  timestamp + "\n" +
  nonce + "\n" +
  sha256(body);

signature =
  HMAC-SHA256(masterKey, canonical);
  • Ipinapadala bilang X-Sage-Signature kasama ang timestamp at nonce header.
  • Inihahambing sa constant time, may replay window.
  • Nasa server-side ang master key at naka-encrypt at rest.
  • Hindi kailanman ibinabalik sa browser o isinusulat sa log.

Data, role at retention

Makitid na data. Naka-scope na access. May record.

Hindi kailangan malaman ng assistant kung sino ang mamimili para sagutin ang tanong sa produkto.

Naitatala ng session

  • Session ID, QR code at ang pasilyong nagpasimula nito.
  • Ang mga tanong, sagot at rekomendasyon.
  • Handoff event at timestamp.

Walang pangalan, account o card data. Hindi ini-link ng demo ang session sa pinangalanang mamimili.

Sino ang makakaabot

  • Merchant account, naka-scope sa mga tindahang naka-link dito.
  • Server admin, para sa setup at provider configuration.
  • Walang cross-merchant store access sa mga store route.

Naka-bound ang invite sa email at nag-expire pagkatapos ng 7 araw.

Gaano katagal ito nananatili

  • Session transcript: naka-configure sa 180 araw.
  • Event record: naka-configure sa 365 araw.
  • Merchant-specific terms: nakasaad sa DPA.

Hinahawakan ang deletion kapag hiniling. Wala pang scheduled purge na inaangkin ngayon.

Audit event

Ang registration, sign-in, failed sign-in, invite, setup at pagbabago ng integration credential ay nakasulat sa audit log. Naka-hash ang email sa audit detail kaysa naka-store nang raw. Internal ang log ngayon; hindi namin ito ipinapakita bilang merchant-facing audit screen.

Attribution

Kailangang makalampas ang record sa audit.

Exact o modelled ang naitugmang benta. Nakikita ng merchant kung alin, at bakit.

Deterministic

Redemption code na dinala mula sa session hanggang sa benta. Confidence 1.0. Modelled false. Attributed outright ang benta.

Modelled

Same-store na benta sa loob ng dalawang oras na window na may mga inirekomendang item. Naka-store ang confidence score, may cap na 0.92, at may label na modelled ang tugma saanman ito i-report.

Exact ang exact na tugma. May label na modelled ang modelled saanman ito i-report. Ang subscription ang tanging bayad, at hindi ipinapakita ang attribution bilang revenue.

Tapat na limitasyon

Ano ang hindi namin inaangkin.

Mas madaling suriin ang tiwala kapag nakasaad ang agwat.

Kung kailangan ng questionnaire ng isang bagay sa listahang ito, sabihin ninyo.

Mas gusto naming mawala ang deal kaysa sumagot nang paligoy-ligoy.

  • 01

    Wala kaming SOC 2 o ISO 27001 certification ngayon.

  • 02

    Hindi pa kami nakakumpleto ng independent penetration test o security audit ngayon.

  • 03

    Hindi namin inaangkin ang PCI DSS scope para sa card payment, dahil hindi kami nagpoproseso ng card payment.

  • 04

    Hindi kami nagte-train ng shared model sa katalogo o usapan ng isang merchant sa kasalukuyang produkto.

  • 05

    Walang AI system na risk-free. Binabawasan ng grounding ang pag-imbento; hindi nito inaalis ang pangangailangan sa review ng merchant at handover rules.

  • 06

    Wala kaming scheduled retention purge ngayon; ang deletion ay operational procedure sa ilalim ng DPA.

  • 07

    Internal ang audit log namin at hindi ito inilalabas bilang merchant-facing audit screen.

  • 08

    Hindi kami nangangako ng service level sa page na ito; ang anumang availability commitment ay nakasaad sa order form.

Responsible disclosure

Kung sa tingin ninyo ay may natuklasan kayong vulnerability, makipag-ugnayan sa support@salewise.co.uk na may sapat na detalye para ma-reproduce ito. Pakiusap na huwag i-access ang data ng ibang merchant, abalahin ang serbisyo, o magdisclose sa publiko bago kami magkaroon ng pagkakataong tumugon.

Mga tanong sa seguridad

Itanong ang mahirap na tanong.

Malugod naming tinatanggap ang security questionnaire, data processing terms at tanong sa arkitektura. Sasagutin namin ang alam namin at sasabihin ang wala.

Makipag-ugnayan sa aminBasahin ang detalye ng produkto