Fintech Deep Dive — Monday | October 05, 2026

Focus: Developer & Technical — payment rails, authentication, APIs and infrastructure.

Coverage period: September 28–October 5, 2026.

Executive summary

Four developments this week show Indian fintech technology moving in two directions at once. Bank of India says it has put recurring, user-configured programmable rupee payments live; Apple Pay has arrived, initially on a narrow Axis Bank card-and-device footprint; payment gateways are absorbing that wallet into merchant checkouts; and an RBI deadline for cross-border online card authentication has now passed. One is a new capability in public digital money, two are the integration work around a private card wallet, and one is a compliance control that issuers must implement across the international card channel.

The developer lesson is not “one new payment button.” It is that payment systems are stacks: issuer permission, scheme tokens, gateway routing, merchant checkout, authentication, settlement and reconciliation must all agree. UPI remains a separate account-to-account rail. Apple Pay does not replace it, while a programmable e₹ wallet is not simply another card token. The public announcements disclose little about measured adoption, failure rates or production volumes, so this edition separates stated capability from demonstrated scale.

1. Bank of India puts scheduled, purpose-bound e₹ on the user side

On September 28, Bank of India and its technology provider Montran India announced that the bank had gone live with user-level programmability and “Auto Issuance” on its central bank digital currency platform. The announcement describes a customer scheduling a fixed amount to a beneficiary’s digital rupee wallet at a chosen frequency, with restrictions on the permitted purpose or use of the funds. A parent sending a monthly allowance for education expenses is the example offered. The announcement, carried by Analytics Insight, quotes Bank of India’s general manager and CTO and Montran India’s CEO.

The technical distinction is important. A conventional standing instruction automates when money moves; a programmable payment also attempts to preserve a rule about what the recipient can do with it. This makes the wallet’s policy logic part of the instrument’s lifecycle, rather than leaving all purpose restrictions to the sender’s message or the recipient’s accounting. It could fit bounded recurring transfers—allowances, school-related spending or other earmarked payments—where the sender wants less manual repetition without giving up every control.

But “user-level programmable” is a feature description, not evidence that consumers or merchants can already use it everywhere. The announcement does not publish enrollment numbers, supported merchant categories, a public integration guide, the conditions users can select, or what happens when a legitimate purchase is misclassified. It also does not explain whether a recipient can appeal, whether the sender can revoke the instruction immediately, how a refund returns through a restricted wallet, or what happens when the scheduled issue fails. Those are product and systems questions, not edge cases: the appeal and reversal paths determine whether programmability is a useful safeguard or an opaque spending restriction.

This is also a distinct proposition from ordinary bank-account automation. The claim is that e₹ is issued to a beneficiary’s CBDC wallet and carries purpose conditions; it is not simply an IMPS or UPI transfer with a recurring date. Developers will need to treat the wallet and policy layer as new participants, and test the end-to-end path from instruction setup through issuance, acceptance, redemption and exception handling. The public evidence this week supports a bank-and-vendor deployment announcement. It does not yet support claims of broad availability or demonstrated impact on household spending.

2. Apple Pay launches in India—but on a deliberately narrow card footprint

Apple Pay began rolling out in India on September 29 and was live from September 30. Business Standard’s launch report and TechCrunch’s earlier report describe the initial support: eligible Axis Bank Visa and Mastercard credit cards, on Apple devices, for contactless and online or in-app payments. Apple’s participating-bank listing now names Axis Bank for Visa and Mastercard credit cards in India. At launch, this is not UPI, RuPay, or universal support for Indian card issuers.

That boundary tells us what the integration is—and is not. Apple Pay is a wallet and tokenized-card experience riding the existing card networks. Adding a card to the wallet requires issuer-side eligibility and provisioning; accepting it requires the relevant merchant/acquirer or payment provider to support the transaction path. At a shop, the device presents a contactless credential to a compatible terminal. Online, a wallet sheet can send a payment token rather than asking the customer to type a card number and wait for an SMS OTP. Apple’s security documentation says full card numbers are not shared with merchants and describes encrypted payment credentials; the Indian launch reporting describes device authentication by Face ID, Touch ID or passcode.

The comparison with UPI should be made at the right layer. UPI moves money between accounts through its own interoperable bank-and-app framework. Apple Pay packages eligible cards into a device-based checkout flow. Both may appear as a button or tap at the point of purchase, but their funding source, routing, issuer relationships and economics differ. Apple’s arrival therefore adds a new interface and acceptance option; it does not establish that India’s card market has displaced QR-first account payments. Nor does “available in India” mean that every iPhone owner can add any card: the issuer and card-network list is the practical gate.

For developers, the hard work is likely to sit less in designing another payment screen than in operational consistency: card provisioning failures, device eligibility, token lifecycle, payment authorization status, idempotent retries, refunds and chargebacks must remain intelligible across the merchant’s existing payment stack. A cleaner checkout can reduce steps, but a biometric prompt is not proof that a transaction cannot be disputed or that the underlying card is immune to fraud. Metrics that matter are authorization success, checkout abandonment, refund completion, fraud loss and support contacts—not the mere presence of the Apple Pay button.

3. Gateways are doing the integration work; the “one more option” still has edges

The rollout was accompanied by separate merchant-side announcements. Razorpay’s September 30 post says Apple Pay is being added to its checkout for domestic Indian payments, and that standard-checkout merchants need no additional integration work, with automatic enablement planned for eligible businesses. PayU’s announcement via ETBFSI says its merchant network can accept Apple Pay online, in-app and in-store. CCAvenue’s announcement via ETBFSI makes a similar network-level claim, including contactless acceptance through compatible terminals.

This is a meaningful infrastructure signal because merchant acceptance can scale through existing aggregators rather than requiring every shop to negotiate a separate technical relationship. In a hosted or standard checkout, the gateway can expose a payment option, obtain the wallet response, route authorization and return a result through the merchant’s familiar flow. That lowers integration friction for merchants already using the provider. Razorpay’s description of a desktop QR handoff also shows that the wallet can bridge a computer checkout to an iPhone, rather than assume every purchase starts and ends on one device.

However, “no integration required” is a statement about a particular provider’s standard checkout, not a universal property of Apple Pay. Razorpay itself directs some businesses to register interest, and product availability can depend on device, card, merchant account, checkout version, channel and acquirer configuration. The announcements do not publish a common API contract, SDK release, certification matrix or merchant-level rollout schedule. Developers should verify exactly which payment methods appear in production and staging, what webhooks and status values are returned, how repeated callbacks are deduplicated, and whether refunds and partial captures behave like card payments already supported by their gateway.

There is a consumer-protection trade-off here. Delegating integration to the gateway can make adoption easier, but it also concentrates observability. A merchant should still be able to tell whether a failure came from device eligibility, wallet authorization, the card issuer, network routing or the gateway. If the customer sees only “payment failed,” the system has hidden the point where a remedy belongs. The same lesson applies to privacy: tokenization reduces exposure of the card number to the merchant, but does not erase merchant-side order, device, location or behavioral data generated during checkout.

4. October 1 RBI deadline turns cross-border card authentication into a live control

A less visible infrastructure change reached its compliance date on October 1. The RBI’s Authentication Mechanisms for Digital Payment Transactions Directions, 2025, issued September 25, 2025, required card issuers by October 1, 2026 to put in place a way to validate non-recurring cross-border card-not-present transactions when an overseas merchant or acquirer requests authentication, register their Bank Identification Numbers (BINs) with card networks, and establish a risk-based mechanism for handling all cross-border card-not-present transactions.

This is a systems deadline, not a newly announced payment product. It sits alongside the directions’ broader domestic requirements: at least two distinct authentication factors for digital payments unless exempted, with at least one dynamic factor for transactions other than card-present payments. The RBI explicitly allows issuers to choose authentication factors and recognises biometrics among possible factors; SMS OTP remains a valid factor. For cross-border transactions, the directions say the domestic authentication provisions do not apply, while separately setting the issuer validation and risk-control requirements above. The distinction matters: “biometrics are permitted” does not mean RBI has ordered every payment to replace OTP, and Apple Pay’s device authentication should not be misdescribed as a blanket exemption from issuer controls.

For engineering teams, the deadline means more than toggling an international switch. Issuers and card networks must map BINs correctly; risk systems must distinguish recurring from non-recurring transactions and handle authentication requests from overseas merchants or acquirers; and decline, challenge and retry behavior must be visible to gateways and merchants. Poorly coordinated controls can create false declines on legitimate international purchases, while weak validation can leave the issuer exposed. The consumer-facing test is simple: a compliant system should protect an overseas online payment without turning every genuine purchase into an unexplained failure.

What the week adds up to

The week’s technical story is integration and control, not a single new rail. Bank of India’s e₹ announcement puts programmability at the wallet level but leaves key consumer safeguards and operating data undisclosed. Apple Pay offers a polished card-funded experience, but only through participating issuers, networks and acceptance providers. The gateway announcements show how a new option can be distributed through existing merchant plumbing; the RBI deadline shows how much issuer-side coordination remains invisible to the customer.

No funding round or valuation was disclosed in these developments. The measurable questions to watch are whether BOI publishes eligibility, usage and dispute data; whether more Indian issuers join Apple Pay; whether the gateways expose transparent merchant documentation and status reporting; and whether cross-border card authentication after October 1 produces fewer unsafe approvals without a spike in false declines. Until those data appear, launch counts are not adoption, and “frictionless” is a product claim to measure—not a result to assume.

Sources