A gift card app is a payment you take once and a balance you owe until it is spent.
The payment is the part Apple has rules about. The balance is the part you have to build, and nobody builds it for you. Apple's App Review Guidelines, read on 14 October 2026, split gift cards by what the card can be redeemed for. A card that buys digital content inside your app has to be sold through in-app purchase. A card that buys a haircut, a class or a table has to be sold some other way, because the service is consumed outside the app. Almost every small business card is the second kind, which is why a gift voucher usually belongs beside the diary in a booking app for business rather than behind a paywall.
What follows is the exact wording of the two rules, where the balance has to live, what Apple Wallet will and will not do for you, and the five ways a gift card scheme quietly loses money. Every guideline number, pass style and file name below comes out of Apple's own documentation on the date above.
Start hereThe short version
What the card buys decides how you are allowed to take the money.
Guideline 3.1.1 is the one people quote, and its own words are these. Digital gift cards, certificates, vouchers, and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase. Physical gift cards that are sold within an app and then mailed to customers may use payment methods other than in-app purchase. Read it twice. The only gift card that sentence lets off in-app purchase is a plastic one you put in the post.
The rule that covers everything else is 3.1.3(e), Goods and Services Outside of the App. If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. A voucher for sixty minutes in your chair is a service consumed outside the app. So the money must go somewhere other than in-app purchase. Not may. Must.
Can you sell a gift card inside a phone app?
Yes, and there is nothing to apply for. The thing that gets apps rejected is picking the wrong rail, because Apple does not treat the two cases as a preference. They point in opposite directions. Put a card form on a voucher that unlocks premium features and you have taken a payment that 3.1.1 says could only have been an in-app purchase. Put a voucher for a massage through in-app purchase and you have broken 3.1.3(e), which told you to use anything but. Same paragraph of the same document, two rejections, opposite causes.
The genuinely hard case is the card that buys both. A studio sells a voucher that covers a class in the room and a video in the app. One product, two rails, and no wording in the guidelines that blesses a mixture. The workable answer is to stop selling one thing: a service voucher paid by card, and app credit or a content unlock bought through in-app purchase. Two products, two buy screens, two balances. It is more work and it is the version that survives review.
One line above those rules is worth reading before you design the screen. The section opens by saying that apps in it cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a). For a service voucher that is not a trap, because a card sheet inside your own app is the method Apple just told you to use. It becomes a trap if your plan was to send people out to your website to buy the same voucher, or to tell them it is cheaper there.
If part of what you sell really is digital, then in-app purchases is the mechanism, and the gift card becomes a consumable you grant on redemption rather than a thing you charge for twice. Decide this before you write any code. The rail you pick shapes the database, the refund process and the receipt the buyer gets, and changing your mind later means changing all three.
Apple, App Review Guidelines, sections 3.1.1 and 3.1.3(e), read 14 October 2026
Check yours
Which payment rail your card has to use
Tick everything a buyer could spend the card on. The rail follows what the card buys, not what the card looks like.
Nothing ticked yet. Pick what the card buys. Every answer below is the rule out of Apple's App Review Guidelines, read on 14 October 2026.
Where does the gift card balance actually live?
In your database, and nowhere else. Neither iOS nor Android holds money on your behalf. There is no system feature that remembers a customer has eighteen pounds left with you. The phone shows a number your server sent it, and if your server is wrong the phone is confidently wrong too. That is the whole reason a gift card is a back end job wearing a front end.
Store it as a ledger rather than as a number. One row per event: issued, redeemed, refunded, topped up, expired. Each row carries an amount, a timestamp and who did it, and the balance is the sum of the rows. A single balance column is quicker to write and it is the design that loses money, because the first time two members of staff redeem the same code at the same moment you have no record of which visit the money paid for. With a ledger you can answer the awkward question, which is not what is the balance but what happened.
Then the counter. A card is rarely spent in one go, so partial redemption is the normal case, not the edge case. Someone with fifty on a card and a thirty five pound bill needs fifteen left and a receipt that says so. Staff need to find a card by its code and by the buyer's name, because people arrive having lost the email. Redemption has to be one action that either happens or does not, and it has to be recorded even when the till is busy. Work out what happens when the shop broadband drops before you ship, because that is the afternoon the scheme gets abandoned.
One more line of 3.1.1 bites here if any part of your balance came through Apple. Any credits or in-game currencies purchased via in-app purchase may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases. So store credit bought through in-app purchase and an expiry date cannot coexist. For a card sold by ordinary card payment, expiry is a matter of consumer law where you trade rather than a platform rule, and that is a conversation with your accountant. Whatever the answer is, it belongs on the buy screen.
A balance that pays for a seat is the same ledger with a timetable in front of it, which is most of what a class schedule app already is. If you have one, the gift card is a second source of payment against bookings you already model, not a separate product. If you do not, build the ledger first and the card second.
Apple, App Review Guidelines, section 3.1.1 on credits and expiry, read 14 October 2026
Should the card live in Apple Wallet?
Usually yes, and the pass style you want is the store card. Apple says it in one line: use store card passes for discount, gift, and store loyalty cards. There are five styles in total, boarding pass, coupon, event ticket, store card and generic. Setting the store card style gets you a layout Wallet already understands, with room for a balance, store points, terms and conditions and other helpful information. A balance field can carry a currency code, so the pass shows money rather than a bare figure. Add a barcode if your till scans one, or skip it if the pass talks to an NFC reader instead.
Making a pass is more clerical than clever. Apple's own steps are these: create the source files, create a pass type identifier, generate a signing certificate, create a digital signature for the pass, create the signed bundle. The pass type identifier is a reverse DNS string you register in your developer account and it has to match the certificate you sign with. The bundle holds a pass.json, your images, a manifest.json listing every file against its hash, and a detached signature in a file called signature. Zip the directory, change the extension from .zip to .pkpass, and keep stray files like .DS_Store out of it.
Getting it onto a phone has four documented routes. Add the pass automatically during an action in your app. Add it from an app or an App Clip. Offer a download on a web page. Send it as an attachment in an email. In an app you show a PKAddPassButton and then present a PKAddPassesViewController, which prompts before each pass is added. A silent add needs the backgroundAddPasses capability, requested once, and the person can change that permission in Settings later. On the web you show an Add to Apple Wallet button and serve the file when it is clicked.
Two guideline lines apply to the pass itself, and both are short. Wallet passes can be used to make or receive payments, transmit offers, or offer identification, and other uses may result in the rejection of the app and the revocation of Wallet credentials. A gift card is squarely inside that. And Apple asks you to ensure that Wallet passes include valid contact information from the issuer and are signed with a dedicated certificate assigned to the brand or trademark owner of the pass. So the shop's phone number goes on the back of the card, and the certificate belongs to the shop.
The honest limit: a pass is a display, not a ledger. Wallet does not know what the balance is. It shows the last number you signed into the pass and will happily show it for months. Treat the pass as a convenient copy of a truth kept on your server, and never as the thing staff check before handing over a service.
Apple Developer, Wallet Passes, store card passes and building a pass, read 14 October 2026
What goes wrong with gift cards, and how do you stop it?
Double redemption first, because it is the one that costs cash. Two tills, one code, both reading a balance of forty and both writing back a balance of ten. The fix is not a faster screen. It is making redemption a single write that the database either accepts or rejects, with the amount and the card on the same row, so the second attempt fails loudly instead of overwriting the first. Append to a ledger. Never read a number, subtract in the app and put it back.
Then the stale Wallet pass. Apple's rule for changing one is that you update a pass by distributing a new version with the same pass identifier and serial number, or you run a web service that pushes the change to devices that registered for it. Neither happens by itself. A customer who spent half their card last month is showing staff the old number unless you built the push. If you are not going to build it, leave the balance off the pass and put the code on it instead.
Third, counting the float as takings. A sold card is money you have received and a service you still owe. Put it in the day's revenue and you will spend it twice, once as cash and again as a free haircut in March. Keep issued value and redeemed value as two separate figures on the owner's screen, and make the difference visible. That number is the only honest answer to how the scheme is going.
Fourth, refunds and resale. If any part of your card went through in-app purchase, 3.1.1 draws a hard line on gifts: such gifts may only be refunded to the original purchaser and may not be exchanged. On the card payment side, a voucher bought with a stolen card and spent the same afternoon is a chargeback you cannot claw back from the chair it paid for, so a delay or a cap on first purchases is cheaper than it looks. Fifth, and smallest, disclosure. Apps using Apple Pay must provide all material purchase information to the user prior to sale of any good or service, so the expiry, the places it can be spent and whether it can be topped up go on the buy screen, not in a page nobody opens.
Prepaid packs are the same problem under a different name. Ten sessions sitting on an account is stored value, so a gym membership app needs the same ledger, the same audit trail and the same answer to the question of what happens when somebody leaves with four unused. Build the mechanism once and sell it under whatever name your customers use.
Apple Developer, Wallet Passes, distributing and updating a pass, read 14 October 2026
Five kinds of gift card, and what each one has to use
| What the card buys | How you take the money | Where the balance lives | A Wallet store card fits |
|---|---|---|---|
| Digital content or features in your app | In-app purchase only, guideline 3.1.1 | Apple's purchase record, mirrored in your own ledger | No |
| An appointment, a class or a table | Apple Pay or card entry, guideline 3.1.3(e) | Your database, as a ledger | Yes |
| A plastic card you post to the buyer | Any card method, named in 3.1.1 | Your database, as a ledger | Yes |
| Account credit that buys both | Split it, one product per rail | Two ledgers that have to agree | No |
| A paper voucher sold at the counter | No store rule, the money never touched the app | Your database, as a ledger | Yes |
Where this lands if a builder generated your app
None of the rules soften because an agent wrote the code. You still pick the rail, you still own the ledger, and on iOS you are the one who presses submit. App Review Guideline 4.2.6 is the reason for that last part. Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. The gift card terms, the refund policy and the money are yours, so the submission is too.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and keeps a two way GitHub sync so the code is never trapped. It is $25 a month and there is no free tier. For a gift card that means you can have a buy screen, a redemption screen and a staff lookup in front of real customers quickly, and change them the week after when the counter tells you what is missing.
The limit is worth saying plainly. A generator will not decide your payment rail for you, because that decision depends on what you sell and only you know that. It will not sign a Wallet certificate in your business name either. Ask for the ledger, the partial redemption and the owner's report first. They are the parts that make a gift card a scheme rather than a screen.
Questions people ask about gift cards in an app
Yes. There is no gift card permission to apply for, and nothing to switch on. What you have to get right is how you take the money. Apple's App Review Guidelines split gift cards by what the card can be redeemed for. Guideline 3.1.1 says digital gift cards, certificates, vouchers and coupons which can be redeemed for digital goods or services can only be sold in your app using in-app purchase. Guideline 3.1.3(e) says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase, such as Apple Pay or traditional credit card entry. A voucher for a haircut or a table falls under the second one. Read on 14 October 2026.
Describe the card, then build the ledger under it
Write down what the card buys, which decides the rail. Then ask for the three screens that make it work: buy, redeem, and a lookup your staff can use with a customer standing in front of them.
Start building