Privacy

SMS Virtual Go, the website, and Receive SMS Go, the iPhone app, are one service. It is operated by Orbiva Ltd, a company registered in England & Wales under company number 17415938, which decides what is collected and is the company to write to about it. The address is under “Your rights” below.

An email address, and a password if you signed up on the website with one. The password is stored hashed by our authentication provider; nobody here can read it.

Your orders. Which service and country you chose, the number you were given, what it cost and when you bought it — and, if a message arrived, the verification code and the text of the message it came in.

Payment references. The identifier your payment provider gives us. Card numbers never reach our servers.

If you sign in with Google on the website. There is no password. Google gives us an identifier for your Google account and your email address and, because its sign-in includes your basic profile, your name and the address of your profile picture. Our authentication provider keeps these with your sign-in. We do not use the name or the picture for anything, and they are deleted with the account.

If you use the iPhone app. You sign in with Apple, so there is no password: Apple gives us an identifier for your Apple Account and an email address, which can be a private relay address that Apple forwards. Credit added in the app is paid to Apple, which sends us its signed record of the purchase — the credit pack, its price and currency, the App Store country and Apple’s transaction numbers. We keep that record with the credit it added. Your card and Apple payment details never reach us.

Notifications in the iPhone app. If you allow notifications and are signed in, the app sends us the notification token Apple issued for it on that iPhone. We store the token with your account, together with your alert choices — an alert when a code arrives, an alert when an order is refunded automatically, and whether an alert may show the code — and whether the token belongs to Apple’s production or test notification service. When a code arrives, or when an order’s time runs out without one and its credit is returned, we send the alert — if you left that kind switched on — to that token through Apple’s push notification service. The alert carries the name of the service the number was for and our reference for the order. Unless you switch off “Show codes in alerts” in the app’s Account tab, the alert text also contains the verification code, so the code passes through Apple and can appear on the Lock Screen. An alert never contains the phone number, the price or the rest of the message. We keep a note of which alerts were sent for an order so the same one is not sent twice; it is deleted with the order. When you sign out, the app has our server remove the token; we also remove it when you delete your account and when Apple reports that it is no longer valid.

Abuse signals. A hashed form of your IP address, and counters for actions like purchases and refunds. The plain IP is not stored — it is put through a one-way function with a secret, so it can be matched against a blocklist but not read back.

No postal address, no phone number, no identity document, no date of birth. We never ask for your name. If you sign up with an email address and a password, or sign in with Apple in the iPhone app, we never receive one either: the app asks Apple for your email address only. The one case in which a name reaches us is Google sign-in on the website, described above. No advertising cookies and no ad-network trackers. The only third-party script on the site is Google Analytics, described in the next section, and it runs with every advertising feature switched off. The iPhone app contains no analytics and no advertising code at all: it talks to our server and to Apple, and to nobody else.

We use Google Analytics 4 to count visits, see which pages and services people use, and find flows that break. Google truncates IP addresses at collection and does not store them. Google Signals, ad personalisation and remarketing are off, and the data is not used for advertising.

Besides page views, these steps are recorded so we can see where people drop off: opening a service page; pressing Buy (the service, country, price tier and price); creating an account or signing in (only whether it was by email or Google); starting a wallet top-up and a completed one (amount, currency, card or crypto, and the payment provider’s own reference for that payment); renting a number; a code arriving (and how many seconds it took); a refund or a failed order (and the reason, such as “out of stock”).

Never sent to Google: your email, your account id, the phone number you rented, the code or the text of any message, or which supplier a number came from. This is enforced in code — an event carrying anything outside a fixed list is dropped before it leaves.

Confirmed payments. A top-up is counted when the payment provider confirms it to our server, not when your browser returns to the site. To make that possible, if analytics was on when you started the top-up we keep Google’s random visitor id next to a one-way fingerprint of that payment — with the amount, currency and the payment provider’s reference for it, the same three values Google receives — for up to 30 days, then delete it. It holds no email, no account id and no card or wallet details. If analytics was off when you started the payment, nothing is kept and our server sends Google nothing about it. If you switch analytics off while a payment is still in progress, the record is deleted at that moment.

Google keeps event-level analytics data for 14 months, after which only aggregated totals remain.

If you are in the UK, EEA or Switzerland, no analytics cookie is set unless you accept the banner. Decline and only cookieless, aggregate signals are sent (Google’s consent mode), which cannot be tied to you. Elsewhere the analytics cookie is set by default; you can switch it off below.

The cookies this site can set:

• sb-* — your sign-in session. Essential; cleared when you sign out.
• svg_consent — remembers your analytics choice for 12 months. Essential; it exists so we do not ask again.
• _ga, _ga_* — Google Analytics; tells returning visitors apart with a random id, kept for up to two years. Set only with your consent where consent is required.
• svg_ev — analytics; written only while analytics is on, never after you decline. It lives for at most two minutes: when an action ends in a redirect (signing in, renting a number) it carries that step to the next page so it can be counted there, then it is deleted. It holds the step’s name and, for a number, the service, country, price tier and price — no id, no email, nothing that identifies you.

A code sent to your number is shown to you and stored with that order, together with the text of the message it arrived in, so you can find it again. Numbers are single-use; once an order closes the number returns to the pool and any later message arriving on it is not yours and is not shown to you.

Deleting your account deletes these codes and message texts along with the orders they belong to.

Orders — with their numbers, codes and message texts — stay while your account exists, so your history is complete. Delete the account and they go with it, along with your balance and its history, your sign-in and, for the iPhone app, your notification tokens.

Four things outlive an account deletion. None of them holds your email address or your account id:

Payment references. A record that a specific payment was already turned into balance: the payment provider’s reference for it — for a purchase in the iPhone app, Apple’s transaction number — with the amount and the time. We cannot trace it back to a person; the provider that issued the reference could. Without it, deleting an account would be a method for spending the same payment twice.

Abuse signals without the account. When a limit was tripped or a payment did not match, a note was made: the kind of signal, the time, and a short detail — the service, our reference for the order, or the payment provider’s reference and the amounts. On deletion the account id is removed from these notes and the notes themselves stay, so that patterns of abuse remain visible.

Delivery records. Whether an order received a code, and how long it took. It records the route, not the customer, and it is not published: the delivery percentages on the site are reported by the supply sources, not taken from these records.

The analytics record of a website top-up. Only if analytics was on when you started a card or crypto top-up on the website: the record described under “Analytics and cookies” — Google’s random visitor id next to a one-way fingerprint of that payment, with its amount, currency and the payment provider’s reference. It was never tied to your account, so deleting the account does not remove it; it is deleted on its own schedule, at most 30 days after the payment was started. Purchases in the iPhone app create no such record.

One more applies only to an account we blocked for abuse: the blocklist entry, a one-way fingerprint of its email address or IP address, stays, so that the block survives the deletion. It cannot be read back.

You can delete the account yourself, at any time, from the app or from the website. It happens immediately and is not reversible.

In the iPhone app: Account → Delete account. The screen says what goes, then “Confirm with Apple and delete” asks you to sign in with Apple once more, to confirm it is you. We then have Apple revoke the app’s sign-in for your Apple Account and delete the account. If Apple does not confirm it is you, or does not answer, nothing is deleted.

On the website: Settings → Delete account. The page lists what is erased, and you confirm by typing the account’s email address.

Either way, any credit left on the account is lost and cannot be restored. Deleting the account does not refund a purchase: credit bought in the iPhone app is refunded only by Apple, through reportaproblem.apple.com.

If you have an order still waiting for a code, deletion is refused until it finishes or is cancelled — otherwise the number would be stranded and the refund path lost. For a few minutes after an order was cancelled or ran out, deletion can also be refused while that order is being closed.

To rent you a number we ask a wholesale supplier for one. They receive the service and country requested — not your email, not your account, not your IP.

Payment providers see what they need to take a payment. Our hosting and database providers process data on our behalf under contract.

In the iPhone app, Apple takes the payment and tells us about each purchase and any refund. Apple also carries the app’s notifications: an alert we send passes through Apple’s push notification service on its way to your iPhone, with the content described under “What we collect”. Records of purchases made in the app are passed to nobody else.

Google receives analytics events — which pages were viewed and which of the steps listed above happened, in what order, from which country and device type — with a truncated IP address and no email, account id, phone number or code. See “Analytics and cookies” above.

We do not sell data. There is no advertising business here to sell it to.

You can see your data — it is on your account pages on the website and in the app — and delete everything yourself. To have it exported, or to correct an email address, write to us: neither the website nor the app has a screen for that yet. If you are in the UK or EU, GDPR rights apply and we do not require you to prove eligibility before honouring them.

Requests go to erdogandogan9292@gmail.com.

If this policy changes in a way that affects what we collect or how long we keep it, the date at the top changes and the change is listed in the changelog. We do not quietly broaden it.

This document describes the system as built, but it has not been reviewed by a lawyer. This notice stays until that review happens.