Key takeaways
- Google Play limits SMS reading to default messaging apps, so store-listed wallets cannot scan your inbox.
- Paste and share-sheet import work everywhere; only a direct install can scan the messages you already forgot.
- An importer with that power should filter to voucher cues, exclude passcodes, and send one message at a time, only when opened.
- Messages that ask for a code are scams, not vouchers; an importer should never surface them.
If you have ever wondered why your gift-card app makes you copy and paste every voucher by hand, the answer is a policy, not a technical limit.
Where do vouchers actually arrive?
Employer benefits, restaurant coupons, gift cards from friends, refunds as store credit: in most markets these land as an SMS with the amount, a code and a date, written in whatever format the sender's system produces. Reading them is a parsing problem. Getting at them is the harder part.
The parsing is not trivial either. One sender writes the amount as a number with a currency symbol, another spells it out, a third gives a percentage off. The expiry appears as a date in any of three orders, as valid for 90 days, or not at all. The code may be a barcode number, a short alphanumeric string, a link, or two of those. A parser has to read all of them and flag the ones it is unsure of rather than guess.
The inbox is also the worst possible archive. A voucher message is pushed down by the next delivery notification within hours, and the cost of an inbox that is always open and never sorted is the same one that email imposes on a working day: everything is visible and nothing is found.
Why can't apps read SMS on Android?
Since 2019 Google Play has restricted the READ_SMS permission to apps whose core purpose is messaging: the SMS and Call Log permissions policy allows it only for the default SMS handler and a short list of exceptions, none of which is a voucher wallet. An app listed on Play therefore cannot read your inbox, however clearly it asks. The policy exists for good reason; the same permission reads one-time passcodes.
Android itself still has the permission. What changed is the store's rule about which listed apps may declare it. The operating system will grant it to an app installed from anywhere, after asking you.
There is one half-way route a store app can take: notification access. An app granted that permission sees the text of each new message as its notification arrives, which is enough to catch a voucher on the day it lands. It does not see the inbox, so it cannot find the vouchers from last spring, and it sees every other notification too, which is a broader grant than it sounds.
PeakVoucher does this from your own data. A wallet for the vouchers buried in your messages. Join the free beta →
What can a store app do instead?
Three things, and they are all fine as far as they go. It can accept a paste: you copy the message, open the app, paste, and the parser does the rest. It can register as a share target so the messaging app's share button sends the text across. Or it can rely on you typing. None of them scans the last six months of the inbox for the vouchers you already forgot.
| Method | Play Store app | Direct install | iPhone | Finds old messages |
|---|---|---|---|---|
| Scan the SMS inbox | No | Yes, with permission | No | Yes |
| Share sheet from the messaging app | Yes | Yes | Yes | One at a time |
| Paste the message | Yes | Yes | Yes | One at a time |
| Type it in | Yes | Yes | Yes | No |
How to import vouchers from SMS with a direct install
An app installed directly, outside the store, can request READ_SMS and Android will still ask you before granting it. That reopens the inbox, and it also raises the bar for how the app should behave, because now it can see everything.
- Download the install file from the developer's own site, not a mirror, and check it is signed by them.
- Allow installs from that source when Android asks; Android verifies the signature on every later update.
- Open the importer and grant the SMS permission when prompted. Nothing should be read before this point.
- Review the list of voucher-looking messages; open one to see the parsed amount, expiry and code.
- Correct anything the parser got wrong, then import. The message should be remembered so it is never offered twice.
What should a careful SMS importer do?
The rules a careful importer follows: read nothing until permission is granted and the importer is opened; list only messages that match voucher cues, gift card, voucher, coupon, benefit, redeem code, barcode; exclude anything matching a one-time-passcode pattern outright; send a message off the phone only when you open that specific one, and say so on the screen; remember which messages were imported so the same one is never offered twice.
These are the same fail-closed rules that govern the rest of a wallet, set out in how a wallet app should treat a code. An importer that could read a passcode and did not filter it out is a liability, whatever else it does well.
Ranking matters as much as filtering. An inbox of a year holds a few hundred messages that mention a shop; perhaps a dozen are vouchers. A message with an amount, a code and a date scores higher than one with a shop name alone, and the list should open on the strongest matches so that the first screen is vouchers rather than delivery updates. The weaker matches stay available further down for the odd one the cues missed.
Which messages should never be imported?
One-time passcodes, bank alerts, delivery codes and anything that asks you to click a link to check a balance. The last one matters: a text that says a gift card is waiting and links to a site that wants the card number is one of the standard gift card scams. An importer should surface messages that contain a code, not messages that ask for one.
Passcodes are easy to recognise and should be excluded before anything else happens: a short numeric code, a sender that is a bank or a login service, and wording such as do not share this code. A message that matches any of those should never appear in the list, even if it also mentions a shop, because the cost of showing one is higher than the cost of missing a voucher.
What about the vouchers you already have?
Once the inbox is scanned, the wallet exists; keeping it useful is a separate habit. Capture new vouchers on the day they arrive, record amount, expiry and code, sort by expiry and review weekly; the full method for keeping track of gift cards takes under a minute a week once the backlog is in.
The first scan is also the moment to be honest about what has already gone. A year of messages will contain vouchers that expired months ago. Import them anyway, marked expired: the total is the number that tells you what the habit is worth, and it is usually larger than expected.
How PeakVoucher does it
PeakVoucher ships the SMS importer in a direct install, exactly because it cannot carry the permission on Play. Open the importer, grant the permission, and it lists voucher-looking messages from the last year ranked by how voucher-like they are, with passcodes filtered out before the list exists. Open one and the assistant reads the amount, the expiry and the codes into a preview you can correct; import saves it and remembers the message.
The same parser sits behind paste and behind the share sheet, so a phone without the permission still gets everything except the scan.
Want this answered from your own data?
That is what PeakVoucher does. A wallet for the vouchers buried in your messages. In private beta — the waitlist is free.
Questions
Is a direct install safe?
Will PeakVoucher be on Google Play?
Does the importer read my bank codes?
Can an iPhone app import vouchers from SMS?
Why does the app need the whole inbox to find vouchers?
Sources
- Google Play. Use of SMS or Call Log permission groups (developer policy). https://support.google.com/googleplay/android-developer/answer/10208820
- Android Developers. Manifest.permission: READ_SMS. https://developer.android.com/reference/android/Manifest.permission#READ_SMS