Privacy policy

Who is responsible for your data

SefereSIM is a brand name of Vigilainte Inc., and that company is the controller of the personal data described here. It is incorporated in Delaware, United States, and its registered address is 8 The Green, Ste D, Dover, DE 19901, United States.

Anything on this page that is unclear, or that you want acted on, goes to support@seferesim.com.

What we hold

• Your email address and your nameGiven at checkout. The email address is your account and where your eSIM is sent. The name goes on your receipt, and our sign-in provider will not finish an account without it.
• Your ordersWhich plan, for which country, when, what you paid, and whether the payment went through.
• eSIM identifiersThe identifiers of the profile issued for you, such as its ICCID and its activation details, so that it can be installed, looked up and supported.
• Usage figures from the network operatorHow much of the plan data has been used, and when we last checked. These come from the operator on a delay. They are a volume, not a record of what you did online.
• What you write to usYour support emails, and our replies.
• Ordinary web request dataRequests to this site reach Cloudflare, which logs them for a short period to keep the site up and to block abuse.

We never see your card number. Card details go straight to Stripe, and what comes back to us is the amount, the currency and whether the payment worked.

We do not hold what you browse while using the plan. That traffic runs over the local operator network and never passes through us.

Why we hold it

• To sell you a plan and deliver the eSIM, which is the contract between us.
• To show you your orders, and to help when something does not work.
• To keep the accounting and tax records we are required by law to keep.
• To see how the site is used, and to measure whether the adverts we pay for lead to sales. The advertising half of that is the half you can switch off, and in some countries it does not start until you switch it on.

Companies that handle it for us

Each of these processes data on our instructions, for the job named next to it. We do not sell personal data, and we do not pass it to anyone for their own marketing.

• ClerkAccounts and sign-in. Holds your email address, your name and the codes we send you.
• StripePayments. Receives your card details directly from your browser, and the amount of the order.
• esimaccessOur eSIM supplier. Issues the profile, reports its status and its usage, and receives what it needs to do that.
• CloudflareHosting for this site and our API, the checkout bot check (Turnstile) when it is configured, and the email service that sends your eSIM and carries support@seferesim.com.
• OneSignalPush notifications for the iOS app. Involved only if you use the app and allow notifications there.
• PostHog, United StatesProduct analytics, on servers in the United States, reached through our own domain rather than a third-party host. Described in the next section.

Analytics, and what is stored in your browser

PostHog counts visits and the steps of the funnel: which page, which question, which plan. Where we have to ask you first, it runs in cookieless mode until you accept, which counts a visit without setting a cookie and without keeping an identifier on your device. Once measurement is on for you, whether because you accepted or because you are somewhere we are not required to ask, it switches to its ordinary mode, which does set a cookie and can join your visits together. The section below says where we ask and where we do not.

If you sign in on this website while measurement is on for you, the profile PostHog keeps for that browser is tied to your account and carries your email address, and your name if your account has one. That is what makes it possible to answer a question about your own order rather than about an anonymous visitor. Those details go on the profile and never on the individual events, and in a browser none of it happens while PostHog is in cookieless mode, because in that mode there is no profile for anything to be attached to. A visitor to this website who has not accepted cookies therefore never becomes a named person in our analytics. PostHog runs on servers in the United States, so that profile, with the address and the name on it, is held there.

The iOS app is the exception, and this is the paragraph to read if you use it. The app has no cookie banner and no cookieless mode, so there is no measurement setting for any of this to wait on: signing in to the app tells PostHog who you are straight away, with your email address, your name if your account has one, and the reference for your account. That happens on every sign-in, wherever you are, and whatever you answered on this website. It is the same profile, kept on the same servers in the United States. While you are signed out of the app, neither your address nor your name is sent.

On this website, PostHog session replay can run only after you accept optional measurement, and only on the public pages from landing through checkout. A visit counted in cookieless mode is not recorded. Account, admin, delivery, installation, redemption, subscription and sign-in callback pages are not recorded. Every input value is masked, the guest email inputs, sign-in form and entire payment form are blocked from replay, cross-origin frames are not recorded, and replay does not collect console logs, canvas pixels, network timing, headers or bodies. This keeps email addresses, names, sign-in codes, card details, order access, eSIM activation details and QR codes out of website replay. We ask PostHog to record every eligible checkout page load and ten percent of eligible page loads on earlier public pages. A reload can be sampled separately, so recordings are qualitative evidence and not a denominator for conversion rates.

The app records too, and here again there is nothing to accept first: it records from the first launch, for everyone, wherever you are, and the app has no setting that turns it off. What leaves your device is screenshots of the app’s own screens, masked before they go: text and text inputs, images and system pickers are all replaced with placeholders, which is what keeps your eSIM activation code, its QR and the card fields out of a recording. Nothing about the requests the app makes to us is recorded, because those addresses carry order and eSIM references. The recordings go to the same project, on the same servers in the United States, and once you have signed in they sit on the same profile your address and your name are on.

Our own servers send PostHog a second, plainer stream: what happens to an order after you have paid for it. That the order was created, that the payment went through or was refused, that the eSIM was provisioned and delivered, that a data threshold was passed or the allowance ran out, and that a refund was issued. Those carry the order and the reference for your account, and nothing else about you: no name, no email address, and nothing from an advert. They are what lets a sale be followed to the eSIM it delivered rather than lost the moment you close the page, and because they are records of a purchase rather than anything read from your browser, they are sent whether or not you accepted cookies. They land in the same project, on servers in the United States.

A promo code linked to a partner is also part of the order record. When you enter one, we use it to apply the discount, credit that purchase to the partner, and calculate and report commission. This happens even when optional measurement is off. It does not enable advertising tags or write a referral cookie.

Eight things are stored in your browser by us, and this is all of them. The last is one entry per ad platform, so it is four keys rather than one:

• seferesim.attribution, in sessionStorageWritten on the first page you land on, before you have answered the cookie banner. It holds the campaign parameters from the link you arrived on (utm_source, utm_medium, utm_campaign), our own angle tag, and the language you landed in, so that a purchase can be credited to the advert that brought you. It lives in the browser tab and goes when you close it.
• seferesim.consent, in localStorageYour answer to the cookie question, so we do not ask again. Declining adds nothing to this list, and it takes the click identifiers below off your device. What is left is written by the site doing its job, not by advertising.
• seferesim.quiz.v1, in localStorageThe answers you give in the questions, so that a reload or a step back does not lose them. It stays on your device and is not sent to us as a profile.
• seferesim.checkout.v1, in sessionStorageWritten when you start paying for an order. It holds the order reference and the secrets Stripe needs to show you that same payment again, so that reloading the page resumes the payment you already started instead of creating a second one and charging you twice. It lives in the browser tab, stops being usable after thirty minutes, and is cleared the moment the order is paid for.
• seferesim.guest-order.<order reference>, in sessionStorageWritten only when you continue without an account. It is a secret for reading that one order and its eSIM after payment. It stays in this browser tab, expires after thirty days, and is revoked when the order is claimed by a verified account. The delivery email carries it after the # in its private order link; we remove that fragment before analytics runs and do not send it to our server as part of the page address.
• seferesim.partner-pending, in sessionStorageWritten when a partner link brings you here before you have accepted measurement. It holds only the public referral token from that link, stays in this browser tab, and is erased if you decline. If you accept, we check the token with our server and then erase this temporary entry.
• seferesim.partner-referral, in a first-party cookieWritten only after you accept measurement and our server confirms the partner token. It lets a purchase made during the next thirty days be credited to that partner, including another purchase in that period. It contains the public token and referral dates, expires within thirty days, and is erased if you decline or later change your mind.
• seferesim.clickid.fbclid, seferesim.clickid.gclid, seferesim.clickid.ttclid and seferesim.clickid.twclid, in sessionStorageOne entry per ad platform, written only once advertising measurement is on for you and never before that. Each holds the click identifier Meta, Google, TikTok or X put on the link you arrived through, and the moment we first saw it, so that a purchase made later in the visit can still be credited to the advert that brought you. They live in the browser tab, are ignored after seven days, and are removed from your device if you decline or later change your mind.

Beyond those eight: signing in adds a session from Clerk, checkout loads Stripe for the card form and, when the checkout bot check is configured, Cloudflare Turnstile; each sets what it needs to do its job. Once measurement is on for you, PostHog and the advertising tags below set theirs too.

Advertising, and the say you have over it

When advertising measurement is on, we load measurement tags from Meta, Google, TikTok and X. Those four then learn that you visited, and, if you buy, that a purchase happened, with its value and the order reference. Meta, TikTok and X are told twice over: once by the tag in your browser, and once by our own servers, both quoting the same order reference so that the platforms count one sale rather than two. The second half is what still reports a sale when you close the tab the moment you have paid. Google is told by its tag alone. That is the whole count for a purchase made on this website. A purchase made in the iOS app takes a third route as well, from the app itself, and the last two paragraphs of this section are about that.

One further signal goes to Meta alone. When you start paying for an order, Meta is told that a checkout was started, with its value and the order reference, whether or not you go on to pay. From this website it travels the same two ways a purchase does: the tag in your browser, and our own servers. In the iOS app it takes the app’s own third route as well, described at the end of this section.

One more goes to two of them, and this one comes from our own servers only. When you begin installing an eSIM you have bought, Meta and TikTok are told that an installation started, with no amount attached to it.

Whether we ask you before any of that starts depends on where you are, because that is what the law makes of it. If you are in the European Economic Area, the United Kingdom, Switzerland or Türkiye, the cookie banner comes first, and until you accept it the Meta, TikTok and X tags are not loaded and nothing is sent to them. Anywhere else the measurement runs from the start of your visit, and you can stop it at any time with the "Cookie choice" link at the foot of every page.

Google behaves differently before you answer, and it is worth saying exactly how. Where we have to ask you first, Google’s tag is loaded from the start of your visit in what Google calls consent mode: it sets no cookie, it keeps no identifier on your device, and it sends Google a limited, cookieless note that a visit happened and, if you buy, that a purchase happened. No name and no address go with it. The tag sees the click identifier from the Google advert you arrived on while it is still on the address bar, and holds it in the page rather than storing it on your device, so that a sale can still be credited to that advert if you accept later in the same visit. Accept, and the tag switches to its ordinary mode and sets its cookies. Decline, and it is switched off along with the other three.

A refusal counts everywhere. If you decline, wherever you were when you did it, the Meta, TikTok and X tags are not loaded and nothing is sent to any of them, Google is told to stop and is sent nothing further, and the click identifiers listed above are taken off your device. That answer is remembered on this browser and is honoured on your next visit, from whatever country you make it, and on that visit nothing is loaded at all. All of that is an answer about this website. The iOS app asks a question of its own, and the last two paragraphs of this section are where it is described.

A purchase you have already started needs a sentence of its own, because that sale is reported by our servers after you have left the page. An order remembers the answer you had given when it was created, and that is what our servers read when the payment settles. So if you are signed in when you refuse, we also clear that answer from any order of yours that has not been paid for yet, and nothing about those orders is then reported to any advertising platform. The plainer record of what happens to an order, described under "Analytics" above, is a different thing and it continues: it is not advertising, and it is sent whether or not you accepted cookies. If you refuse while signed out we cannot do that, because a signed-out browser cannot tell us whose orders to clear: what stops in that case is everything in the browser, immediately. And a sale that was already paid for before you changed your mind has already been reported. A refusal does not reach back into it, and we would rather say so than promise you otherwise.

On a purchase we also send Meta, Google, TikTok and X a one-way hashed copy of your email address (SHA-256), so that they can match the sale to an advert you were shown. The checkout and installation signals above carry that same hash: Meta receives it when you start paying, which means it reaches Meta even if you never pay, and Meta and TikTok receive it when an eSIM installation begins. They receive the hash, not the address itself. For Meta, TikTok and X the hashing happens on our server. For Google it happens in your browser, inside Google’s own tag, and only once advertising measurement is on for you: an unanswered banner or a refusal sends Google no address at all.

The signals our own servers send carry two more match keys, and both are one-way hashed here before they go. One is the same reference to your account that the browser tag is handed, hashed by us rather than sent as it is. The other is the two-letter code of the country your request came from, which is the form Meta asks for it in. Both go to Meta, on the purchase, the checkout and the installation signals alike, and both go whether or not your browser ever loaded Meta’s tag. That is what makes the server half work at all for somebody who closed the tab. Neither is sent when we have nothing to put in it, because the hash of an empty value is a real-looking identity that matches nobody.

Meta has one further route to the same thing, and it is worth reading twice. If you are signed in at the moment its tag is set up, we hand that tag your email address and a reference to your account. Meta documents that its tag hashes an address in your browser, with SHA-256, before it leaves the page, so that is what happens to the address. It documents nothing of the kind for the account reference, so we do not claim it: that reference is an identifier of ours, it carries neither your name nor your address inside it, and it may leave the page exactly as we handed it over. Meta calls this advanced matching, and its point is that every event the tag sends afterwards can be matched to you: not only a purchase, but the plain fact that you were on a page. It happens only while advertising measurement is on for you, and never for a visitor who is not signed in. Signing out, or withdrawing your answer to the cookie question, takes it back.

The iOS app asks you about all of this a different way, and the question there is Apple’s rather than ours. The app has no cookie banner. Instead iOS shows you its own prompt, the one asking whether SefereSIM may track you across apps and websites owned by other companies, and it asks wherever you are rather than only in the countries named above. What your answer controls is the advertising identifier Apple keeps on your device for advertisers. Agree, and that identifier goes to Meta beside what the app sends. Decline, and it is not read at all, so there is nothing for anything to carry. Declining costs you nothing else: the same plans at the same prices, and every part of the app working exactly as it always has. You can change the answer whenever you like, in the iOS Settings app under Privacy and Security, then Tracking, where SefereSIM has a switch of its own.

What the app tells Meta is two things of ours and no more: that you have started paying for an order, with the plan and the amount, and that the payment went through, with the plan, its name, the amount and the order reference. Meta’s own kit counts the app being installed and opened as well, which it does by default and which we have left on. Nothing the app sends carries your name, your email address, your account reference or anything about where you are. That same order is reported by our servers too, quoting the same order reference, so that Meta counts one sale rather than two. If you decline the prompt, that second route stops with the first: an order is created carrying the answer you had given, our servers read that answer when the payment settles, and an order carrying a refusal is not reported to any advertising platform. iOS blocks the app’s own connection to Meta’s addresses for the same reason, which is why the app declares them to Apple as tracking addresses.

Meta, Google, TikTok and X use what they receive under their own terms as well as ours. They are recipients of your data, not processors working only for us.

How long we keep it

• Order records are keptPurchases and payments stay on file for the legal and accounting periods we're required to keep them, even once the account is gone.
• Your accountDeleted when you delete it, from the iOS app or by writing to us. Deleting it does not switch off an eSIM you have already installed, and it does take away access to anything you bought and have not installed yet. What is on the account and is not part of the payment record goes at once, unless you have ordered from us. The notices we sent you about an order are the record of what we told you and when, so they stay for the same eighteen months as your name and go when it does.
• Your name and email addressKept for up to eighteen months after your last order, then removed from the records that stay. A card payment can be disputed with the bank months after it is made, and answering a dispute means being able to show who bought what. If you delete an account that never ordered anything, there is nothing to answer for, and your name and email address go within thirty days.
• eSIM identifiersThe ICCID and the supplier references for the profile issued to you stay with the order they belong to, for the same ten years, because they are how a payment is matched to what was actually delivered. Once your name and email address are gone, nothing on that record points back to you.
• Support emailKept for three years from the last message in the exchange, as the record of what was asked and what was agreed, then deleted.
• Analytics eventsKept in our PostHog project for the retention window set on that project.

Four periods cover what we hold under your account. Order and payment records, and the eSIM identifiers that belong to them, are kept for ten years, which is the tax retention period we work to. Your name and email address are kept for up to eighteen months after your last order, so that a payment dispute raised months later can still be answered, and go within thirty days of you deleting an account that never ordered anything. The notices we sent you keep the same eighteen months, for the same reason, and go when your name does. Support correspondence is kept for three years. Everything else on the account goes within thirty days of you deleting it. Two things keep clocks of their own, and are described above where they are listed: the Cloudflare request logs, and the analytics events in our PostHog project.

Your rights

You can ask us for a copy of what we hold, to correct it, to delete what we are not required to keep, to restrict what we do with it, and to object to the advertising measurement described above. Write to support@seferesim.com from the address on the account, and we will answer within the period the law allows us.

You can change your mind about advertising measurement whenever you like, with the "Cookie choice" link at the foot of the page, whether or not the banner was ever shown to you. Going from on to off reloads the page, because reloading is the only thing that actually stops advertising tags that have already started. Clearing this site data in your browser also removes the stored answer, and you are then back to the default for where you are.

If you think we have handled your data badly, you can complain to the data protection authority where you live.

KVKK notice for visitors in Türkiye

Visitors and customers in Türkiye are covered by KVKK, law 6698. The aydınlatma metni that law asks for is on the Turkish version of this page, at /tr/privacy, and it is in Turkish because that is the language it has to be readable in. It describes the same processing this page describes, under the headings the law names.

The veri sorumlusu named there is the company named at the top of this page, and no other: Vigilainte Inc., 8 The Green, Ste D, Dover, DE 19901, United States.

Changes to this page

When this page changes we change the date at the top. If we start doing something materially different with your data, we will say so plainly rather than quietly reword a paragraph.

Contact

support@seferesim.com. It reaches a person, not a queue.