Gift cards in a banking app are an engagement and revenue feature: users already trust the app with their money, and the app keeps a slice of every card sold. The supply side runs through one distributor or aggregator contract and one API, which makes this closer to a product decision than an infrastructure project.
This playbook walks the reasons fintechs add the feature, how supply works, the product decisions that matter and what to measure once it is live.
Why fintechs add a gift card catalogue
Three reasons come up in every case. First, transaction frequency: a catalogue gives users a reason to open the app between salary day and bill day, and each purchase is a payment the app processes end to end. Second, non-interest revenue: every card sold carries a spread for the app, with no credit risk and no logistics behind it. Third, gifting: cards are bought as presents, which brings seasonal spikes and pulls in recipients who may not be customers yet.
None of this requires new user behaviour. People already buy gift cards; the app moves the purchase to where the money already sits.
How the supply side works
No bank signs fifty brand contracts. One agreement with a distributor or gift card aggregator covers hundreds of brands, regional availability and stock, delivered through a catalogue API. The app requests a code the moment a user pays and shows it in seconds; the integration path is the same as for any storefront, with sandbox, catalogue sync and idempotent ordering as the load-bearing parts.
The commercial setup is one negotiation, one settlement schedule and one reconciliation feed, which matters in a regulated organisation where every new supplier passes procurement and risk review.
Product decisions that decide adoption
Curated or full catalogue. Start curated: twenty to fifty brands your users recognise beats five hundred they scroll past. A shorter list is also easier to support and to keep in stock. Expand by watching search terms users type into the catalogue.
Payment flow. The card should be payable from the wallet balance or a saved card in two taps. Any redirect to an external checkout gives away the one advantage a banking app has, which is that the money is already there.
Delivery and refunds. Deliver the code inside the app, not by email, and keep it retrievable from purchase history. Decide the refund policy before launch: a revealed code is a bearer instrument and cannot be taken back, so most apps refund only undelivered orders and say so plainly at checkout.
The unit economics, in one paragraph
The app buys each card below its face value and sells at face value; the difference between face value and trade price is the spread the app keeps. It varies by brand and region, and it is thin per unit, so the feature earns through volume and repeat purchase rather than through any single sale. Treat it as a payments-adjacent revenue line, not a standalone business case.
Compliance notes, kept general
The supplier relationship starts with KYB in both directions: the distributor checks the app, the app’s risk team checks the distributor’s sourcing and licences. On the consumer side, digital codes need their own terms: delivery commitments, the refund position, and expiry disclosures where local rules require them. None of this is exotic for a fintech; it is the same review as any new payment-adjacent product, applied to a new product type.
What to measure
Three metrics tell you whether the feature works. Attach rate: what share of active users buy at least one card in a quarter. Repeat purchase: whether buyers come back monthly, which is where the volume lives. Seasonality: gifting peaks around local holidays and Q4, so judge the feature on a full year, not on a quiet spring month.
Frequently asked questions
How do banking apps make money on gift cards?
The app buys cards at a trade discount from a distributor and sells them at face value, keeping the spread on each sale. There is no inventory risk when supply is API-based, since each code is bought at the moment the user pays. Per-unit earnings are modest, so the feature is judged on volume, repeat purchase and its effect on app engagement rather than on any single transaction.
How hard is it to add gift cards to an app?
The technical work is one catalogue API integration: sandbox testing, catalogue sync, an idempotent order flow and secure code display. Teams with a working payment flow typically ship in weeks. The longer path is commercial and compliance onboarding with the supplier, which runs in parallel, so the practical timeline is set by procurement as often as by engineering.
Do users buy gift cards in banking apps?
Uptake concentrates in two behaviours: gifting around holidays, and monthly self-use in categories such as gaming, streaming and app-store credit. The feature performs best when checkout takes two taps from an existing balance and the catalogue leads with brands the local audience recognises. A small curated catalogue with the right brands beats a long list of unfamiliar ones.
Which gift card brands should a banking app stock first?
A curated list of twenty to fifty brands the local audience already recognises, weighted towards gaming, streaming, shopping and app-store credit. A short list is easier to support, easier to keep in stock, and converts better than five hundred logos users scroll past. Expand it by watching the search terms users type into the catalogue, since those name the missing brands more reliably than any market report.
Can you refund a gift card bought through a banking app?
Only while the code is undelivered, in most apps. A revealed code is a bearer instrument: once the user has seen it, it can be redeemed by anyone holding it, so it cannot be taken back. The workable policy is to refund failed or undelivered orders in full, state at checkout that delivered codes are final, and keep delivery status logged so support can tell the two cases apart.