Fintech payment app marketing strategy: the India launch plan for 2026

India processed 24.51 billion UPI transactions worth ₹29.82 lakh crore (about $339 billion) in August 2026, per NPCI data reported by Entrackr — a daily average of 791 million transactions and ₹96,205 crore (about $10.9 billion). Two apps hold 78% of it, and an NPCI market-share cap they both breach has a December 2026 deadline — next quarter, not this one.

App-level share, from NPCI's July 2026 release (August app-level data was not yet published):

The remaining ~13.7% is where Navi, super.money, CRED, BHIM, Fampay and the rest sit; per-challenger shares were not broken out in the source reporting, so treat any you see as unverified.

The structural fact that changes your strategy: NPCI's 30% market-share cap for UPI apps has a deadline of December 2026 — the quarter after this one, so roughly one planning cycle away — and PhonePe at 45.89% and Google Pay at 32.33% are both far above it. Either it is enforced, forcing a redistribution of roughly 48 percentage points of share and creating the largest acquisition opportunity in Indian consumer apps, or it is deferred again, as it has been before. Do not build a plan that assumes either outcome. Build a base plan that works at organic growth rates, plus a pre-approved surge plan — creative, budget, verification, capacity — you can trigger inside a week.

This post plans India only. One US contrast is worth carrying, because it sets the scale of the problem: Cash App reported 59 million monthly actives and $7.2 billion revenue in 2025, up 18%, at roughly $108 annual revenue per user, per Business of Apps. Venmo's latest figures are 2023 — 83 million users, $276 billion payment volume, $1.1 billion revenue, monetized through a 2.9% merchant fee and a 1% instant-withdrawal fee. Both US models monetize the payment itself. India's does not, and the revenue-per-user section below shows what that costs. It also invalidates most US payments-marketing advice here, so no US plan appears in this post.

Both stores classify payments apps as Finance.

Two different events, and conflating them is the most expensive mistake in this category. The activation event is the first successful transaction; the revenue-predictive event is the first monetized action — a bill payment, recharge, gold buy, or an insurance or credit product accepted. The first proves the app works. The second pays for the install.

The ladder, regulated steps in place:

install
  → mobile number verification (SMS device binding)
  → bank account discovery + linkage
  → UPI PIN set
  → first successful transaction (P2P send or scan-and-pay)
  → second transaction within 7 days
  → first merchant / P2M transaction
  → first monetized action (bill pay, recharge, gold, insurance, credit)

The abandonment cliff is UPI PIN setup. It needs SMS-based device binding and debit-card credentials, and it is where a user who was happy to install decides this is a lot of work. Business of Apps' finance benchmarks, updated 7 January 2026 from their Fintech App Report 2025, put activation at roughly 14% by day 30 — read that as first transaction: about 86% of your installs never transact once.

Retention is the worst in finance. Business of Apps notes that stock trading apps have the highest average retention within finance and payments the lowest, against a finance-wide D30 of 4.2%, exact split paywalled. One more benchmark, with its caveat attached: Adjust reports fintech D1 retention at 22% against an all-category median of 26%, but the source page carries no measurement period at all and the numbers line up with 2022–23-era releases — treat both as undated. They are a directional floor. They are not a 2026 measurement, and they are not a target.

The UPI economics problem, stated plainly

UPI peer-to-peer carries zero merchant discount rate by law. The app earns nothing on the transaction. Not a small amount — nothing. So your LTV model cannot be per-transaction, and any spreadsheet that multiplies transactions by a take rate is fiction.

Two commercially important qualifications that get left out of the usual "UPI is free" framing:

• RuPay credit card on UPI does carry MDR on merchant transactions above ₹2,000. It is the one UPI flow with an interchange economics attached, which is why every large app pushes credit-on-UPI onboarding hard — it converts a zero-revenue habit into a revenue-bearing one without changing the user's gesture.
• The government's P2M incentive scheme reimburses acquirers on low-value merchant transactions, partly offsetting the cost of running zero-MDR small-ticket volume. The scheme is set annually and its size moves with each Budget, so treat any number you model from it as provisional and confirm the current year's terms before you put it in a plan.

Neither changes the headline: the P2P send that most installs are acquired for still earns nothing.

What actually monetizes, per Inc42's breakdown of PhonePe's business:

PhonePe's H1 FY26 revenue was ₹3,918.5 crore (about $445 million) — payments ₹3,238 crore (86%), financial services ₹452.8 crore (about $51 million, 11.55%) — on a loss of ₹1,444 crore (about $164 million), widening 20% year on year ahead of a planned IPO. The category leader, with 700 million registered consumers and 46% share, is not profitable on this model.

What that means for your media plan: the user who installs, links a bank and sends money to a friend has cost you money and returned nothing. Acquisition economics only close when a meaningful share of those users take a monetized action — so underwrite UA against lending, insurance, bills and merchant economics, never against transaction volume, and instrument the monetized action as a first-class event from day one. The next section puts a number on how far that gets you.

About ₹112 (roughly $1.27) of gross revenue per registered user per year at the category leader — below the ₹163 planning CPI used later in this post. That comparison is the defining fact of the category, and it is why every budget here has to be underwritten by something other than the payment.

The arithmetic, from PhonePe's own reported numbers:

Two qualifications, both of which make the picture worse rather than better.

Most of that ₹112 is not attributable to a consumer install. Payments was ₹3,238 crore of the ₹3,918.5 crore — 86% of revenue — and the bulk of it comes from merchant interchange, device subscriptions across roughly 9.2 million deployed SoundBoxes and EDC terminals, and biller commissions. A SoundBox rented to a kirana store is not revenue from the consumer who installed the app. Strip down to the line that most resembles consumer revenue, financial services, and you are at roughly ₹13 per registered user per year.

Registered is not active. Seven hundred million registered consumers is a cumulative number covering a decade of acquisition. Revenue per monthly active user is higher than ₹112; revenue per user acquired last month through paid media in a saturated market is lower.

This is why PhonePe loses ₹1,444 crore in a half-year while holding 46% of the largest real-time payment network on earth. It is the structure, not the execution: zero MDR on the hero action, revenue that lives in merchant and device lines, and a consumer base acquired when installs were cheap.

What does a challenger's cross-sell have to deliver?

Take the planning numbers used later in this post — a ₹163 CPI, a 14% install-to-first-transaction rate, and 31% install fraud. Cost per fraud-net activated user is ₹163 ÷ (0.69 × 0.14) ≈ ₹1,687 in media, plus a ₹150 first-transaction incentive: call it ₹1,850 per activated user.

Now underwrite it. Lending referral is the highest-value cross-sell available to a payments app: at a 1.5–3% commission on a ₹50,000 personal-loan disbursal, roughly ₹1,200 gross per disbursal.

There is no lending conversion rate that closes this. Add bill-pay commissions (a few rupees per bill, so perhaps ₹20–40 a year from a habitual user), insurance (₹300–800 per policy at low single-digit conversion) and digital-gold spreads on small tickets, and a good year reaches perhaps ₹60–120 per activated user. That is the same order of magnitude as the leader's ₹112 — and roughly a fifteenth of what the install cost.

Three conclusions follow, and a payments plan that states none of them is not finished:

1. Paid consumer UA does not pay back on consumer revenue in Indian payments. Not at a ₹163 CPI, not at ₹78. Put that sentence in the plan rather than letting a CAC table imply otherwise.
2. The economics close on the merchant side or they do not close. Interchange, device subscriptions and biller commissions are where the ₹112 actually comes from — which is what the payment-aggregator track above buys you, at the cost of a different acquisition motion with a different cost structure.
3. If you run consumer paid UA anyway, run it as a top-up on an organic, distribution-led or partnership-led base, funded as a strategic position rather than against year-one contribution margin. Give it a named payback horizon and a named activated-to-cross-sell conversion target, and kill it on schedule if that conversion rate does not appear.

That is the replacement for the per-transaction LTV model this post has just demolished. It is a worse answer than the one it replaces, and it is the true one.

Your NPCI onboarding, ad platform verification, fraud controls and permissions architecture. The gate on a consumer UPI app is NPCI's Third-Party Application Provider framework, not an RBI payment-aggregator licence — and that distinction decides your entire launch timeline, so get it right before anyone builds a plan around the wrong one.

The actual gate: NPCI's TPAP framework

A consumer UPI app is a Third-Party Application Provider. It is not a payment aggregator. PhonePe, Google Pay and Paytm all reach the UPI rails as TPAPs, riding a sponsor bank's Payment Service Provider licence. That is the structure you are building toward, and there are three sequential steps in it:

Three consequences for the marketing plan. First, your sponsor bank is a dependency you do not control — bank appetite for new TPAPs varies, and a bank that goes cold restarts the clock. Second, the 30% market-share cap is applied to TPAPs, so it is the framework your upside case sits inside, not an abstraction. Third, none of these steps publishes an SLA, which is why the timeline section below gives estimates and labels them as estimates.

Where RBI payment-aggregator authorisation actually applies

Separately, and optionally. RBI's Payment Aggregator Directions govern merchant-side aggregation of card and netbanking flows — onboarding merchants and settling their money. If your product is a consumer UPI app, this does not apply to you. If you also decide to acquire merchants and process card or netbanking payments for them, it becomes a second, parallel licensing track with its own capital requirement:

• The Directions were issued 15 September 2025 and took effect immediately. Non-bank payment aggregators need a Certificate of Authorisation; banks do not. Three categories: PA-P for physical point of sale, PA-O for online, PA-CB for cross-border.
• Net worth ₹15 crore (about $1.7 million) at application, rising to ₹25 crore (about $2.8 million) by the end of the third financial year post-authorisation, maintained on an ongoing basis.
• Merchant onboarding requires due diligence via the Central KYC Records Registry where available, with a simplified route for merchants under ₹40 lakh (about $45,000) annual turnover. The Directions are explicit: "PA shall undertake background and antecedent check of the merchant."
• Segregated escrow with a scheduled commercial bank, day-end balance never below amounts realised but unsettled.
• Prohibited: marketplace business, co-mingling cross-border funds, ATM PIN authentication for card-not-present, cash-on-delivery escrow. Cross-border transactions are capped at ₹25 lakh (about $28,000) each.
• PA-CB licences have issued through 2026 — 19 firms at the latest published list, Juspay among them in January 2026.

The reason this matters commercially rather than legally: merchant acquiring is where the revenue is, as the next section shows. So the PA track is not a compliance footnote you can defer indefinitely — it is the route to the only line item that pays for consumer acquisition. Decide early whether you are building a consumer app on someone else's merchant economics or building both.

Confirm the current NPCI circulars and RBI directions with your compliance counsel before you commit to either track; both move, and this post is a September 2026 snapshot.

Ad platform verification

Google Ads requires financial services verification in India through G2 Risk Solutions: obtain verification, receive a unique code, submit it to Google. Payments apps, wallets and payment aggregators are all in scope — being a TPAP rather than a PA does not exempt you. The wording is unforgiving — business information "must exactly match with the business details available on the relevant financial services registries," and false information means verification revoked with immediate effect plus possible account suspension. Put this on the critical path with no float.

Meta's SEBI verification mandate is securities-specific, so a pure payments app sits outside it. The moment you advertise wealth, broking or investment cross-sell to Indian users you are in scope, needing the SEBI-registered payer and beneficiary plus a public disclaimer on every in-scope ad. Meta's broader financial-advertiser verification has been expanding through 2026, but no definitive India-payments requirement was verifiable from a primary source. Do not plan around a rule nobody can confirm — ask your Meta representative in writing before committing budget.

Fraud controls are a launch requirement here, not an optimization

AppsFlyer's State of Ad Fraud 2026, built on 106.4 billion installs, puts finance at roughly 31% fraud, against 11.7% on iOS and 14–15% on Android overall — the highest vertical figure in the dataset as reported. By channel: affiliates around 40% versus self-reporting networks around 1%, a 36-fold gap, and "affiliate" is exactly how CPI networks are structured. Note the circularity — an MMP's fraud rate is its own detection rate, so 31% is a floor.

That is why an MMP is not optional here. Firebase is free and sufficient if you run Google only, but it has no fraud detection and does not feed Meta.

If you buy any CPI inventory, demand these in the insertion order: your MMP is the source of truth, not theirs; fraud protection named with blocked installs non-billable; post-attribution clawback of at least 30 days, wider than the MMP's own 7-day window; full sub-publisher and site-ID transparency with blocklist rights; no incentivized or rewarded inventory, warranted in writing; a retention floor as a payment condition; audit and termination for cause. None of these protect your store account — they protect your money.

Timing sharpens this. AppsFlyer's festive study — 20.5 million installs and $419 million of UA spend across October to December 2024 — describes the season as a nine-week sequence rather than a Diwali spike, and records iOS fraud reaching 60% after Diwali, a 176% jump. A festive launch therefore doubles your exposure at exactly the moment your budget peaks, which is an argument for having the MMP, the blocklist and the clawback clauses live weeks before the first rupee, not an argument against launching then.

Event taxonomy

Define these once, before either SDK goes in:

first_monetized_action is the one people forget to instrument, and the only event here that correlates with revenue.

How long does each gate actually take?

Nobody publishes an SLA for most of them, which is precisely why they belong on a dated plan rather than in a checklist. The table below gives weeks-before-launch as planning estimates, not documented turnaround times — the two documented items are marked. Build the plan backwards from your launch date and treat every estimate as a floor.

Two notes on the Play production-access gate, because it is the one that quietly kills launch dates. It applies to personal Play Console accounts created after 13 November 2023; organization accounts are exempt. Testers who opt in for fewer than 14 days and then opt out do not count, and if a tester opts out and returns, the clock restarts. Older guides saying 20 testers are outdated — it is 12.

Nothing on that list can be compressed with money. The only lever is starting earlier, which is why this section exists before the channel plans rather than after them.

Lead with UPI, then stack the monetized adjacencies straight into the title. That is what the leaders do, and it is not an accident — the ASO literally mirrors the monetization model. Both Paytm and PhonePe also use "Secure," because trust is the competitive axis here.

Live listings:

One flagged inconsistency: PhonePe's App Store title rendered as PhonePe: Secure Payments App on the chart page and PhonePe: UPI, Gold, Insurance on the product page — most likely an active title test. Verify live before benchmarking against it.

India head terms from leader metadata: upi, upi payment, upi app, payment app, money transfer, recharge, bill payment, scan and pay, send money, wallet, digital gold, instant loan, bhim upi, qr code payment.

Business of Apps puts finance page-view-to-install at 32.8% on iOS and 19.7% on Play. India's volume is overwhelmingly Android, so 19.7% is the number to work on, and it is the weaker of the two.

Play's financial services policy and data safety

Every developer must complete the financial features declaration, including those with no financial features. Payments sits under Payments & Transfers — mobile payments, digital wallets, money transfer, wire services — and your app category must be Finance.

Then the constraint that shapes onboarding: contacts, photos, location, phone numbers and external storage are prohibited data access for financial apps. That is stricter than general Play policy, and it kills contact-list scraping for P2P recipient discovery — the most common growth shortcut in this category. Design the send flow around UPI IDs, QR and typed phone numbers, not around a permission you cannot have.

Your Data Safety declaration must match what the app collects and your privacy policy must reconcile with it. DPDP Act 2023 obligations apply in full. Get the penalty figure right, because it is widely misquoted: ₹250 crore (about $28 million) is the ceiling for failure to take reasonable security safeguards specifically, while the general maximum is ₹200 crore (about $23 million) per instance for other breaches of the Act. If you attach lending, India personal loans require the app to appear on the RBI's list of digital lending apps deployed by regulated entities, with prominent disclosure of every partner NBFC and bank — Google has enforced hard here, actioning 3,500-plus loan apps in a prior India sweep.

Permissions: what you can and cannot ask for

Play's default rule is that only the default SMS, Phone or Assistant handler may use SMS and call-log permissions. The exception that saves UPI apps is explicit: "SMS-based financial transactions (e.g. UPI, payment verification)" is a permitted use case for READ_SMS, RECEIVE_MMS, RECEIVE_SMS, RECEIVE_WAP_PUSH and SEND_SMS. Device binding is legitimate — but declare it through the Permissions Declaration Form in Play Console. Apps without one face removal.

Two dated constraints to build around now rather than retrofit: account verification via READ_CALL_LOG is prohibited from 27 January 2027, with Google's July 2026 update already removing phone-call-based account verification as an approved use case; and Google steers you to the Digital Credentials API or SMS Retriever API instead. Build on SMS Retriever from day one — retrofitting after a policy rejection costs a release cycle you will not have.

Small, and worth running mostly for the one thing it gives you that no other channel does: a published India price. India iOS is roughly 4–6% of devices, and these plans put 15% of media into Apple Ads — a deliberate over-index on the basis that finance store conversion is 32.8% on iOS against 19.7% on Play, and that AppsFlyer's APAC data has India and Indonesia supplying 58% of APAC iOS finance revenue. Treat 15% as a ceiling to defend at week four, not a floor.

Apple's documented four-campaign structure is set out in full in the broking post; the config is identical here, so this is the reference rather than a walkthrough:

Add every Brand, Category and Competitor keyword into Discovery as exact-match negatives. Budget splits like 30/35/30/5 are convention, not Apple guidance. Placement drives everything: AppTweak's tap-through runs 7.4% on search results against 0.29% on the search tab, so search results is where a small budget goes.

The payments-specific decisions, which is what this section is actually for:

• Custom Product Pages, built per monetized adjacency rather than per payment feature. Up to 70 per app, Marketing role in App Store Connect, search-results ad groups only, editable without shipping a new version. A bill-payment page against "electricity bill payment" and "mobile recharge"; a gold page against "digital gold"; a credit page against lending terms if you are DLA-listed. This is the one place you can advertise the revenue rather than the payment.
• Maximize Conversions probably does not fit at these budgets. It wants a budget supporting at least five conversions a day and two weeks before judgement, and its mandatory Search Match conflicts with the exact-match discipline the four-campaign structure depends on. At the Lean budget below, the Apple line produces about 4.2 first transactions a day before fraud adjustment and under 3 after — under Apple's floor either way. Run the manual structure until the Apple line clears five a day.

Why the ₹163 planning CPI belongs on the Apple line only

The ₹163 figure is derived from Apple Search Ads data, and it is being used in this post as a cross-channel planning CPI. It should not be. The derivation runs: AppTweak's 2025 panel of roughly 3,500 apps, 50,000 campaigns and $1 billion in spend puts India CPI at $0.89 against a $1.80 global median, and applying the US Finance-to-median ratio ($8.44 ÷ $4.06 ≈ 2.08) gives roughly $1.85, or about ₹163. Every input in that chain is Apple Ads, iOS, and mostly American.

The budget below is 55% Google App Campaigns and 30% Meta, running on Android broadcast inventory in the world's largest Android market. Those are not the same auction. So:

• Use the $0.89-derived range on the Apple Ads line, and even there as a range rather than a point — AppTweak's own cross-panel spread on the best-measured metric in the set is instructive: US cost per tap is $1.91 on AppTweak's panel and $1.58 on Adapty's, a 20% gap on a metric both measure directly.
• Hold Google and Meta India Android CPI as unknown until week two. Nobody publishes it. The install projections in the budget table below are computed at ₹163 across all three channels purely so the table has a shape; they are a placeholder, not a forecast, and they are the first thing you replace.
• Size week one to produce the number. One Google App Campaign for Installs on target CPI at a deliberately generous ₹120 bid, which sets the documented floor at 50 × bid = ₹6,000 a day, so ₹42,000 over seven days. One Meta ad set on App Installs at ₹5,000 a day, ₹35,000 over seven days. Apple Ads at ₹3,000 a day, ₹21,000. That is roughly ₹1 lakh to buy the input every other number in this post depends on — cheap against a ₹10 lakh month spent on a guess. Re-run every table at the end of it.

One APAC note: AppsFlyer's State of Finance APAC 2026, covering 5.31 billion finance installs and $5.7 billion in UA spend, found finance installs fell for the first time even as iOS hit a record 16% APAC share, with India and Indonesia together at 66% of Android and 58% of iOS finance revenue in APAC.

Android is not a secondary platform in Indian payments — it is the whole market, and it is also the only place your measurement is deterministic. So the Google plan is the plan, and the only real question is how deep an event it can carry at your budget.

Three documented numbers decide that, and practitioners get all three wrong:

Read those as one system rather than three rules. The 50× floor sets the minimum daily spend an install campaign can run at for a given bid. The 10× floor does the same for an in-app-action campaign, which is why choosing a deeper event is a budget decision before it is a targeting decision. And the 100-conversion threshold is a count, not a clock: a campaign that needs five weeks to accumulate 100 conversions has been learning for five weeks, and every edit made in that window restarted it. Google separately advises against selecting more than one action for target CPA, and suggests iOS bids around 1.5 times Android.

Android is also where your measurement works. Android Privacy Sandbox was cancelled in October 2025 — GAID persists and deterministic user-level attribution continues, while iOS runs on aggregate, delayed, crowd-anonymity-gated AdAttributionKit and SKAdNetwork. Prove your monetized-action rate on Android, then use it to value iOS conversions you cannot see directly.

Two configuration failures cost about a fortnight each and neither surfaces an error. Deep linking needs robots.txt to permit AdsBot-Google and AdsBot-Google-Mobile through to apple-app-site-association and assetlinks.json — the single most common silent misconfiguration in App Campaigns. And on Android, deferred deep links have to be switched on in the measurement SDK, or every post-install route lands the user on your home screen instead of the bill-payment flow the ad promised.

For legitimate launch-day velocity, use Play pre-registration: 90 days maximum per country, a day-one push to everyone registered, and automatic install for eligible devices — apps up to 200 MB on Wi-Fi and cellular, 200 MB to 2 GB Wi-Fi only, above 2 GB not eligible. You get exactly one reward for the campaign's lifetime and it cannot be edited once created. Google publishes no statement that pre-registration confers a ranking benefit; the install-concentration mechanism is real, the ranking claim is inference.

On buying burst installs

The tactic as practised: 24–72 hour windows, $35,000–50,000 budgets in vendor case studies, claimed movement of 5–20 positions, gains fading within two weeks. The independent evidence is weaker than the pitch — the ACM IMC 2020 study of real incentivized campaigns — 500 installs each through three platforms, 2,126 offers from 922 apps over three months — reported all three tiers: top-chart appearance of 3.1% at baseline, 7.5% through vetted incentive platforms and 2.5% through unvetted ones.

The 7.5% is the one result that partially supports bursts, so state it and then read it honestly. The vetted tier is not what a CPI network sells you. The same study observed install-only offers priced at $0.06 and found continued engagement one day after install running at one to four users out of roughly 500 per platform. The inventory available to a launching app at a $0.06 clearing price is the unvetted tier, which produced no detectable ranking benefit at all — and MIT's 2025 shutoff experiments across six apps and 500 days put the organic halo from paid spend at about 8%, roughly an order of magnitude below what vendors pitch.

Two policy facts that make this a company risk, not a campaign risk. Apple's February 2026 Guidelines revision added clause 5.6.3 "Discovery Fraud" under the Developer Code of Conduct, where the stated remedy is termination of the Developer Program account rather than app rejection: "Manipulating any element of the App Store customer experience, such as charts, search, reviews or referrals to your app, erodes customer trust and is not permitted." The Section 3 preamble reaches the agency you hired as well — "or engage with third-party services to do so on your behalf" — so outsourcing the tactic does not outsource the finding. On the other store, Google states it filters incentivized installs out of ranking, escalating to top-chart removal and then store removal, which means the burst can be silently zeroed while you keep paying for it; and the account consequence does not stop at one app, because "any related Google Play developer accounts will also be permanently suspended." And finance carries roughly 31% fraud, against 11.7% on iOS and 14–15% on Android overall — the highest vertical figure in the dataset as reported — so a bought install here is worth less than a bought install anywhere else in the series.

The legitimate version produces the same curve: pre-registration cohort, email waitlist, PR embargo, creator posts and paid campaigns all landing on the same day.

Meta is your highest-volume channel for payments and your most constrained one the moment you advertise a financial product beyond the payment itself. Verification gates the account, not the ad — clear it before you plan spend.

Scope, precisely: Meta's SEBI verification mandate covers securities and investment ads targeting Indian users. A pure UPI app is outside it. Advertise a mutual fund, a broking cross-sell or any investment product and you are inside it, needing SEBI registration of the entity that both benefits from and pays for the ad, plus a public disclaimer naming the beneficiary and registration number, retained in the Ad Library for up to seven years. Since wealth cross-sell is exactly where payments apps go for LTV, most serious launches end up in scope within a year. Get verified before you need it.

Which optimization goal, and which two to rule out now. App Installs is Meta's own recommended default and where you start. App Event Optimization is the next rung once App Events flow reliably — note that it is charged on impressions rather than on events, so a thin event stream costs you money before it costs you learning. Rule out the other two early: Meta explicitly discourages Link Click Optimization once the SDK is installed, and Value Optimization is documented as available "on a limited basis to partners and advertisers", which makes it unplannable — and it wants purchase-value data that a zero-MDR payments app barely generates anyway.

The learning-phase number, and why it is softer than it looks. Roughly 50 optimization events per ad set per rolling seven days is what everyone plans against. Treat it as trade-press consensus rather than documented fact: Meta's Business Help Center is robots.txt-blocked, so nobody can cite Meta directly, and the figure is consistent across sources partly because those sources cite each other. What matters operationally is that budget, creative, audience and optimization-event changes each restart the clock — and that in this category the fraud discount below removes about a third of your real event volume, so an ad-set plan sized on gross events will sit in learning indefinitely. Fewer, larger ad sets is the structural fix; raising budget purely to shed the "learning limited" label typically buys 5–10%.

iOS and the eight-event model. Up to eight conversion events per verified domain, ranked by priority, only the highest-priority event in a session reported, and a 72-hour cooldown after any reorder. The standalone Aggregated Event Measurement tab was removed for many web accounts in 2026, but the eight-event model still governs iOS app campaigns. For payments, rank them first_monetized_action, first_p2m, first_transaction, upi_pin_set, bank_linked, and set it once.

Conversions API for App Events belongs in the launch build: action_source = "app", advertiser_tracking_enabled carrying ATT state, extinfo, and event_id for deduplication. Install events get automatic 90-day deduplication; post-install events do not.

You optimize to first_transaction for the first quarter and to first_monetized_action only once budget supports the volume — and the volume required is about four times higher, before you account for the fact that roughly a third of the installs you pay for are not people.

The only published anchor is Business of Apps' finance activation figure of roughly 14% by day 30 — your first-transaction rate off installs. Everything below is a planning model you replace with measured data by week three; no credible India cost-per-first-UPI-transaction or cost-per-linked-account benchmark exists, and the historical ones were distorted by cashback.

Working model from 10,000 gross installs — the installs you pay for, not the installs you get. This post makes 31% category fraud its headline statistic, so the model has to carry it rather than mention it:

So roughly 2.4% of the installs you pay for reach the event that earns you anything — 3.5% of the ones that were real people. The difference between those two numbers is the difference between a plan that clears its platform thresholds and one that does not.

Against the documented platform gates, stated in gross installs because that is what a budget buys:

Every figure there is roughly 45% higher than the version that circulates, because the circulating version applies gross rates to gross installs and quietly assumes every install you bought was a person.

Priced at the placeholder ₹163 CPI — which, as set out above, is an Apple Ads figure standing in for numbers you have not measured yet — clearing Meta's threshold on first_monetized_action needs roughly ₹14.6 lakh a month (about $16,600) per ad set, on one channel. On first_transaction it needs about ₹3.7 lakh (about $4,200). That four-fold gap is why most payments launches spend their first quarter optimizing to activation, and why the fraud discount is not an accounting detail: it moves the boundary between the two.

The iOS measurement question, and for once the answer is favourable. The constraint is the same across this series — AdAttributionKit reports in three windows from first launch (days 0–2, 3–7, 8–35), fine conversion values arrive only in the first postback and only at crowd-anonymity Tier 2 or 3, and at Tier 0 windows two and three send nothing at all. What differs by category is whether your money event falls inside window one. In payments it can. A user can link a bank, set a PIN and send ₹10 to a friend in a single sitting, so first_transaction is a day-zero event for a meaningful share of installs — encode it in the fine conversion value and you will genuinely receive it, which is not true of a broking first trade. The monetized action usually will not land there, so measure the transaction-to-monetized-action ratio on Android and use that ratio to value iOS conversions you cannot see.

Sequencing: launch on install or target CPI, clear 100 conversions on Google or roughly 50 a week on Meta, move down one rung, re-clear, repeat. Never skip a rung.

Sell the cross-sell, not the payment. Creative that drives generic UPI installs buys the least valuable user in the category. Lead on the monetized action, using UPI as the entry mechanic.

The cashback playbook everyone remembers is a consequence of the business model, not a creative insight: when the hero action earns nothing, you buy the first transaction outright. It works, and it produces a cohort with no demonstrated intent to do anything profitable. If you use it, make it a bridge to the monetized action — cashback on the first bill payment, not on the first P2P send. And budget it as acquisition cost, not as a promotion: at ₹100–200 a head it is 8–17% on top of media, and it appears as its own line in every scenario below for that reason.

Trust and security are the visible competitive axis. Both Paytm and PhonePe put "Secure" in their store metadata, and India's UPI fraud discourse makes safety messaging a real differentiator rather than a hygiene claim — defensible territory, and under-served by challengers.

What you cannot do:

• No contact-list hooks. Play prohibits contacts access for financial apps, so "find your friends" is a policy violation you have advertised in advance.
• No "instant loan approved" claims without RBI DLA listing and prominent partner disclosure — the most commonly enforced line in Indian fintech advertising.
• No investment or return claims in wealth cross-sell creative without Meta SEBI verification and the beneficiary disclaimer, and no guaranteed or assured-return language at all.
• No dark patterns. The CCPA's Dark Patterns Guidelines 2023 catch false urgency, fake scarcity, forced action and subscription traps hiding cancellation — all four appear routinely in payments onboarding.
• No absolute claims. ASCI prohibits "100%" constructions, and CCPA misleading-advertisement penalties run to ₹10 lakh (about $11,400) first offence and ₹50 lakh (about $57,000) for repeats, with endorser liability.

No published creative-intelligence study for Indian payments apps exists — better to say that than invent one. General mobile UA guidance carries over: short-form video, write to the first three seconds, 50–80 variants a month, UGC-style production over polish.

Three scenarios, all India, all monthly. Media is priced at the placeholder ₹163 CPI, so the install rows are a shape rather than a forecast — replace them the moment week one's price-discovery test returns a measured Google and Meta Android CPI. Incentive, creative and fraud-reserve lines sit on top of media, because all three are real cash and all three are usually missing from payments launch plans.

Cashback is CAC, so it belongs in the table rather than in the creative section. A ₹100–200 first-transaction incentive adds 8–17% on top of media, and at ₹150 it moves blended cost per first transaction from about ₹1,700 to about ₹1,850. The number that matters to whoever approves the budget is the blended one. The referral pool is separate and smaller, and should be capped rather than open-ended — an uncapped referral scheme in a zero-MDR category is an unbounded liability against a revenue line worth ₹112 a user a year.

Why Lean is capped at bank_linked. Two of the three channels miss their own floors. Meta's ₹3 lakh buys roughly 1,840 gross installs, 1,270 net, about 178 first transactions a month — 41 a week in a single ad set, against the ~50 threshold, so a Lean plan cannot optimize a Meta ad set to first_transaction even before splitting it. And Apple Ads at ₹1.5 lakh produces about 4.2 first transactions a day gross and 2.9 net, against Apple's documented floor of five a day for Maximize Conversions — so run Apple manually at Lean and do not switch on automated bidding.

Why Standard is capped at first_transaction, when the gross arithmetic says otherwise. This is the conservatism worth making explicit rather than asserting. On gross installs, Standard clears: cost per monetized action is ₹163 ÷ 3.5% = ₹4,657, the 10× target-CPA floor is ₹46,570 a day, and Standard's Google line is ₹16 lakh ÷ 30.4 = ₹52,631 a day. It also produces about 344 monetized actions a month, clearing Google's 100-conversion threshold in nine days.

Apply the fraud discount and it stops clearing. Cost per monetized action becomes ₹163 ÷ 2.4% = ₹6,736, the floor becomes ₹67,360 a day, and ₹52,631 does not reach it. Real monetized actions fall to about 164 a month, so the 100-conversion threshold takes 19 days rather than nine. Standard clears on the installs you paid for and misses on the ones that were real, which is exactly the failure mode a fraud-blind plan cannot see. Scale, at ₹48 lakh on Google, runs ₹157,895 a day against the same ₹67,360 floor and clears comfortably.

At Scale you cross 50,000 gross cumulative installs inside a month — the gate for App campaigns for Engagement — though on fraud-net installs it takes closer to six weeks, so plan the ACe start date off the net number. With 86% of activated-eligible installs never transacting, re-engaging PIN-setup abandoners is the largest efficiency lever in the plan.

The KPI ladder, in the order these numbers become trustworthy:

That last row is the discipline this category demands: if a KPI is denominated in transactions, it is not a revenue metric.