Pasal
Back to homePasal

Legal · Privacy

Privacy Policy

Last updated 26 August 2026

This is the honest version. It tells you what Pasal holds, who else it reaches, how long it stays, and what you can do about it. We do not sell data to anyone. We run no advertising trackers, no tag manager, and no session recorder, on pasal.studio or on any shop built with it. Where the answer is uncomfortable, it is written down here anyway, because a privacy policy that describes a tidier product than the real one is worse than no policy at all.

  1. 01

    Who is behind this, and one word to get out of the way

    Pasal is run by Retriever Labs Pvt. Ltd., a private limited company registered in Nepal on 13 August 2026, registration number 399717, at Bhaktapur Municipality-2, Bhaktapur. In this policy, "we" and "us" mean that company, and "Pasal" means the service at pasal.studio and the shops built on it.

    We say shopper for the person buying from a shop, and customer means the same thing. Shop owner means the person running a shop on Pasal, and staff means someone they invited into the dashboard.

    If anything here is unclear, email support@pasal.studio and a person will answer.

  2. 02

    Who is responsible for what

    Pasal has two kinds of data in it, and different people answer for each.

    Your own account with us. If you open a shop, invite staff, or sign in as a shopper to see your order history, we decide how that account works and what we do with it. We are the ones to ask about it, and this policy is the answer.

    Your customers' details inside your shop. The orders, bookings, khata entries, loyalty points, tickets and repair jobs in a shop belong to that shop. The shop decides what to ask for, what to write down, and what to do with it. We store it and process it so the shop works, and we act on the shop's instructions, not on our own ideas.

    What that means in practice, if you bought something from a Pasal shop: ask the shop first. They hold the record, they can change it, and they can delete it. If you cannot reach them, if they have stopped trading, or if they will not answer, email support@pasal.studio and we will act on your request ourselves. You are not stuck just because a shop went quiet.

    One honest note about the words. Nepal's Privacy Act 2075 does not divide the world into controllers and processors the way European law does. We use the split above because it describes how Pasal actually works and it tells you who to write to. It does not move our own duty under Nepali law. We hold the data, so the law's obligations sit on us as well as on the shop.

  3. 03

    What we hold about a shop owner

    Your account. Your email address, the display name you set, when the account was created, when you last signed in, and whether the email has been confirmed. Sign-in is a one-time six-digit code sent to your inbox, so most accounts have no password at all. You can set one if you want, from the Forgot password link on the sign-in page, and if you do it is stored hashed, never in readable form.

    Your shop's public profile. Shop name, web address, street address, phone, WhatsApp, Instagram and any other social links, opening hours, tagline, logo, hero image and about photos. All of this is published on your storefront on purpose, so anyone on the internet can read it, including search engines and anyone scraping pages. On a one person shop those are that person's own contact details, so publish only what you want strangers to have.

    Where your shop sits on a map. If you put a pin on your loyalty card or on an event, we store a pair of coordinates for it. You get there two ways. Typing an address and pressing look up sends that text to OpenStreetMap and stores what comes back. Pressing use my current location asks your browser for your device's position, and your browser will ask your permission first. Say yes to that one only where the shop is. It reads your device to about ten centimetres, not to the nearest street, and the pin is public like the rest of your shop profile. If you run the shop from home and press it in your kitchen, you have published your home. Type the address instead if that is you, and you can clear a pin at any time.

    Your private reply address. A separate contact email you can set so your personal inbox is not published. It is deliberately kept out of the public part of your shop record. We use it as the Reply-To on mail we send your customers.

    Your tax registration. Your registered legal name and your PAN, if you enter them so your receipts are legal. These are not published on your storefront. They are printed on a customer's own receipt and invoice, and they are read by the function that sends that email.

    Payment details you publish. Your payment QR image, its label, and your payment note, which usually contains an eSewa number or a bank account and the name on it. These are public, because a shopper has to be able to scan and read them.

    Your eSewa merchant key, if you connect one. Stored so we can sign and check payments for you. Nobody can read it back through Pasal: not you, not your staff, not us through the ordinary interface. The dashboard can only tell you whether a key is set and when it was last written.

    Your catalog. Products, prices, categories, sizes, colours, stock and photos. Also your cost prices, which sit in a separate owner only table and are never shown on a storefront or to a shopper.

    Counter PINs. If you use the counter, the names and PINs you set for your staff are stored on your shop record in plain, readable text. This is worth knowing rather than assuming: a PIN here is a way to keep staff honest with each other about who rang a sale, not a security boundary. Anyone who can sign into your shop's dashboard can read them. They are not published to the public.

    Your plan and what you paid us. Which plan, how many months, the amount, the transaction id, the status eSewa reported, and when it settled. No card number, bank number or account number ever reaches us. We record which plan you are on and when it changes, including the day a trial ends.

    Order alerts. If you turn on new order notifications, the address your browser gives us to deliver them to, and which account switched it on. Nobody can read these through Pasal; only the function that sends the alert can.

    Help chat questions. What you type into the help assistant in your dashboard, plus the last six messages of that conversation, is sent to Anthropic's API so it can write the answer. The question and each earlier message are cut to 2,000 characters first. Two things about your shop go with it. Which features you have switched on, so the answer only covers buttons you actually have. And, so a question about your own money can be answered at all, whether each figure on your dashboard is a number, a zero, a book your account may not read, a book your shop does not keep, or a reading that did not load.

    The amounts themselves are never sent to Anthropic. Its answer comes back with named blanks in it, and our own server puts your figures, and the names on your khata, there afterwards. No product, no order row, no customer name and no phone number goes to Anthropic with a chat question. When the assistant is not available to your shop, the dashboard answers from a list of help articles held on your own device and nothing is sent anywhere. Do not paste a customer's details into it.

    Help chat usage. How many questions your account asked the help assistant on each day, so we can keep one runaway client from running up a bill. It is a count, not the questions. We also record which family each question came from, out of a fixed list of ten subjects: today's takings, the week, the khata, repairs, orders, unpaid orders, any other money question, a request to change something, a question about using Pasal or about your plan, and one for everything else.

    The family is worked out from your words at the moment you ask, and the words are not kept with it. It is the subject only, never the question you typed and never the answer. It is not filed against you either: the tally holds a day, a family and a number, with no account and no shop on it. We keep it so we can see which kinds of questions owners actually ask, and decide what to build next and what to charge for, without reading anybody's questions.

    The AI product writer. When you press Write it with Pasal AI in the product editor, that product is sent to Anthropic's API so it can draft the words: its name, price, unit, description and category, its first photo, the categories your shop already uses, and your shop's name, trade and area. We send the link to that photo and Anthropic fetches it, so the photograph itself reaches them and the model sees it. It is the product photo your shop already publishes on its own storefront. Nothing else goes, and nothing comes back saved. The drafts sit under the box until you press one.

    If you asked us about opening a shop. Older shops came through a Create Shop form that recorded the shop name, your name, your phone, your email, what you sell and your note. We no longer use that form: you open a shop yourself at pasal.studio/create. Nothing in Pasal sends us a lead any more, so no new record is being made. The records the form left are kept, and only our own founder account can read them. Ask us and we will delete yours.

  4. 04

    What we hold about a shop's staff

    If you are a staff member at a Pasal shop, this is what exists about you.

    Your roster entry. Your email address, your display name, and the list of dashboard tabs the owner granted you. The owner types this, not you. Pasal does not email you to tell you it happened; you simply find the shop attached when you next sign in. Telling you is the owner's job, and their agreement with us says so.

    Your own Pasal account. The same as any owner account: email, when it was created, when you last signed in.

    Your name on the sales you rang. A counter sale records who rang it as plain text, so it stays correct in the shop's records after you leave. Removing you from the roster removes your access and your roster entry. It does not rewrite the sales you already rang, the loyalty points you granted, or the orders you handled.

    Your counter PIN, as described above, in readable text on the shop record.

  5. 05

    What a shop holds about its customers

    If you run a shop, this is what Pasal stores for you about the people who buy from you. All of it is stored by us on the shop's behalf. Unless a line says otherwise, only that shop can read it, and no shop can see another shop's records.

    Orders. An order holds:

    • the customer's name, phone number and email address;
    • the delivery address, but only for a delivery order, because pickup and dine-in send an empty one on purpose;
    • which table a dine-in order came from, read from the QR sticker the guest scanned and not from anything their phone claims;
    • the note the shopper typed, which can hold anything they choose to put in it, such as a landmark, a gate code or an allergy;
    • every line of the order with quantities, prices, sizes and colours;
    • the money, meaning subtotal, discount, any promo code, delivery fee, service charge, VAT and total;
    • whether it is paid, its status, and the time.

    If the order is cancelled, it also holds the reason the shop typed, which is sent to the customer word for word.

    Who can read an order. The shop owner, and every staff member with an account on that shop. This is worth saying plainly because it is not what most people assume: the order read rule is per shop, not per permission, so a staff member you granted no tabs at all can still read every order, with the customer names, phone numbers, email addresses and delivery addresses in them. A shopper signed into their own Pasal account sees the orders that carry their email address. Someone holding an order link, and nothing else, can see only whether it is paid and what its status is.

    Payment evidence. If a shop takes money by QR, the customer can type the transaction number from their bank or wallet and attach a screenshot. The screenshot is a photograph of somebody's banking app, so it usually shows their account name, an account or wallet number, and often a balance. Pasal treats both as a claim, never as proof: nothing is marked paid because a customer said so. The screenshots sit in a private store that only that shop can open, through a link that stops working after five minutes. The transaction number is also printed on the customer's own invoice email.

    Khata, the credit book. If a shop lets a regular take goods on a tab, it records that person's name, phone number, the amount, whether each line is credit taken or money settled, a note, and the date. This one is different from everything else here and deserves the difference stated: the person named did not type any of it, has no Pasal account, is not told by Pasal that the record exists, and cannot see or correct it themselves. The shop's agreement with us requires the shop to tell them, and to answer them within 14 days if they ask. Only that shop, and the staff it granted the khata tab to, can read it. It is never published, never shared with any other shop, and never used to score anyone's credit. We are not a credit reference agency and we do not report a shop's khata to anyone. If you believe a shop has written something about you that is wrong, write to the shop, and write to us if you cannot reach them.

    Loyalty points. The ledger stores the customer's name, their phone number where they left one, and every adjustment: how many points, the reason a staff member typed, who made it, and when. Adjustments cannot be edited or deleted, so a correction is a new line rather than a rewrite. The other half of a balance is not stored at all. It is worked out each time from what that person has spent at that shop. Which spending counts depends on who is asking, and that split is deliberate. The shop's own screens match you by your phone number, or by your name if you never left one, because a person is standing at the counter and staff can see who it is. Anything you see yourself, on the website or on a card in your phone, matches only the email address you signed in with and proved. Points a shop typed against your phone number therefore show at that counter and can be spent there, and they do not show on your card. We tried joining a proved email to an unproved phone three times, and each attempt let somebody spend points that were not theirs, so we stopped joining them. So a loyalty scheme is, mechanically, a lasting link between a named person and everything they have ever bought from that shop. Every member of the shop can read the ledger; granting or redeeming points takes a permission.

    Bookings and appointments. The name, phone, optional email, date, time, how many people, a free text note, the status, and the shop's reason if it declines. Anyone can request a booking without signing in. For a garage, the booking form also asks for the vehicle plate, which is stored at the front of that booking's note. Nobody outside the shop can read a booking. A shopper signed into Pasal sees bookings that carry their own verified email address.

    Event tickets. The name printed on each ticket, copied from the buyer at checkout, and whether and exactly when that person walked through the door. The ticket buyer's name, phone and email are also recorded as an ordinary order. One thing to know before you forward a ticket: the ticket code is the key. Anyone holding the code, including anyone in a group chat where a screenshot was shared, can look up the holder's name and whether they have been admitted. Treat a ticket like a boarding pass, not like a poster. That warning matters more now the ticket can live in your phone's wallet, because a wallet card can be set to show on a locked screen. Anyone who can see your screen can photograph the code, and the code is the whole key. A ticket in a wallet is also not a receipt: it carries the name and the tier and nothing about what was paid.

    Repairs. For a shop that takes work in, the customer's name and phone, the device they handed over, the fault they described, the quote, any deposit and the final charge. Like khata, this is typed by counter staff about somebody who never touched the software. Only staff granted the Repairs tab can read it.

    Returns. What came back, the size, the reason, the refund and how the money went back. A return recorded from a receipt is stored against that order, and the order carries the customer's name, phone and email, so that return is about an identifiable person and the shop's customer list relies on it: refunds are subtracted from what that person has spent with the shop. A return recorded with no order number names an item and an amount and nobody. Only the owner and staff granted returns can read either.

    The Ledger. Revenue and expense lines a shop types. The labels are free text and in practice they name sponsors, venues and hired people. Only the owner and staff granted billing can read it.

    The customers list. Not a separate collection. It is the order table read back and grouped, so a shop can search for a customer from months ago and see what they have spent in total.

    Invoices. When an order is marked paid, it is given the next number in that shop's own tax invoice series for the current Nepali fiscal year, with the fiscal year and the moment it was allocated. The number and the document belong to the shop, which is the taxpayer.

    A shopper's own Pasal account. If you sign in on a storefront, we email a one-time six-digit code and create an account for that email address. The account is ours, not the shop's, and it is what lets you see your own orders, tickets and bookings across every Pasal shop you have bought from. It is keyed on the verified email in your session, so it shows you the orders that carry your email address and nothing else. One caveat we would rather state than hide: a shop's checkout does not verify the address a shopper types, so if somebody types your address by mistake their order can appear in your account. Tell us and we will take it out.

    Your saved details, and where they travel. You can tell Pasal your name, phone and delivery address once, so you are not retyping them at every shop. That is one record for your account, not one per shop, and it is yours to change. It fills in your checkout. It is not handed to shops to browse, and no shop can search it.

    There is one door into it and we would rather name it than let you find it. If you add a shop's loyalty card to your phone and a staff member scans that card at the counter, they are shown the name and phone on your account, along with the email the card was issued to. That is the point of scanning it: they are trying to find out who is standing there. It means a shop can learn your name and number from the card alone, even if you have never bought anything from them, because adding a card only takes a Pasal sign-in. Only staff that shop trusted with its orders can do it, only for a card you chose to add, and only one person per scan. If you would rather a shop did not have that, take their card out of your wallet, or leave the name and phone on your account blank.

  6. 06

    What we hold about someone just visiting

    This applies to everyone, whether you run a shop, work in one, or just bought something.

    A visit token. The first time a browser opens pasal.studio or a Pasal storefront, it makes a random 24 character token and keeps it in that browser's own storage. There is no expiry on it and nothing rotates it. It is sent with each thing we count. It is not written onto an order, a booking, a customer or an account, and nothing in Pasal can turn it into a name. We considered joining it to accounts and decided not to, because that would turn an anonymous token into an identifier for a named person.

    Two things about it we would rather say than have you discover. It is a token that lasts, so it does distinguish your browser from another browser until you clear your browser storage, which you can do at any time. And it is the same token for both counts below, so within one web address a browser's marketing page views and its storefront browsing sit under one key. A shop on its own domain or its own subdomain is a different web address and gets a separate token of its own.

    Storefront counts. For each arrival, product view, event view and add to cart: which shop, which of those four things it was, a reference (a product or event id, or the campaign tag on the link you followed such as ?s=instagram, or failing that the bare site you came from such as instagram.com), the token, and the time. Never a full web address and never a query string. The shop can read its own, and no one else's.

    Marketing site counts. For a page view on pasal.studio itself: one of ten fixed page names, never a path or a URL, plus the same reference and token and time. Nobody can read these rows one at a time through Pasal, not a shop and not us: the database permission is removed and there is no rule that would allow it, on purpose, so that one browser's movements around our site cannot be pulled out of the product. What is left is direct access to the database itself, which Security below describes. We look at the totals, never at a row.

    Server logs. Vercel serves every page, so its logs hold the usual things a web server sees: the visiting IP address, the browser's user agent, and the address requested, which on a storefront includes the pages that were browsed.

  7. 07

    Why we hold it, and on what basis

    To do what you asked us to do. Running your shop, showing your catalog, taking an order and passing it to the shop, sending the receipt and the status updates, issuing a ticket and checking it at the door, holding a booking, counting loyalty points, and taking your payment for a Pro plan. Without this the product does not work.

    To meet a legal duty. Keeping invoices, tax records and the numbered invoice series a shop needs for PAN and VAT.

    Because we have a genuine interest in a service that works and stays safe. Counting visits so a shopkeeper can see how many people came and we can see whether Pasal is growing, keeping the platform secure, limiting abuse, finding and fixing faults, and understanding across the platform how many shops there are and how they are doing.

    That last one deserves one specific disclosure rather than a vague phrase. We run a founder console, and it can see, for every shop: the shop's name, address, type, plan, when it opened, the owner's email address, how many orders it has, its revenue and profit over the last 30 days, its visit counts, and every plan payment it made to us. It can also list every Pasal account with its email, name and last sign-in. That console shows shops in counts and money: it returns no customer name, phone number, email address, order, khata line, loyalty entry, booking or ticket.

    What it does not do is fence off the database itself. The people named in Security below can reach that directly in order to run and support the platform, and the same access lets us create an owner account, reset a password and change an account's email address when somebody asks us to.

    Here is what we do not do, and it is a short list because it is complete. We do not sell data. We do not run advertising or advertising trackers. We do not use a shopper's email address to market anything to them. We do not build a profile of a person across shops. To be exact about that, because we do hold one thing that spans shops: if you saved your name, phone and address to your Pasal account, that is one record and it fills in your checkout wherever you buy. You typed it and you can change it. We do not add to it by watching you, we do not join your purchases at one shop to your purchases at another, and no shop is given it to browse. We do not read a shop's customer records except when a shop asks us for help with something specific, or when we have to in order to keep the service running.

  8. 08

    Email we send on a shop's behalf

    This is Pasal's own infrastructure sending mail to a shop's customers, so it is worth being precise about.

    Who the sender is. Every message goes out from an address we own: orders@pasal.studio for orders, invoices, tickets, bookings and storefront sign-in codes, and hello@pasal.studio for a shop owner's own sign-in and account mail. The shop's own address is the Reply-To, so a reply reaches the shop and not us. That means we are the sender of record on mail carrying a shop's customers' details, and it means one shop's bad practice can affect delivery for every other shop.

    What goes to a customer. Their own delivery address or table, every line of the order with prices, and the shop's own address. When an order is marked paid they also get an invoice mail carrying their name, phone and email address, the payment reference they typed, the invoice number and, where the shop has entered one, its registered legal name and PAN. A receipt PDF is attached. For an event, their ticket codes and a ticket PDF.

    What goes to a shop owner. A new order notice carrying the customer's name and phone. And the daily summary email, sent every morning on any day the shop had orders or bookings, which for a shop with a diary open also lists today's bookings with the time, the name, the phone number, the party size and whatever the customer wrote in the booking note, including a vehicle plate at a garage. It is on for every shop by default and there is a switch in Settings to turn it off.

    Sign-in codes, to whoever typed the address, for owners, staff and shoppers alike. Codes stop working after an hour and are never shown to anyone but the recipient's inbox.

    All of this is transactional: it is about something a person started. Pasal is not a newsletter tool, and we do not use addresses collected through a shop's checkout to market anything, to that shop's customers or to anyone else. If a person tells us they do not want mail from us, we stop sending to that address and keep it on a list we will not send to.

  9. 09

    Who else your data reaches

    These are the companies that hold or handle data as part of running Pasal. The full list, including where each one sits and exactly what reaches it, is at pasal.studio/subprocessors.

    Supabase. The database, sign-in, file storage and the server functions. This is where Pasal lives, so everything this policy says is stored, is stored there: accounts, orders, khata, loyalty, bookings, tickets, repairs, photos and payment screenshots.

    Vercel. Hosts and serves pasal.studio and every storefront, and attaches a shop's subdomain. It sees every request, so the visiting IP address, browser and page requested.

    Resend. Delivers every email Pasal sends, including sign-in codes. It sees the recipient's address and the whole message, which means order contents, customer name, phone and delivery address, ticket and invoice PDFs, and a shop's legal name and PAN.

    Anthropic. Powers the help assistant and the AI product writer in the dashboard. From the assistant it sees the question an owner types and the last six messages of that conversation, each cut to 2,000 characters, which features the shop has switched on, and whether each figure on the dashboard is a number, a zero or a book that account cannot read. No amount, order or customer record is attached. From the writer it sees the product being written for and the shop's name, trade and area.

    eSewa. The payment gateway, where a shop connects its own merchant account, and where a Pro plan would be paid. It sees the amount, a transaction id we issue, the merchant code and a signature. The shopper's browser goes to eSewa directly, so eSewa also sees them. No card, bank or account number ever passes through us.

    Google, for two typefaces. Serves the Space Mono and Caveat webfonts used across the site and every storefront, so it sees your IP address, browser and the page you are on, on every single page load. See the next clause.

    Google, Mozilla or Apple, for push. Deliver an order alert to a shopkeeper's device. Which one depends on their browser, not on us. They see the device subscription and the fact that an alert was sent. The alert itself is encrypted to that device.

    Apple and Google, for wallet passes. Hold a loyalty card or a ticket in the wallet app on a customer's phone. The two differ. A Google pass is built on Google's servers, so a customer's name, their points and an event's name, date and venue reach Google. An Apple pass is a file we sign and the phone keeps, so Apple sees the token used to tell that phone its card has changed, and not what the card says.

    OpenStreetMap. Turns an address into coordinates when a shop puts a pin on its loyalty card, or an event puts one on its venue. They receive the address text and nothing else, asked by our server rather than by your browser, so they are not told which shop asked and they never see your visitors.

    Unsplash and Pexels. Host the stock photography on Pasal's own demo shops at pasal.studio/demo and on the pages that preview a template while you are setting up. Shops you and other customers run use their own uploaded photographs. So these two see your IP address, browser and the page you are on, when you are looking at one of our demo shops or a template preview.

    We do not sell data to any of them or to anyone else. They handle it to do their part and nothing more.

  10. 10

    What your browser loads from other companies

    Some of the list above is a company we hand data to. Some of it is a request your own browser makes to a third party host, which tells that company your IP address whether we like it or not. Since that distinction is usually hidden, here it is straight.

    On every page, without exception, your browser asks Google for a stylesheet at fonts.googleapis.com and opens a connection to fonts.gstatic.com, and downloads the two typefaces themselves from there wherever a page uses them. This happens on pasal.studio and on every storefront, before you have clicked anything. Google therefore sees the IP address and browser of every person who opens a Pasal shop. The rest of Pasal's typefaces are served from our own servers; these two are not, and this is the one piece of Pasal that hands data to a company you did not choose on an ordinary page view.

    On every page, your browser also talks to our own database host at Supabase to load the shop, keep a session alive, and fetch product photographs.

    On our own demo shops and template previews, images load from Unsplash or Pexels. A shop you buy from shows photographs its owner uploaded, which come from Supabase like everything else.

    Only if a shopkeeper turns on order alerts, their browser registers with their own vendor's push service.

    Only on the eSewa checkout path, your browser is sent to eSewa, where you leave our site.

    Only if you add a card or a ticket to Google Wallet, your browser is sent to pay.google.com to finish it, where you leave our site. Adding one to Apple Wallet does not do this. That file comes from us and your phone opens it itself, so your browser never visits Apple.

    Nothing else. We run no analytics or advertising product of any kind on pasal.studio or on any storefront: not Google Analytics, not a Meta pixel, not a session recorder, not any of the other usual names. We checked this against the built site and not only the source code, which is how the Google Fonts request above was found and why it is written down here.

  11. 11

    Using the camera to scan

    The counter can read a barcode, a payment QR or a customer's loyalty card with your phone's camera, and the door can scan a ticket. Your browser will ask your permission the first time, and it is your device asking, not us.

    Here is the part worth stating plainly, because a camera is the thing people are right to ask about. No picture leaves the device. The video is never recorded, never uploaded, and never sent to us or to anyone else. The reading is done inside your own browser, by code we serve from our own servers rather than fetching from somebody else's. The only thing that ever reaches us is the text that was decoded, which is a product's barcode number, a ticket code, or the reference on a card. When you close the scanner the camera is switched off.

  12. 12

    Where the data is kept

    Pasal's data leaves Nepal, and there is no way to run it as it stands without that being true. Here is the honest picture.

    The application is served by Vercel, whose server functions for Pasal run in Mumbai, India, and whose network is worldwide. The database, sign-in and file storage are with Supabase, on servers outside Nepal. Email is delivered by Resend, also outside Nepal. The help assistant and the AI product writer both run on Anthropic's API in the United States. eSewa is in Nepal. If you need to know the exact country any one of these sits in, ask us and we will tell you.

    We chose these because they are the services that run the kind of platform Pasal is, and we chose them knowing where they sit. We are not able to promise that your data stays inside Nepal, so we do not.

    On the law, as it stands today: there is no Nepali rule requiring a business like Pasal to keep personal data inside the country. The directive that governs data centres and cloud services binds the providers of those services, not their customers. If that changes, this policy changes with it and we will tell you.

    Pasal is offered to businesses in Nepal and priced in Nepali rupees. It is not offered or marketed to people in the European Union, and we do not claim to comply with European or Indian data protection law. We would rather say that plainly than put a badge on a page we cannot stand behind.

  13. 13

    What is kept in your browser

    Pasal sets no cookies. Not one, anywhere, on any page. There is no cookie banner because there is nothing to consent to. What we use instead is your browser's own storage, which stays on your device and is never sent in a request header. Here is every item of it.

    Your sign-in session. Keeps a shop owner or staff member signed into the dashboard. It lasts until you sign out, and the token inside it refreshes every hour.

    A shopper's sign-in session. Kept under its own name so a shopper's session and an owner's session on the same device never overwrite each other. Until you sign out.

    The visit token. The random token described above, sent with the visit counts. No expiry. Clear your browser storage to reset it.

    Your shopping bag. What you put in the bag at one shop, with quantities. No name, phone or address in it. It is removed when the bag empties or the order is placed. If it is more than 7 days old it is thrown away the next time you open that shop.

    Unsent counter sales. On a shop's own counter device: sales rung while the internet was down, with items, prices, total, discount, pay method and the staff member's name, waiting to be sent. Cleared as each sale lands.

    Parked bills and the day's opening cash float. On a shop's own counter device, until the bill is finished or the day ends.

    Wizard answers. The trade and features you picked in the setup wizard, carried to the publish form. Until the shop is published.

    A payment in progress. The transaction you are part way through and the page to return to, kept only in the tab. It dies with the tab.

    Preferences. Dashboard theme, kitchen TV settings, landing page language, and which prompts you have dismissed. Until you clear them.

    None of it is used for advertising. There is nothing to use it for advertising with.

  14. 14

    How long we keep it

    The honest answer is that Pasal deletes nothing on a schedule. There is no job that clears old records after 90 days or a year or ever. An order placed on the day a shop opened still carries that customer's name, phone, email and delivery address today, and will next year. The same goes for every khata line, every loyalty adjustment, every booking, every repair job, every ticket with the name on it and the moment it was scanned, every visit count, and every payment screenshot.

    That is a deliberate position and not an oversight, so here is the reasoning. An order is a shop's record of a sale, and a shop needs it at a tax assessment, in a dispute, and when a customer comes back six months later. A khata line is money somebody owes. A payment screenshot is the shop's evidence when a customer says three weeks later that they paid. A job that quietly deleted these would take a shop's own records away on a timetable nobody chose.

    What actually removes data, all of it somebody pressing a button:

    • An owner deleting an order. It goes for good, along with any tickets on it, and we delete its payment screenshot at the same time. That is the one moment a customer's bank screenshot is destroyed. If the file store is unreachable at that instant the picture can survive the order; tell us and we will remove it.
    • An owner deleting an event, which takes its ticket types and its tickets with it.
    • Deleting a loyalty card or a ticket from your phone's wallet. The phone tells us, and we drop the record that let us send anything to it. The card itself stays on your account, so adding it again picks up where you left off.
    • An owner deleting a product, a promo code, a ticket tier, or a Ledger line. Note that deleting a product does not remove photographs already uploaded for it: those stay reachable at their addresses until we remove them, so ask us if you need that done.
    • An owner removing a staff member, which removes their access and their roster entry, and leaves the sales they rang and the points they granted intact.
    • An owner deleting a repair job, while no money has been collected on it. Once a job is collected its charge is counted in the shop's takings, and it can no longer be deleted at all.
    • An owner deleting a recorded return or exchange. Any refund on it comes back out of the shop's figures for the day it was recorded on.
    • An owner clearing their stored eSewa key.
    • A device unsubscribing from order alerts.
    • Us clearing an old lead from the Create Shop form.

    There are things a shop cannot delete for itself at all, and it is better you hear it here than find out when you ask: a booking, a khata line and a loyalty entry have no delete control in the dashboard, and loyalty entries are deliberately append only so a correction is a new line rather than a rewrite. A collected repair job belongs on that list too, for a different reason: the delete control is there until the money is taken and gone the moment it is, because deleting it would rewrite takings the shop has already read. If one of those has to go, ask us and a person does it, subject to what the law makes us keep.

    Four things do expire by themselves, and they are the only time limits in the product: a saved shopping bag after 7 days, a link to a payment screenshot after 5 minutes, a link that hands a wallet card to your phone after 10 minutes, and a sign-in code after 1 hour.

    There is today no button that closes a shop or deletes an account, for an owner or for a shopper. That does not mean you cannot have it done, it means you have to ask us and a person does it. See the next clause. If you want us to hold your shop's data for a fixed period after you leave rather than indefinitely, say so and we will agree it in writing.

  15. 15

    Your rights, and how to use them

    You can ask to see what we hold about you, to correct it, to get a copy of it, and to have it deleted. So can a shopper who bought from a shop built on Pasal.

    How to ask. Email support@pasal.studio and say what you want. If you are a shopper, start with the shop you bought from, because they hold the record and can act faster. If they do not answer, or the shop has closed, come to us and we will do it.

    What happens then. We will reply within 5 working days to say we have it and what we need from you. We will finish the request within 30 days, and if something makes that impossible we will tell you why before the 30 days are up.

    What we can do today, honestly. A shop owner can download a month of orders at a time as a spreadsheet from the dashboard, without asking anyone. Everything else, meaning products, customers, khata, loyalty, bookings, tickets, the Ledger and photographs, is assembled by a person when you ask, in whatever plain format we can produce. There is no self serve export and no delete button yet. We would rather tell you that than imply a button exists.

    Verifying it is you. We will ask you to confirm the request from the email address on the account, because handing someone else's records to whoever asks would be the worse failure.

    When we may say no, or not all the way. We will keep invoices and tax records that the law requires us to keep, even if you ask us to delete everything else, and we will tell you when that is what has happened. We will not hand you another person's data inside a shared record, so where an order names both a shop and a customer we give each of you your own part. We will not act on a request we cannot verify.

    If you are not happy with our answer. Tell us first, in plain terms, and we will look at it again. Beyond that, Nepal has no data protection regulator to complain to, so we will not name one. The routes that do exist under Nepali law are a complaint to a district court or a police office under the Privacy Act 2075, and, where the issue is about a service you paid for, the consumer complaint routes under the Consumer Protection Act 2075. Nothing in this policy takes away a right the law gives you.

  16. 16

    Security

    Here is what is actually true, and only that. There is no certification, no outside audit, no outside security test and no cyber insurance behind this product, and we are not going to imply otherwise.

    In transit, everything travels over an encrypted connection.

    In the database, every table has row level security: rules held by the database itself, not by the app, that decide which account can read which rows. A shop's records are fenced to that shop. Several things are fenced harder than that: a shop's eSewa key has no read rule at all, so nobody can read it back through Pasal; order alert subscriptions have none either; the marketing site's page view rows have none and their permission is revoked.

    Sign-in is a one-time six-digit code to your inbox rather than a password, so for most accounts there is no password to steal or reuse. Whoever can read your email can sign in, so protect your inbox.

    Payment screenshots are in a private store, opened only through a link that expires in five minutes and only by people belonging to that shop.

    Access by us. A small number of people at Retriever Labs can reach the database in order to run and support the platform, and that access is not limited by the rules above. Through the founder console we see shop level figures and owner email addresses, as described earlier, and not customer records.

    Four limits you should know about rather than assume away. We would rather write them down than let you discover them. Three of them we intend to fix, and this page will say so when each one lands. We are not putting a date on that, because a date we might miss is worth less to you than a plain description of where things stand.

    • Every staff member with an account on a shop can read all of that shop's orders, including staff granted no dashboard tabs at all. If someone should not see your customers' names, phones and addresses, do not give them an account.
    • Counter PINs are stored in readable text and are visible to anyone who can sign into the shop. They tell you who rang a sale. They do not stop anyone doing anything.
    • An event ticket code is a key. Anyone holding it can see the holder's name and whether they have been admitted.
    • The fourth one is not on that list, because it is a deliberate choice and not something we are building: Pasal keeps no record of which staff member looked at which customer. There is no per person access log. Plan around that rather than around us changing it.

    No online service can promise perfect security. We take it seriously, we fix what we find, and when something does go wrong the next clause is what we will do.

  17. 17

    If something goes wrong

    If personal data held in Pasal is exposed, we will tell the shops affected within 72 hours of becoming aware of it, with what we know at that point: what happened, what was affected, when, and what we are doing about it, and we will keep telling them as we learn more.

    If it reaches a shop's customers we will help that shop tell them, and write the notice with them if they want. If a shop has not told them within 7 days of us asking, or the shop is no longer trading or will not answer, we will tell those people ourselves.

    Nepali law does not require this of us today. We are promising it because it is the thing you would want, and because a company that only says what it is forced to say is not one worth trusting with a customer list.

  18. 18

    Children

    Pasal is a tool for running a business and is not aimed at children under 16. We do not knowingly keep a shop owner or staff account for anyone under 16.

    A shopper does not need an account to buy from a Pasal shop, and we do not ask a shopper their age. If a child orders from a shop, that shop's own rules and the law where it trades decide what is allowed. If you believe we are holding an account for someone under 16, tell us and we will remove it.

  19. 19

    If you are a shopper

    Everything above applies to you, but here is the short version.

    When you order from a Pasal shop, that shop is who decides what happens with your details, and they are the first people to ask about them. We store the order for them, we send you the receipt and the updates you asked for, and we do not use your address to market anything to you, ever.

    You can sign in with a code sent to your email and see your own orders, tickets and bookings across every Pasal shop you have bought from. That account is with us, not with the shop. A shop's cost prices, its takings and its own records are never shown to you. The shop's registered legal name and PAN do appear on your own receipts and invoices, because a tax invoice has to carry them.

    Points you collect belong to the shop that gave them, not to us. If that shop closes, the points end with it.

    One thing to be aware of, and we would rather write it down than let you find it. A shop can write its own terms and privacy notice, and many have not. When a shop has written nothing of its own, its storefront has nothing of its own to show you, which means a checkout can collect your name, phone number and address with no notice from the shop attached. That is a gap and we are not going to dress it up. This policy is what applies to what Pasal does with your details in the meantime, and if you cannot find a shop's own notice, or cannot reach the shop, email support@pasal.studio and we will help.

  20. 20

    Changes and how to reach us

    If we update this policy, we change the date at the top. If a change materially alters what we collect, who receives it, or how long we keep it, we will email the address on your account before it takes effect rather than leaving you to notice a date.

    Questions about anything here, or a request about your own data, go to support@pasal.studio. They are handled by Rohan Bhaju, who founded Pasal. Pasal is small enough that this is a real person reading, not a queue.

This is written in plain language so it is easy to read. If anything is unclear, email support@pasal.studio and a person will answer. The other pages in this set are the Terms of Service, the Privacy Policy, the Acceptable Use Policy, and the list of companies that help us run Pasal.