लेखक: 
Research review: 17 October 2026. ऑनलाइन card payment में tokenisation का मतलब क्या है और RBI इसे क्यों लाया? Card number exposure, consent, merchant storage और customer safety को बैंकिंग के official framework के आधार पर समझें।
Card Tokenisation का मूल अर्थ
जब किसी shopping website पर card से payment किया जाता है तो पुरानी व्यवस्था में कुछ merchants future checkout की सुविधा के लिए card details store कर सकते थे। Card tokenisation में actual card number की जगह एक alternate identifier या token का उपयोग किया जाता है। RBI ने authorised card networks तथा issuers के लिए frameworks दिए हैं ताकि sensitive card credentials merchant systems में unnecessarily मौजूद न रहें। यह process केवल masking यानी card number के last four digits दिखाना नहीं है; payment flow की credential handling अलग हो सकती है।
RBI के Card-on-File नियम
RBI के circulars में card transaction ecosystem के लिए actual card details storage पर restrictions और tokenisation व्यवस्था की दिशा दी गई है। Rules का उद्देश्य merchants तथा payment-chain entities पर sensitive credential storage का footprint घटाना था। इस विषय में latest amendments भी देखना चाहिए, क्योंकि implementation, exceptions और responsibilities समय के साथ बदल सकती हैं। User को कोई shopping website यह कहे कि ‘हम आपके CVV हमेशा save करते हैं’ तो safety concern होना चाहिए।
Token किससे जुड़ा हो सकता है
Tokenisation framework में card, token requestor तथा device या merchant context महत्वपूर्ण हो सकता है, जैसा RBI के अलग guidance में बताया गया है। एक online retailer पर बना token हर दूसरे retailer पर usable universal card-number replacement होगा, यह मानना गलत है। Exact token domain और lifecycle service provider की architecture पर निर्भर करते हैं। Customer की सुविधा के लिए ‘saved card’ जैसा UI दिखाई दे, लेकिन backend में actual sensitive card number handle करने का तरीका अलग हो सकता है।
Online checkout का example
मान लें ग्राहक नियमित grocery website पर card इस्तेमाल करता है। यदि वह approved tokenisation consent देता है, तो authorised network तथा payment ecosystem ऐसा token उपलब्ध करा सकते हैं जिससे बाद के compatible checkout में full card details दोबारा type करने की जरूरत कम हो। लेकिन payment authorisation, additional authentication, issuer risk controls तथा merchant trust की आवश्यकता खत्म नहीं होती। किसी fake website पर पहली बार card number डालने से tokenisation उसे automatically safe नहीं बना देती।
Consent को समझना क्यों जरूरी
RBI की FAQs tokenisation request के लिए explicit customer consent पर जोर देती हैं। User को ‘saved card’ विकल्प और applicable limits पढ़ने चाहिए। Default tick वाले unknown consent पर भरोसा न करें। यदि checkout screen पर tokenisation unsupported है, तो उसे force करने के लिए unverified app extension install न करें। Customer यदि saved credentials नहीं रखना चाहता तो pay-as-you-go flow चुन सकता है, subject to provider facilities।
Tokenisation और OTP अलग controls हैं
Tokenisation card details के exposure को कम करने का mechanism है। OTP या AFA transaction authorisation या registration consent verify करने में उपयोग हो सकता है। दोनों एक दूसरे के substitutes नहीं हैं। Token हो जाने से हर payment guaranteed approved या fraud-proof नहीं हो जाता। Phishing, fake seller, social engineering और wrong amount जैसे risks transaction context पर depend करते हैं। Customer को amount, merchant और payment purpose पढ़ना चाहिए।
Merchant को actual card number क्यों कम चाहिए
Merchant के पास अधिक sensitive data store होने से breach exposure और compliance obligations बढ़ सकते हैं। Tokenisation actual card details को specialised authorised parties के controlled systems में सीमित करने का प्रयास है। इससे merchant की checkout functionality बनी रह सकती है जबकि card-data exposure घटे। लेकिन merchant को order history, delivery address और login security के लिए फिर भी appropriate safeguards चाहिए। Tokenisation पूर्ण website cybersecurity नहीं है।
Device-based और card-on-file context
RBI FAQs में device-based tokenisation तथा cards-on-file tokenisation से जुड़ी अलग terminology दिखाई देती है। Device token कुछ payment use cases जैसे contactless या app-based flows से जुड़ा हो सकता है। Card-on-file merchant checkout context से संबंधित हो सकता है। User किसी one-size-fits-all definition के आधार पर सभी wallets तथा ecommerce screens का operation नहीं समझे। Official bank और network help documentation में specific feature देखना बेहतर है।
Customer अपना token कैसे manage करे
कुछ issuers card token management, saved merchants या digital card controls देते हैं। Customer को registered merchants की सूची देखने और unwanted token या card linkage हटाने की सुविधा उपलब्ध हो सकती है, लेकिन app-by-app screens अलग होंगी। हर suspicious transaction के बाद सिर्फ app uninstall करना protection नहीं है। Bank से card block, dispute और token revocation procedures देखें। User अपने login credentials सुरक्षित रखे और customer-support number independently confirm करे।
क्या saved card का मतलब retailer के पास PAN है
जरूरी नहीं। Tokenisation adoption के बाद consumer interface में card brand, last digits और saved payment option दिखाई दे सकते हैं, जबकि full Primary Account Number merchant के पास stored न हो। एक data breach report पढ़ते समय देखें वास्तव में कौन-सा data leak हुआ—token, customer address, last four digits या full card credentials। इन terms को मिलाने से risk का गलत आकलन हो सकता है। फिर भी user को merchant account का strong password रखना चाहिए।
Subscription और auto debit का confusion
Recurring subscription authorisation card tokenisation से संबंधित हो सकती है, पर merchant recurring-payment mandates तथा customer consent के नियम अलग हैं। Token मौजूद होने से किसी company को unlimited arbitrary amount charge करने का automatic अधिकार नहीं मिलता। Renewal price, plan cancellation और merchant notification terms पढ़ें। Billing dispute में bank statement तथा subscription agreement उपयोगी होंगे। Token delete करने से membership contract स्वयं खत्म हो गया, ऐसा मानना हमेशा सही नहीं।
Chargeback और token के बीच अंतर
Tokenisation payment credential security का पहलू है; chargeback customer dispute settlement का अलग process है। यदि खराब product मिला या unauthorised debit हुआ, तो consumer को bank/card issuer की official complaint procedure अपनानी चाहिए। Token use होने पर भी dispute supporting evidence जरूरी हो सकता है। Card tokenisation को guaranteed refund mechanism बताना गलत है। Merchant और customer दोनों transaction records सुरक्षित रखें।
Card खोने पर क्या बदल सकता है
Physical card गुम हो जाए तो issuer को तुरंत report करके block या replace कराने की जरूरत है। Bank rules के अनुसार पुराने card token mapping तथा replacement card handling का व्यवहार अलग हो सकता है। Customer को supported payment apps और recurring services में token status verify करना पड़ सकता है। किसी SMS में ‘new token activation fee’ मांगने पर bank के official channel से पुष्टि करें।
Privacy और merchant trust
Tokenisation sensitive card details की exposure घटाने में मदद कर सकती है, लेकिन merchant account का contact number, address, purchase history और browsing behaviour अभी भी privacy concerns हैं। Shopping service चुनते समय data retention, account deletion और complaint handling policy देखें। Secure checkout के लिए website URL तथा authorised payment gateway verify करें। किसी browser popup से card number चुराने वाली phishing site पर tokenisation की security guarantee लागू मानना गलती होगी।
Small business merchant checklist
Payment gateway से लिखित समझें कि card credentials handling किस authorised actor की जिम्मेदारी है। Staff को card photos WhatsApp पर माँगने से रोकें। Merchant dashboard के access पर least privilege और MFA लगाएँ। Payment failures तथा refunds के लिए audit logs रखें। Customer service representatives को full PIN, CVV या OTP माँगने की अनुमति न दें। Gateway agreement में data security obligations और incident notification पढ़ें।
Consumer की दस-second checkout checklist
Website official है? Payment amount और merchant name सही हैं? Token save करने का consent optional समझ आया? OTP किस transaction के लिए आया है? Return/refund policy स्पष्ट है? यदि कोई भी point unclear हो, checkout रोककर independently verify करें। Public Wi-Fi पर sensitive payment करना हो तो system updates और trusted network controls का ध्यान रखें। किसी caller के pressure में transaction authorise न करें।
Hotel और ecommerce payment में अलग scenarios
Hotel booking में card guarantee, delayed charge और cancellation fee की terms अलग हो सकती हैं। Customer को merchant का contractual payment authority समझनी चाहिए, क्योंकि tokenisation स्वयं hotel की cancellation policy नहीं बदलती। Ecommerce site saved card option दिखाए तो customer पहले order amount, estimated tax, shipping तथा refund windows जाँचे। यदि merchant किसी unrelated subscription से payment जोड़ रहा है तो explicit consent और billing documentation मांगें। ऐसे cases में payment security और consumer rights दो अलग discussions हैं जिन्हें एक के नाम पर दूसरे से बचा नहीं जा सकता।
Card issuing bank की जिम्मेदारी
Card issuer limit settings, transaction alerts, dispute route और blocked-card support प्रदान कर सकता है। Customer अपने bank app में active cards और international or online payments के controls verify करे। किसी OTP message में transaction amount या merchant name अलग दिखे तो उसे approve न करें। RBI framework और issuer-specific procedures को साथ पढ़ना cardholder की सुरक्षा के लिए practical habit है।
किसी payment method में नया feature जोड़ने से पहले card-issuing bank और payment network के current terms देखना चाहिए। Tax, fees और merchant category के अनुसार final debit अलग हो सकता है; displayed consent को पूरा पढ़कर ही approval दें।
Official RBI references
Primary references: RBI Card-on-File Tokenisation circular और RBI payment-system FAQs। यह अक्टूबर 2026 की educational guide है; specific issuer implementation तथा latest RBI amendments पर original documents निर्णायक होंगे।
इस विषय पर आगे क्या पढ़ें?
इस खबर से जुड़े विषयों को आसान भाषा में और गहराई से समझें।
