Apple Pay went live in India on 30 September 2026, with Axis Bank as the first and currently only issuing partner. The consumer story has been covered everywhere. The parts worth a developer’s time are different: the regulatory change that finally made this possible after twelve years, and the small but easy-to-botch piece of integration work it drops on your plate.

What actually launched

  • Cards: eligible Axis Bank Visa and Mastercard credit cards only. No RuPay. No debit cards announced at launch.
  • Where it works: contactless terminals in-store, in-app, and on the web.
  • Payment service providers live at launch: BillDesk, Cashfree, Juspay, Mswipe, Paytm, PayU, Pine Labs, Razorpay (Worldline also reported).
  • Merchants named by Apple: Apple Store locations, Blinkit, Chaayos, Comet, Croma, Interflora, Ixigo, Le15 Patisserie, Reliance brands, Tata 1mg, Zomato.
  • Devices: iPhone, Apple Watch and iPad at launch. Mac support is listed as “coming soon” — check Apple’s page for exact model and OS requirements.

Notably absent: HDFC Bank, ICICI Bank and SBI Card, reportedly still negotiating commercial terms. Apple is said to be seeking around 20 basis points per transaction, which is the actual reason your bank isn’t on the list.

There is no UPI integration. Apple Pay here rides card rails, not the UPI stack. That single fact determines almost everything about how much it matters to you.

Why it took twelve years

Apple Pay launched in 2014 and reached most major markets years ago. India was blocked on a specific regulatory mismatch, and it’s a genuinely interesting one.

The RBI has long required an Additional Factor of Authentication (AFA) on card transactions. In practice — though the rules never actually said this — the industry implemented AFA as SMS OTP, with a narrow carve-out for contactless taps under ₹5,000. Apple Pay’s entire design is built on replacing that interaction: you authenticate to the device with Face ID or Touch ID, and the device produces a cryptogram. Bolting an SMS OTP onto the end defeats the product.

That changed with the RBI (Authentication Mechanisms for Digital Payment Transactions) Directions, 2025, issued 25 September 2025 and in force from 1 April 2026. The new regime is principle-based rather than prescriptive: a transaction needs two factors drawn from different categories — something you know, something you have, something you are — and at least one factor must be dynamic and unique per transaction. The explicit motivation was to move the ecosystem beyond SMS OTP, which is vulnerable to SIM swap, phishing and plain bad connectivity.

Apple Pay’s model maps onto that cleanly:

RBI factor categoryApple Pay mechanism
Something you haveThe Device Account Number provisioned into the Secure Element — bound to that specific device
Something you areFace ID / Touch ID (or device passcode as “something you know”)
Dynamic per transactionA one-time cryptogram generated per tap, not a reusable credential

Apple Pay went live roughly six months after those Directions took effect. To be fair: neither Apple nor the RBI has publicly framed the launch as a consequence of the new rules, and commercial negotiations with banks clearly mattered too. But a model that was previously inexpressible under the de facto OTP regime is now squarely expressible under the written one, and the sequencing is hard to ignore.

The takeaway that generalises beyond Apple: if your product’s authentication story died on “but RBI requires OTP”, that assumption is now out of date. Re-read the 2025 Directions.

What the transaction looks like from your side

Apple Pay uses EMV payment tokenisation. The card network acts as Token Service Provider and issues a Device Account Number — a separate PAN-shaped number mathematically decoupled from the real card — which lives in the Secure Element. The real card number is never stored on the device, never on Apple’s servers, and never reaches you.

Practical consequences:

  • You never receive a PAN, so card-on-file tokenisation (CoFT) logic doesn’t apply to these transactions. The token is device-bound, not merchant-bound.
  • You can’t do your usual “last 4 digits” matching against a customer’s stored card — the DAN’s last 4 differ from the physical card’s.
  • Recurring/subscription flows behave differently from a stored card. If you run mandates, test this specifically rather than assuming parity.

Accepting it: the one thing you actually have to do

You almost certainly will not implement the Apple Pay JS API yourself. Your PSP does that. With Razorpay Standard Checkout, for example, there are no code changes — Apple Pay appears dynamically for eligible customers once two things are done: you accept the terms in the dashboard, and you verify your domain.

Domain verification is where people lose an afternoon. Apple requires a file served at an exact path, with exact characteristics:

1

https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association

The requirements are strict and the failure mode is a silent non-appearing button:

  • Must return HTTP 200 directly — no 301, 302 or any 3xx redirect
  • Served over HTTPS with TLS 1.2+
  • Content-Type: text/plain
  • Publicly reachable — no auth, no password protection, no proxy or firewall interception

The file has no extension, so most servers will serve it as application/octet-stream and the verification fails with no useful error. Force the type explicitly.

nginx:

1
2
3
4

location = /.well-known/apple-developer-merchantid-domain-association {
    root /var/www/yoursite;
    default_type text/plain;
}

Apache:

1
2
3

<Files "apple-developer-merchantid-domain-association">
    ForceType text/plain
</Files>

Then verify it from outside your network before you touch the dashboard. This one-liner checks all three failure modes at once:

1
2
3

curl -sS -o /dev/null \
  -w 'status=%{http_code} type=%{content_type} redirects=%{num_redirects}\n' \
  https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association

You want exactly status=200 type=text/plain redirects=0. Anything else — a redirect from the apex to www, an HTML error page returning 200, a CDN rule stripping dotfile paths — and verification fails.

Two more traps worth knowing up front:

  • Apple Pay does not work in test mode on Razorpay. You validate in production, with a real card, for a real amount. Plan a small live transaction and refund it.
  • If you’re on Shopify or a mobile SDK, you skip the file entirely. Overlay/iframe integrations (WooCommerce, Magento) need it.

Detecting availability in the browser

If you want to reorder your payment options rather than just let the PSP render a button, feature-detect properly:

1
2
3
4
5
6
7

function applePayAvailable() {
  return Boolean(
    window.ApplePaySession &&
    ApplePaySession.supportsVersion(3) &&
    ApplePaySession.canMakePayments()
  );
}

The gotcha: canMakePayments() tells you the device is capable, not that the user has a card provisioned. For that you need canMakePaymentsWithActiveCard(merchantIdentifier), which returns a Promise and requires your merchant identifier. Using the synchronous check to promote Apple Pay to the top of your checkout will show it to people who can’t complete it.

Also tag the transactions so you can actually measure whether this was worth it. On Razorpay, Apple Pay payments carry:

1

"notes": { "provider": "apple_pay" }

Should you prioritise this?

Honestly: for most Indian consumer products, no — not above anything else on your roadmap.

UPI handles the overwhelming majority of Indian digital payment volume, it’s free for consumers, and it works on every ₹8,000 Android phone. Apple Pay at launch reaches a slice of a slice: iPhone owners who bank with Axis and hold an eligible Visa or Mastercard credit card. That is a small population.

But it’s a small population with an unusually high average order value, and the integration cost is close to zero — a dashboard toggle and a correctly-served static file. If you sell anything premium, travel, electronics or D2C with an iOS-skewed audience, spend the afternoon. Just don’t restructure your checkout around it, and don’t let it displace UPI as your default.

The real question is what happens next: whether HDFC, ICICI and SBI Card come on board, whether RuPay and debit cards get added, and whether NPCI and Apple ever find a way to put UPI inside Wallet. That last one would change the calculation entirely. Until then, this is a well-built premium rail on top of card infrastructure in a country that mostly stopped paying with cards.

Sources: Apple Newsroom India · TechCrunch · Entrackr · RBI contactless AFA notification · Razorpay Apple Pay docs