In short
CardScanner identifies a trading card from a photo. To do that, the app sends the photo off your phone: first to our server, then on to OpenAI, whose model reads the text printed on the card. The app asks you before it does this for the first time, and you can take the permission back.
Your collection stays on your phone. When you add a card from a scan, the photo kept with it is the same photo that was sent to identify the card; nothing in your collection is uploaded from there.
We keep no copy of your photographs. We do keep a record of every recognition request: when it happened, which device it came from, and which cards we matched. Right now nothing on our server deletes those records after a while. This policy says plainly what that means and what it does not.
Scanning is paid by subscription, after one free scan. The subscription is bought through Apple and managed for us by Adapty. We also use Mixpanel to count how the app is used: which screens people reach, whether scans succeed, whether people subscribe. Both services start working when you open the app, before you scan anything, and there is no switch in the app that turns them off. Neither of them receives your photos, the words you type into search, or your collection.
There is no account, no name, no e-mail address and no password. There is no advertising in the app, nothing that tracks you across other companies' apps and websites, and we do not sell your data.
Who we are, and how to reach us
CardScanner is an independent app. It is not affiliated with, endorsed or sponsored by the rights holders of the games it shows.
Write to us at quicklysearch.bot@gmail.com. That mailbox is hosted by Google, so an e-mail you send us is stored on Google's systems along with your own address and anything you attach. If you write from inside the app, the message comes with the app version and build, your iOS version, your device model and your language – nothing else, and you can see and edit all of it before you send.
Use of the app is governed by Apple's Licensed Application End User License Agreement: apple.com/legal/internet-services/itunes/dev/stdeula
The photograph of a card
Identifying a card sends the photograph off your phone. The app asks before the first time it does this, and it will not send anything if you decline. Declining costs you the photo, nothing else: the rest of the app keeps working.
What is sent
- The photograph, prepared for sending. The app draws the picture again from its pixels into a new image, shrinks it so the longer side is at most 1024 pixels, and saves that as a JPEG. Because the file is built from scratch, the location and camera details your phone writes into an original photo are simply not in it. As a second guard the app strips the Exif block, and our server refuses any image that still carries one.
- Which game you selected, if you selected one.
When you use the camera, the app sends the part of the frame inside the scanning rectangle. If the card cannot be read, the app offers to send the same shot whole; if you accept that offer, everything the camera saw goes with it. When you pick an existing photo instead, the whole picked image is sent.
What the model gets is a picture, not an extract from it
We instruct OpenAI's model to read only the visible text of the card. That is an instruction to the model, not a filter on the image. Anything else inside the frame – a face, a room, a document on the desk, the rest of your photo – is in the image we send. This is the honest reason the app draws a scanning rectangle and asks you to fill it with the card.
Live camera video never leaves your phone. Only the still photo you scan does.
What our server does with the photo
It holds the image in memory for the few seconds the request takes, passes it to OpenAI, and writes it nowhere. There is no image column in our database, and the only file storage our server uses holds card catalogues and price lists, not anything you send.
What our server does write down is a fingerprint of the photo: a one-way hash computed from the image bytes together with the game hint. It cannot be turned back into a picture. It does match if the same photo is sent again, which is how a retry gets the previous answer instead of being charged twice.
Retention at OpenAI
This is the one part of this policy that describes somebody else's system in detail, so we state it as that.
Our request is marked so that OpenAI does not store the response for later retrieval. Under OpenAI's published terms for its API, data sent through the API is not used to train their models, and inputs may be retained for a limited period for abuse monitoring. We have not enabled Zero Data Retention. We do not control what OpenAI keeps, and we will not tell you that OpenAI deletes your photo, because we cannot verify it.
The subscription
What is free and what is paid
Scanning is the paid part. Everything else in the app – searching for a card by name or number, browsing the catalogue, looking up reference prices, keeping your collection – stays free with or without a subscription.
You get one free scan without subscribing. It is used up by the first scan that actually gets you an answer: a list of matching cards, or our reply that the card is not in our catalogue. A scan that fails, that you stop, that runs into the daily limit, or where we ask you for another photo does not use it up. After that, scanning needs a subscription.
The app remembers that the free scan is used in the system keychain, so deleting and reinstalling the app does not bring it back (see "What the app keeps on your phone").
Apple handles the payment
You buy the subscription from Apple, in Apple's own purchase sheet. We never see your card number, your billing address or your Apple Account, and the app never asks you for them. What comes back to the app is Apple's confirmation of what was bought, and from then on the subscription's state: whether it is active, which plan it is, when it started, and when it renews or ends.
To cancel, use Apple's subscription settings on your iPhone (Settings, then your name, then Subscriptions; Apple explains it at support.apple.com/en-us/118428). The app has no cancel button of its own; deleting the app does not cancel anything. Refunds are Apple's to give: ask for one at reportaproblem.apple.com (support.apple.com/en-us/118223). "Restore purchases" in the app's Settings tab, and on the subscription screen, asks the App Store for a subscription already bought with your Apple Account.
Adapty
Adapty (Adapty Tech Inc.) runs the subscription for us: it shows the app which plans to offer, carries out the purchase through Apple, and tells the app whether a subscription is active. The Adapty code inside the app starts when you open the app, not when you first see a subscription screen. It sends Adapty:
- identifiers for this installation: a random identifier the Adapty code creates for itself, Adapty's own profile identifier, and Apple's identifier for vendor (IDFV) – an identifier that is the same for all apps from one developer on your phone;
- our pseudonym for your installation, as your customer ID in Adapty. The app passes it on at
the next launch after your phone has registered with Apple's App Attest (see "What leaves your
phone"). It is the value our server uses for you at that moment: the text
key:followed by a one-way hash of your App Attest key identifier. That deliberately lets a subscription, our server's records and Adapty's profile be joined to one installation. Adapty keeps the first such value it gets: if the app later has to replace its App Attest key, our server's identity for you changes and Adapty's customer ID does not; - the identifier Mixpanel uses for this installation (see "Usage analytics"), so that Adapty's records and Mixpanel's can be joined;
- your purchases: Apple's confirmation of each purchase and restore. If your Apple Account has ever bought CardScanner's subscription, the Adapty code also sends a reference to the latest such purchase when the app starts, so that Adapty can load your purchase history from Apple;
- which subscription screen you were shown;
- technical details of the phone and the installation: device model, iOS version, screen size, language and region settings, time zone, the country of the App Store you use, app version and build, when the app was installed, whether tracking permission has been granted (in this app it never is), and a standard web browser identification string;
- Apple's Search Ads attribution token – see "Advertising and tracking" below;
- technical logs of the Adapty code itself, such as which requests it made, how long they took and whether they failed;
- your IP address. Apart from seeing it with every request, the Adapty code looks up your phone's public IP address and writes it into your Adapty profile; we have not switched that off. To look it up, the phone makes a request to ipify (api.ipify.org), a public service that replies with the address it sees. From the IP address Adapty works out a country for your profile (it can differ from the country of your App Store).
Usage analytics
We use Mixpanel to see how the app is used, so that we can tell where it breaks and whether people find it worth paying for. The app sends events to Mixpanel's European endpoint (api-eu.mixpanel.com), for a Mixpanel project set up in the EU region.
What is counted. One event each time something of these kinds happens, with a few plain details attached:
- opening the app, and coming back to it;
- going through the first-run introduction, including the game you pick there;
- subscription screens: being shown one, which plan you tapped, whether a purchase or a restore went through, was cancelled or failed, and closing the screen;
- being sent to the subscription screen when you tap Scan, and using up the free scan;
- scans: that one started, how it ended (cards found, not in the catalogue, another photo needed, or an error), which game mode was on, how long it took, how many candidate cards came back, and what you did next if the scan did not settle it;
- adding a card to your collection: whether it came from a scan or from search, whether it was saved, and which game the card is from;
- searches: whether you typed a name, a number or both, and how many results came back – not what you typed.
When something fails, the event carries a short technical code for the failure, never the error message itself.
Attached to events: the app version and build, iOS version, the language and region set on your phone, the device model, operating system and screen size, whether the phone is on Wi-Fi, the type of mobile network and the mobile carrier's name where iOS still provides it, a random identifier for each app session, and – once you have seen it – which version of the introduction's subscription screen was shown. Most of these, without the network details, are also kept as a small profile for this installation.
What never goes to Mixpanel from the app: your photos, the text of what you search for, the names, numbers or sets of cards, identifiers of cards, anything in your collection, and our server's identity for your installation.
The identifier. Mixpanel knows this installation by a random identifier created on your phone the first time the app runs. It is not your IDFV and not the advertising identifier. It is kept on your phone and changes if you delete and reinstall the app. The app gives this identifier to Adapty (see above), which is what lets the two services' records be joined.
Location. Mixpanel, like any server, sees your IP address when the app sends it events. We have switched off Mixpanel's feature that works out your city and country from that address. The country Mixpanel sees from the app comes from your phone's region setting, not from where you are.
Subscription events from Adapty. Adapty sends our Mixpanel project its own records of subscription events – for example, a free trial starting, turning into a paid subscription, renewing or ending – under the same Mixpanel identifier. These records come from Adapty's side, not from the app, and they carry what Adapty holds about the subscription and your profile: the product, the price and the proceeds, the store transaction IDs, the country of your App Store, your Adapty profile ID, and the IP address and country Adapty associates with your profile.
Advertising and tracking
- There are no ads in the app, and no advertising SDK.
- The app never asks for permission to track you. The Adapty code reads the advertising identifier (IDFA) only when that permission has been granted, so in this app it is not read.
- We do not track you across other companies' apps or websites, we do not share your data for advertising, and we do not sell it.
- One thing about ads, stated so that it is not hidden. Once for each Adapty profile, the Adapty code asks iOS for an Apple Search Ads attribution token and sends it to Adapty. Apple designed this token to tell an app whether it was installed after someone tapped an ad for it in the App Store's search results. It works without the IDFA and without the tracking permission. It is how we can learn whether our own App Store ads bring people who subscribe.
What the app keeps on your phone
| What | Where | In device backups? |
|---|---|---|
| Your collection: card records, notes, condition, purchase price | a database inside the app's own storage | yes |
| Photos of your own copies | a folder inside the app's own storage | yes |
| An unfinished scan, including the photo bytes that were sent | a single file in the app's own storage | no, excluded |
| A key identifier for this installation of the app | the system keychain | per your keychain settings |
| A mark that your free scan has been used | the system keychain | per your keychain settings |
| Your settings: the consent flag, the chosen game, onboarding state, whether the subscription screen has been shown | system app preferences | yes |
| Adapty's identifiers for this installation, its copy of your subscription status, and its logs waiting to be sent | the app's own storage and preferences | mostly yes |
| Mixpanel's identifier for this installation, and events waiting to be sent | the app's own storage and preferences | yes |
Some of this deserves more than a row in a table.
Your collection is in your backups, and we did that on purpose. Your cards are your own records; they should survive a new phone. The cost of that choice is that deleting a card from the app does not reach into backups already made. Those copies remain until the backup itself is replaced or deleted, and that is between you and Apple, not something the app can do.
Deleting a card deletes its photo from the phone, once nothing else refers to it. But the collection database also keeps a short operations journal: one line for each card added and each card deleted, with a time stamp and the record's internal identifier. Deleting a card adds a line to that journal; it does not remove one. The journal stays on your phone and goes into your backups with the rest of the database.
One folder is never cleaned up. If the collection database is ever lost and has to be rebuilt
from scratch, the app moves the old photos aside into a folder named photos-set-aside-… instead of
deleting them, so that a recoverable collection is not destroyed by a bad startup. Nothing in the
app ever deletes such a folder. If this has happened on your phone, those photos remain in the app's
storage, and in your backups, until you delete the app.
An unfinished scan leaves the photo on disk. When a scan is interrupted, the app keeps the exact bytes it sent, so that reopening the app can finish the request instead of paying for it again. The file is excluded from backups. Besides the photo, the file holds the request identifier, the identity the request was signed with, our server's answer and the card you picked. It is deleted when you save the card from that scan, when you start a new scan or leave the result, or the next time the app reads it and finds it older than 24 hours. A result you look at and neither save nor leave keeps the file until one of those happens. The last case matters: the file is removed on the next read, not by a timer. If you never open the app again, the file stays where it is until you delete the app.
Both keychain items survive deleting the app. iOS keeps keychain items after an app is removed. The first holds the identifier of this installation's App Attest key, so that reinstalling does not hand you a fresh daily quota; it is marked so that it does not travel to another device. Because it survives, a reinstalled app on the same phone also gives Adapty the same customer ID as before. The second is only a mark that the free scan has been used; it contains nothing about you. It is not marked as device-only, so it can move to a new phone with a backup.
Deleting the app removes the collection, its photos, the catalogue, the unfinished scan, the settings, and Adapty's and Mixpanel's identifiers on the phone. It does not remove the two keychain items, anything already in a backup, anything on our server, or anything already sent to Adapty or Mixpanel.
What leaves your phone, and when
| When you | What leaves your phone | Where it goes |
|---|---|---|
| Open the app, or come back to it | the identifiers and technical details described under "Adapty" and "Usage analytics", a reference to your latest CardScanner purchase if there is one, and the events listed there | Adapty, Mixpanel |
| a request that shows your public IP address | ipify | |
| See a subscription screen | which screen it was | Adapty, Mixpanel |
| Subscribe, or restore a purchase | the purchase itself goes to Apple; Apple's confirmation and your purchase history go to Adapty; the outcome goes to Mixpanel | Apple, Adapty, Mixpanel |
| Scan a card | the prepared photo, the game you chose, a request identifier, a device attestation | our server, then OpenAI |
| that a scan started and how it ended (no photo, no card details) | Mixpanel | |
| Search by name or number | the name or number you typed, a request identifier, a device attestation | our server |
| whether you typed a name or a number, and how many results came back | Mixpanel | |
| Look up a reference price | identifiers of the card printing, from our own catalogue | our server |
| Open a card's details | identifiers of the card printing | our server |
| View a card's picture | a request for that image file | the catalogue source that hosts it (see below) |
| Add a card to your collection | where it came from and which game it is from – not the card | Mixpanel |
| Tap "Where to buy" | the card's name, printed number and set name, inside a search address | TCGplayer or eBay, in a browser view |
| Write to support | whatever you write, plus app version, iOS version, device model, language | our mailbox at Google |
| Anything at all | your IP address, as with every internet request | whoever you are talking to |
There is no account, no registration, no name and no e-mail address anywhere in this list.
The device attestation is Apple's App Attest. Your phone asks Apple to vouch that the request comes from a genuine, unmodified installation of this app, and sends us the result. It exists to stop somebody draining the service with a script; it carries nothing about you. If attestation is unavailable, the app still works, on a smaller quota.
What our server keeps, and for how long
| What we store | Why | How long |
|---|---|---|
| A record of each recognition: the device identity, the request identifier, the photo fingerprint, a daily IP key, the time, the outcome, and the cards we matched – their names, sets, numbers and picture addresses | to answer a retry without charging you twice, to keep quotas honest, and to see what the service costs | indefinitely. Nothing deletes these records |
| Token counts for each recognition | to see what the service costs | with the record above |
| A record of each counted request: device identity, request identifier, which endpoint, a daily IP key, the time, the status, how many results came back | quotas and diagnosing failures | indefinitely |
| One row per device identity, with first-seen and last-seen times | to apply a quota to a device | indefinitely |
| The public key and key identifier of your installation's App Attest key, with a use counter | to verify that later requests come from the same genuine installation | indefinitely |
| A daily counter of requests per IP key | rate limiting | indefinitely, though the key itself changes every day |
| A short-lived copy of a search or price answer | so that a repeated request returns the same answer instead of hitting the sources again | 30 minutes, then removed by a sweep that runs on later writes |
| A cached reference price, keyed by our own catalogue identifiers and not by who asked | so that repeated lookups do not hit the price source again | treated as stale after up to 24 hours; the stale row itself is not deleted |
| A random challenge issued during attestation | to prove the attestation is fresh | valid for 5 minutes; deleted when used, and expired ones are deleted the next time a challenge is issued |
We are not going to dress this up. There is no scheduled clean-up on our server. The records of what you scanned, and when, accumulate and stay. We think they should not, and a clean-up is something we intend to build; until it exists, this table is what is true. If that changes, the date at the top of this page changes with it.
Our server does not store anything about your subscription. Whether you subscribe is known to Apple and Adapty, not to our database.
We never write down your raw IP address. Two different one-way values are derived from it before anything is stored:
- a daily IP key – a keyed hash of the current date and your address. Tomorrow's key for the same address is a different value, so rows from different days cannot be tied together by it;
- an anonymous identity, used only when App Attest is unavailable – a keyed hash of your address and your app's user-agent string. This one has no date in it. It does not change from day to day, and it sits in our database indefinitely. If you share an address with other people, as happens behind most home and mobile networks, you share this identity with them too.
Your device identity is a hash, and we can undo it inside our own database. When App Attest works, your identity in every record above is a hash of your App Attest key identifier. We also store that key identifier itself, unhashed, in the table of registered keys – we need it to verify your next request. So the hash is not a wall: anyone with access to our database can join the two. The same identity, as it was when the app passed it on, is also given to Adapty as your customer ID, so Adapty's record of your subscription can be joined to our records too. We tell you this because calling it "anonymised" would be untrue. It is a pseudonym, and you keep your rights over data behind a pseudonym.
Two things are not in the tables above, and that is not an omission. Your photographs are not stored. The words you type into the search box are not stored either – they are used to run the query and are gone; not even a hash of them is written down.
What Adapty and Mixpanel keep, and for how long
What each of them receives is described above. We do not delete it on a schedule. We ask for it to be deleted when you ask us to (see "Your choices"), and when we close the project. We are not going to name a period, because nothing in the app sets one. Adapty's and Mixpanel's own terms may limit how long they keep data on their side; we do not restate those terms here, because we have not verified them.
Who else receives data
This list is built from what actually leaves a device or our server, not from the list of sources the app credits on its "Sources & trademarks" screen. Crediting a source and sending it data are different things, and only the second belongs here.
| Who | What they receive | Why |
|---|---|---|
| OpenAI | the photograph you scanned, and our instruction to read the card | reading the printed text |
| Adapty (Adapty Tech Inc.) | the identifiers, purchases, technical details, attribution token and IP address listed under "Adapty" | running the subscription |
| ipify (api.ipify.org) | a request from your phone, which shows it your IP address | the Adapty code uses it to learn your public IP address |
| Mixpanel | the events, identifier and technical details listed under "Usage analytics", and Adapty's subscription events | understanding how the app is used |
| Vercel | all traffic to our server, including your IP address, and the platform's own request logs | they host our server |
| Neon | everything in the retention table above, and the queries our server runs – including, for a search, the name or number you typed, while that query runs | they host our database |
| cards.scryfall.io, assets.tcgdex.net, images.ygoprodeck.com, optcgapi.com | a direct request from your phone for one card picture, including your IP address and which card it is | your phone loads catalogue pictures from them, not through us |
| Apple | an App Attest request from your phone; your purchase, if you subscribe | vouching that the app is genuine; selling the subscription |
| an e-mail you send to support, with your address and anything you attach | they host our support mailbox | |
| TCGplayer, eBay | a search for a card's name, number and set, when you tap "Where to buy" | showing you listings, in a browser view |
Two more companies appear in the app and are not on this list, deliberately. PriceCharting supplies the reference prices, but from a price list that our server downloads from them on its own schedule into our database; looking at a price does not contact them, and the download carries nothing about you. api.scryfall.com and api.tcgdex.net are contacted by our server for some price lookups, using identifiers from our own catalogue – they learn which card was asked about, and nothing about you or your device.
Your choices
Turning the sending of photos off
Open the app, go to the Settings tab, find Sending photos, and tap Withdraw. The app asks you to confirm. From then on no photo is sent, and the app asks you again before the next one.
Be clear about what this does and does not do. It stops future photos leaving your phone. It does not recall a photo already sent, and it does not delete the records described above. Those records stay until we delete them.
Not using the camera at all
Refusing camera access leaves the app usable. You can search for cards by name or number, browse the catalogue and keep your collection by hand. Nothing in that path sends a photograph.
Adapty and Mixpanel
There is no setting in the app that stops Adapty or Mixpanel, and turning the photo permission off does not stop them either. If you do not want this data collected, the honest options today are not to use the app, or to ask us to delete what was collected (below). If you keep using the app after that, collection starts again from the next launch.
Your subscription
Cancel it in Apple's subscription settings, and ask Apple for refunds, as described under "The subscription". Asking us to delete your data does not cancel a subscription.
Asking us what we hold, and asking us to delete it
Write to quicklysearch.bot@gmail.com with "privacy request" in the subject. We answer within 30 days, and we will tell you honestly what we found.
Here is the difficulty, stated in advance rather than after you have written. There is no account, so your e-mail address matches nothing in our database, nor at Adapty or Mixpanel. Our records are keyed to an installation of the app, and so are theirs, and today the app does not show you any of those identifiers. We will not claim to have found your records on the strength of an e-mail address – that would be a comfortable lie, and it would also mean we were willing to hand somebody else's records to whoever asked.
So a deletion request works like this:
- You write to us, from any address, saying what you want deleted.
- We ask you to prove the request comes from the installation you mean. That means doing something from the phone in question at a time we agree, so that we can find the matching record on our server. We will tell you exactly what to do, in that reply.
- We follow that record to Adapty and Mixpanel. Adapty holds our identity for your installation as your customer ID, and Adapty's profile holds the identifier Mixpanel uses. That link exists only if your phone registered with App Attest, the app passed the identity on at a later launch, and the identity has not changed since then. If not, we will tell you what we could and could not find, instead of guessing.
- We delete what we can identify: on our server, the recognition records, the request records and the device identity row for that installation, and the registered App Attest key; and we ask Adapty and Mixpanel to delete the profile and events tied to that installation.
- We tell you what we did not delete, and why. We cannot reach anything already handed to OpenAI, and we cannot reach our hosting providers' own operational logs or their backups. We cannot touch a backup of your phone; that is yours and Apple's. Apple keeps its own record of what you bought from it. If a record cannot be tied to your installation, we will say so rather than delete somebody else's.
If you cannot complete step 2 – the phone is gone, the app is uninstalled – say so, and we will tell you what that means in your case instead of guessing at it.
Children
CardScanner is not directed to children under 13, and we do not knowingly collect data from them. If you believe a child has sent us a photo, write to us and we will delete what we can identify.
Changes to this policy
If we change how the app handles your data, we update the date at the top of this page, and where the change matters we say so inside the app. The app records that you gave permission to send photos, but it does not record which version of this policy you read at the time – so if a future change is significant, we will ask again rather than assume the old permission covers it.
What changed on 27 September 2026. The previous version, of 25 September 2026, said that the app had no analytics and no third-party code. That stopped being true when we added the subscription. This version adds Adapty, Mixpanel and ipify, what they receive and why, the free scan and the keychain mark that records it, and how a deletion request now reaches Adapty and Mixpanel. It also corrects a few details of the previous version: what the unfinished-scan file holds and when it is deleted, that a collection photo is the photo that was scanned, what our server's file storage holds, and when expired attestation challenges are deleted. How photos are sent and handled has not changed.