The refund that used to be simple

A shopper buys a pair of running shoes on a D2C store, picks guest checkout, pays, and leaves without making an account. Nine days later they want a refund. The store's ops team goes to process it and hits a wall: there is no saved card to refund against, because the shopper never agreed to save one, and the store is not allowed to keep the card number anyway.

That wall is new. Before India's card tokenisation rules, a merchant could hold the card details on file and quietly run refunds, captures, and chargeback responses against them. Guest checkout or not, the card was there. Today it is not, and that changes how post-purchase work gets done.

Alt ID (Alternate ID) is the card networks' answer to that gap. It lets a merchant keep processing refunds, captures, and chargebacks on a guest checkout order without ever storing the real card number. This piece explains what Alt ID is, why it exists, how the flow works, and what it means for staying compliant with the Reserve Bank of India (RBI).

What breaks at guest checkout after tokenisation

Guest checkout lets a customer pay without creating an account or saving their card. It is popular for a reason: it strips out the sign-up step, which is where a lot of first-time and one-off buyers drop off. Merchants lean on it to cut cart abandonment and lift checkout conversion.

The catch is what happens *after* the sale. Plenty of payment work continues once the order is placed:

• Refunds, in full or in part
• Payment captures on an earlier authorisation
• Chargeback and dispute handling
• Reconciliation and settlement

Traditionally all of that ran off stored card data, known in the industry as Card-on-File (CoF: a card the merchant keeps to charge again later). RBI's tokenisation regime removed that option. And for guest checkout specifically, the usual workaround does not apply: normal card tokenisation needs the customer's consent to save the card, and a guest by definition has not given it. So the merchant cannot mint a standard token, yet still needs a safe reference for the money work that follows. That is the exact gap Alt ID was built to close.

What RBI's card storage rules actually say

To cut card fraud and shrink the amount of sensitive data floating around, RBI restricted who may store actual card credentials. In plain terms:

• Only card issuers and card networks may store the real card details.
• Merchants, payment gateways, and payment aggregators must purge stored card data.
• A business may keep only limited, non-sensitive fragments, such as the last four digits and the issuer name, for reconciliation.

The intent is straightforward: if merchants do not hold card numbers, a breach at a merchant cannot leak them. For customers who *do* consent, network tokenisation (replacing the card number with a secure token issued by the network) fills the need. Guest checkout is the leftover case, and Alt ID is the mechanism that covers it.

A quick note on trust: PayGlocal is authorised by the RBI as a Payment Aggregator - Cross Border - Inward & Outward (PA-CB-I&O) and as an Online Payment Aggregator (PA-O), and is part of the ICICI Bank Group. Card-storage and tokenisation rules sit at the centre of how a regulated aggregator is built.

What is Alt ID?

Alt ID (Alternate ID) is a unique identifier that a card network generates for a guest checkout transaction, standing in for the real card so a merchant can run post-transaction activity without storing the Primary Account Number (PAN: the actual 16-digit card number).

Instead of holding the PAN, the merchant holds an Alt ID that points to that specific card for that context. Refunds, captures, settlements, and chargebacks all reference the Alt ID rather than stored card data. Because the Alt ID replaces the real number, the merchant stays inside RBI's card-storage rules while still offering a fast, no-friction guest checkout.

It helps to be precise about the boundary. Alt ID is not the same as saving a card. A saved-card token exists because the customer opted in; an Alt ID exists precisely because they did not, and it is scoped to keeping the payment lifecycle working, not to charging the shopper again on a whim.

How does Alt ID work?

At a high level, the merchant, the payment gateway, and the card network pass a reference between them so the real card number never has to sit in the merchant's systems. The flow runs like this:

1. The customer pays. They enter card details at guest checkout and complete the purchase as usual.
2. The merchant forwards the request. The card details go to the merchant's payment service provider or gateway, not into the merchant's own store.
3. The network issues an Alt ID. The gateway asks the relevant card network for an Alt ID. Rather than returning the real card data, the network returns a unique Alt ID plus the cryptographic material needed to authorise the payment securely.
4. The payment is processed. The gateway uses the Alt ID to complete the transaction without exposing or storing the card number.
5. Later actions reuse the Alt ID. For any refund, capture, settlement, or chargeback afterwards, the merchant references the Alt ID instead of a stored card.

The practical upshot: the merchant's environment stays out of scope for holding raw card data (which also keeps PCI-DSS obligations lighter), and the post-sale workflow carries on as if a card were on file, because a safe reference to it effectively is.

What do merchants get out of Alt ID?

The benefit is not abstract. It is the difference between a guest order you can service and one you cannot.

• Refunds and chargebacks keep working. The most common post-sale actions no longer depend on stored card data.
• Card numbers never sit with the merchant. Less sensitive data on hand means less to lose in a breach and a smaller compliance surface.
• Guest checkout stays frictionless. Customers still skip the account step, so the conversion advantage of guest checkout is intact.
• RBI compliance holds. The business meets the card-storage rules without dropping post-transaction capability.

There is a tradeoff worth naming: Alt ID is scoped to a transaction context and is not a general-purpose saved card, so it is not a substitute for a proper consented token when you genuinely want a returning customer's card on file. It solves the guest case, not every case. For eligible India-issued card transactions, that is exactly the case it is meant to solve.

Where Alt ID fits into RBI compliance

For any business taking domestic card payments online, compliance is not optional, and the card-storage rules are among the ones most likely to trip up a checkout flow. Alt ID lets a merchant meet them without forcing customers to create accounts or save cards just so the back office can function.

That is the quiet value. The merchant keeps offering guest checkout, keeps its conversion numbers, and keeps refunds and disputes running, all without holding a card number. For payment providers and merchants handling India-issued card transactions, Alt ID has become a standard part of a compliant setup rather than a nice-to-have.

How PayGlocal supports Alt ID

PayGlocal supports Alt ID provisioning and processing through direct integrations with the major card networks. Merchants on PayGlocal can use Alt ID for eligible India-issued card transactions, so guest checkout stays secure and RBI-compliant without card data living in the merchant's systems.

In practice that means:

• Alt ID provisioning handled at the gateway
• Refunds, captures, and chargebacks that reference the Alt ID, not a stored card
• RBI-compliant card handling as the default, not an add-on
• Integration that fits into an existing checkout rather than replacing it

As an RBI-authorised aggregator inside the ICICI Bank Group, PayGlocal treats card-storage compliance as part of the plumbing, so a merchant can keep a clean guest checkout and still service every order that follows.