Apple Pay के काम करने के तरीके को लेकर गलतफहमियां

 (birchtree.me)
1 पॉइंट द्वारा GN⁺ 2024-03-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • असली card number को छिपाने वाली संरचना सिर्फ Apple Pay की सुविधा नहीं है, बल्कि Google Pay, Samsung Pay जैसे प्रमुख digital wallets में भी इस्तेमाल होने वाला payment तरीका है
  • मुख्य बात physical card number यानी FPAN और device-specific payment number यानी DPAN का अलग होना है; एक ही card होने पर भी iPhone और iPad में अलग-अलग DPAN इस्तेमाल होते हैं
  • DPAN merchants के बीच tracking को मुश्किल बना सकता है, लेकिन उसी merchant के भीतर बाद की transactions में भी बना रहता है, इसलिए एक ही merchant की purchase history tracking को नहीं रोकता
  • payment information leak होने पर DPAN, FPAN से ज्यादा सुरक्षित होता है, और DPAN तभी काम करता है जब उसे हर transaction से जुड़े unique encrypted bundle के साथ submit किया जाए
  • Apple Pay नाम, email, billing/shipping address, खरीदे गए product जैसी personal information को अपने-आप नहीं छिपाता; payment screen पर दिखने वाली जानकारी merchant को भेजी जाती है, ऐसा मानना चाहिए

DPAN, Apple Pay की exclusive सुविधा नहीं है

  • जब कहा जाता है कि Apple Pay असली credit card number को छिपाता है, तो इसकी कुंजी DPAN है
  • FPAN physical card पर छपा 15–18 digit funding primary account number होता है, और DPAN device primary account number होता है
  • DPAN को DNS record जैसा समझा जा सकता है
    • user असली IP address जाने बिना भी domain name के जरिए website access करता है
    • एक ही card को भी अगर Apple Pay में iPhone और iPad पर इस्तेमाल किया जाए, तो हर device को unique number मिलता है और वे अलग-अलग DPAN इस्तेमाल करते हैं
  • यह महत्वपूर्ण है कि नाम से ही यह “Apple Pay number” नहीं है
    • Google Pay और Samsung Pay भी अमेरिका के प्रमुख digital wallets के तौर पर इसी तरीके से असली card number को छिपाते हैं
    • Amazon Pay और Shop Pay buttons में भी payment दूसरी कंपनियों के जरिए process होता है, इसलिए तकनीकी रूप से DPAN नहीं है, लेकिन वे merchant को असली FPAN देखने से रोकते हैं

merchants और banks भी असली card number exposure कम करना चाहते हैं

  • अगर merchant असली credit card number को सीधे process करता है, तो risk burden बढ़ जाता है
  • आधुनिक payment acceptance tools payment information को इस तरह collect करवाते हैं कि असली card information तक पहुंच रखने वाले लोगों की संख्या जितनी हो सके उतनी कम रहे
  • यह अनुमान कि banks DPAN का इस्तेमाल नहीं करेंगे, असली उदाहरणों से मेल नहीं खाता
    • Wells Fargo, Chase, Bank of America जैसे कई banks ने अपने digital wallets चलाए हैं या चला रहे हैं, और सभी सामान्य account number को DPAN से protect करते हैं
    • अमेरिका के बड़े banks द्वारा इस्तेमाल किया जाने वाला Paze भी DPAN इस्तेमाल करता है
    • Paze द्वारा बताए गए प्रमुख कारणों में से एक है: “Paze does not share your actual card number with the merchant.”

DPAN कौन-सी tracking रोकता है और कौन-सी नहीं

  • यह कहना कि DPAN हर transaction में बदलता है, सही नहीं है
  • उसी merchant के साथ आगे होने वाली transactions में वही DPAN इस्तेमाल होता है
  • यह संरचना उन data brokers के लिए बाधा बन सकती है जो कई merchants के transaction data खरीदकर किसी व्यक्ति की shopping tendencies समझना चाहते हैं
  • इसके उलट, एक single merchant Apple Pay द्वारा दिए गए DPAN से ही उस customer की transaction history देख सकता है
    • Target ने अपनी purchase history के आधार पर customer status infer किया था—ऐसी स्थिति को Apple Pay नहीं रोकता
    • दूसरे digital wallets की भी यही सीमा है

data breach के समय DPAN से मिलने वाली सुरक्षा

  • payment card information leak होने की स्थिति में DPAN, FPAN से ज्यादा सुरक्षित होता है
  • 2024 में merchants को credit card number सीधे handle नहीं करना चाहिए, लेकिन payment gateway hack होकर DPAN और expiry date leak होने की स्थिति पैदा हो सकती है
  • attacker leaked DPAN भर से payment execute नहीं कर सकता
    • DPAN तभी काम करता है जब उसे हर transaction के लिए unique encrypted bundle के हिस्से के रूप में submit किया जाए
    • Apple Pay से collect किए गए card पर recurring payments चलाने का तरीका है, लेकिन hacker ऐसा कर सके—ऐसा नहीं होना चाहिए
  • इसलिए सभी digital wallets द्वारा collect किए गए DPAN का leak होना जितना खतरनाक है, उससे कहीं ज्यादा खतरनाक FPAN leak है

Apple Pay personal information अपने-आप नहीं छिपाता

  • यह विचार कि Apple Pay personal information को अपने-आप mask कर देता है, सच नहीं है
  • test merchant account में वास्तविक Apple Pay transaction चलाने पर merchant-level report में नाम, email, billing address और home address जैसी जानकारी दिखती है
  • physical goods के payment के लिए shipping information की जरूरत होती है, इसलिए Apple Pay SDK merchant को यह चुनने देता है कि customer से कौन-सी personal information ली जाए
  • product information भी Apple Pay को भेजी जा सकती है ताकि buyer देख सके कि वह क्या खरीद रहा है, और यह जानकारी भी merchant को भेजी जाती है
  • payment के समय Apple Pay card पर दिखने वाली information merchant को भेजी जाती है, ऐसा मानना चाहिए
    • इस मामले में Apple Pay दूसरे payment methods जैसा ही है
    • merchant checkout में जरूरत या इच्छा के मुताबिक personal information चुनकर मांगता है
    • दूसरे digital wallets भी इसी तरीके से काम करते हैं

digital wallets असल में जो सुरक्षा देते हैं

  • Apple Pay एक अच्छा payment method है, और Apple ने इस तरह के digital wallets को popular बनाने में भूमिका निभाई है
  • हालांकि Apple Pay की capabilities industry में unique नहीं हैं
  • DPAN कई merchants में फैली किसी व्यक्ति की purchase tracking को मुश्किल बनाता है, और payment card information leak होने पर customer risk घटाने में उपयोगी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-29
Hacker News टिप्पणियां

  • मैं ELI5 अंदाज़ में जानना चाहता/चाहती हूं कि Apple Pay और Google Pay असल में कैसे काम करते हैं। पहले मुझे लगता था कि वे कार्ड की जानकारी सीधे merchant या payment processor को दे देते हैं, और मूल लेख भी कुछ ऐसा ही लगता है, लेकिन मैंने देखा है कि Google Pay में Amex इस्तेमाल करने पर कुछ merchants payment reject कर देते हैं, जबकि MasterCard के साथ ऐसा नहीं होता
    कभी-कभी ऐसा लगता है कि Apple/Google खुद payment processor या payment method की तरह काम करते हैं। क्योंकि वे transaction data इकट्ठा करते दिखते हैं, और supermarket terminals को भी Apple/Google Pay apps के लिए खास support चाहिए था, ऐसा लगता था
    तो Apple/Google का अपना proprietary secret sauce क्या है, और इसे किसी open source alternative से replace करना मुश्किल या असंभव क्यों है? क्या ऐसा इसलिए है कि iOS/Android पर NFC chip तक पूरी access सिर्फ Apple/Google के पास है?
    https://news.ycombinator.com/item?id=39845805

    • Apple/Google के पास कोई खास secret sauce नहीं है। दुनिया भर के कई banks अपने HCE wallets देते हैं, लेकिन वे सिर्फ Android पर चलते हैं। Apple ने जरूरी APIs नहीं दिए थे, और EU में अब यह बदलना शुरू हो रहा है
      अहम चीज default होना है। हर device पर default Visa, Mastercard wallet सिर्फ एक ही हो सकता है, और जिसे tap करने से पहले अलग से app खोलने की जरूरत न पड़े, उसे फायदा मिलता है। Google Pay कई bank cards support करता है, इसलिए किसी खास issuing bank के HCE wallet की तुलना में इसका बड़ा advantage है
      Apple/Google किसी नए card को किसी specific device में register करते समय mediation में शामिल होते हैं, लेकिन असली POS transaction flow में नहीं आते
      Merchant को फिर भी underlying card brand accept करना होता है। आज के Google Pay और Apple Pay card brand बदलने वाले proxy cards नहीं हैं, और Curve जैसी services से अलग हैं
      Offline terminals को अलग support की जरूरत नहीं होती। जब तक terminal में bug न हो, जहां underlying card scheme accept होती है, वहां यह काम करता है। Physical और logical protocols plastic card जैसे ही होते हैं और terminal के नजरिए से लगभग अलग पहचान में नहीं आते
      Web पर मामला अलग है। Shopping mall website और payment service provider को explicit support देना पड़ता है
    • Apple/Google Pay contactless EMV का इस्तेमाल करते हैं, जो contactless credit cards जैसा ही तरीका है। यह Visa/MC के Paywave, Paypass के पीछे वाला standard है
      इसलिए wireless terminals आम तौर पर Apple Pay और Google Pay को यूं ही accept कर लेते थे, ज्यादा special support की जरूरत नहीं थी। मुझे याद है कि एक बदलाव यह हुआ कि ऐसे devices को ज्यादा secure माना गया, इसलिए contactless cards की तुलना में payment limits बढ़ा दी गईं
      Open source implementation मुश्किल होने की वजह यह है कि EMV implementation complex है, और specialized equipment के जरिए काफी testing और certification की जरूरत होती है। Device में private keys को सुरक्षित रखने के लिए secure element चाहिए, और app को यह verify कर पाना चाहिए कि biometric authentication या PIN unlock इस्तेमाल हुआ है, ताकि user security की guarantee दी जा सके
      साथ ही setup process में card-issuing bank के backend से integrate करके जरूरी keys और जानकारी issue करानी होती है। Open source implementation को भी banks के साथ contracts करने और UL जैसी जगहों से lab certification कराने की संभावना काफी ज्यादा है
    • इकलौता “secret sauce” liability shift है। Traditional online और contactless payments को “cardholder not present” transactions माना जाता है, इसलिए fraud liability ज्यादा merchant पर जाती है
      Apple Pay और Google Pay, तथा banks द्वारा दिए गए payment apps, biometric authentication से cardholder approval confirm करके कुछ payments को “cardholder present” में बदल देते हैं
      इसलिए कुछ chargeback types तुरंत reject हो जाते हैं, और दूसरे types में भी merchant से मांगे जाने वाले evidence की जरूरत कम हो जाती है
      यह card network standards का हिस्सा है, और अगर रुचि हो तो https://www.emvco.com/ पर देख सकते हैं
      Open source option न होने की वजह यह है कि implementation की security certify करनी पड़ती है, इसलिए banks के साथ काम करने के लिए commercial entity चाहिए। ऊपर से हर bank के साथ अलग integration करनी पड़ती है, यानी deal करने के लिए बहुत ज्यादा banks हैं
    • Google Pay में Amex reject हो और MasterCard काम करे, तो आम तौर पर यह card terminal provider की configuration problem होती है, या card scheme से communicate करने वाले acquirer backend में mobile wallet feature certification की कमी की वजह से होता है
      सभी card schemes, सभी payment methods और सभी devices को cover करने वाले end-to-end transactions को सही तरह से चलाना काफी पेचीदा है। हर card scheme के “payment kernel” parameters और certification requirements अलग होते हैं
      या यह transaction fees बचाने की कोशिश भी हो सकती है। Amex आम तौर पर merchants के लिए काफी ज्यादा महंगा होता है
    • यहां अच्छी जानकारी है
      https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...

  • जब Apple Pay पहली बार व्यापक रूप से इस्तेमाल होना शुरू हुआ, तब मैंने retail payment processing के अपने अनुभव के आधार पर इसे काफी विस्तार से देखा था। उस समय सबसे प्रभावशाली बात यह थी कि यह industry standards में कितनी गहराई से जड़ा हुआ था
    wireless communication के बाद का कोई भी हिस्सा Apple-विशेष नहीं था, और इस लेख को पढ़कर लगता है कि आज तक यह बात बनी हुई है
    मुझे याद है कि उस समय card-based tap-to-pay को जानबूझकर स्वीकार करने वाले कुछ merchants को, जब उन्होंने अनजाने में बहुत ही standard Apple tap-to-pay स्वीकार कर लिया, तो अपने systems बदलने पड़े थे। खास तौर पर CVS याद आता है; वह किसी प्रतिस्पर्धी payment scheme में शामिल था और शायद चाहता था कि stores में उस scheme का चलना Apple Pay से उसका differentiator बने
    हाल में जब “यह तो सिर्फ Apple Pay करता है” वाली myth बनने लगी, तो मुझे हैरानी हुई कि क्या मैंने आखिरी बार देखने के बाद कुछ बदल गया है; इसलिए अच्छा लगा कि लेखक ने इसी context में ताज़ा review किया

    • एक निजी किस्से के तौर पर, जब Apple Pay पहली बार launch हुआ था, तब यह सिर्फ अमेरिका में काम करता था। ज़्यादा सटीक कहें तो इसे सिर्फ अमेरिका में set up किया जा सकता था। उसके तुरंत बाद मैं Australia चला गया, जहाँ tap-to-pay standard है
      official support न होने के बावजूद Australia में लगभग हर जगह Apple Pay काम करता था, यह देखकर काफी हैरानी हुई। अमेरिका में केवल बहुत कम merchants support करते थे, लेकिन Australia में यह standards-based था, इसलिए POS के 99% पहले से ही support करते थे
    • standards-based होने के बावजूद Apple का launch और marketing का तरीका काफी चतुर था, जिससे यह impression बना कि Apple Pay ही अकेला phone tap-to-pay है। merchants “Apple Pay accepted” के signs लगाते थे और Google का ज़िक्र नहीं करते थे, जिससे confusion होता था कि non-Apple payments चलेंगे या नहीं
      Android payments की उलझी हुई स्थिति ने भी इसमें भूमिका निभाई। Samsung Pay का मतलब NFC भी हो सकता था और magnetic stripe emulation भी। Google branding में खराब होने के लिए मशहूर है, और Wallet व Google Pay के कई iterations के बीच आज भी समझना मुश्किल है कि क्या क्या है
    • सबसे मज़ेदार बात यह है कि लोग भूल जाते हैं कि Apple Pay mobile payments market में देर से आने वालों में था। असल में वह लगभग आखिरी ही था

  • ऐसी चर्चाओं में छूटी हुई बात यह है कि Apple Pay, Google Pay, Samsung Pay जैसे wallets के transactions भी अब underlying card number वाले transactions जितने ही trackable हैं
    DPAN किसी खास device के लिए unique होता है, लेकिन आजकल merchants के payment service providers card network के authorization response से PAR नाम का unique identifier पा सकते हैं। यह identifier उसी card के सभी DPANs में समान होता है, और लक्ष्य यह है कि अगर base account वही रहे तो card number बदलने पर भी यह बना रहे
    PAR से merchant payment charge नहीं कर सकता, इसलिए यह security issue नहीं है, लेकिन digital wallet payments को सामान्य card या card-number payments से ज्यादा private मानने की उम्मीद नहीं करनी चाहिए
    https://wcapra.com/payment-account-reference-capraplus-your-...
    https://www.securetechalliance.org/wp-content/uploads/EMVCo-...

    • जब तक सरकार की ओर से कोई कार्रवाई नहीं होती, मुझे उम्मीद नहीं है कि आगे कुछ भी ज्यादा private होगा
    • Japan में ऐसा नहीं है। Apple Pay anonymous ICOCA/Suica card इस्तेमाल करता है, और चाहें तो उसे delete करके फिर से बनाया जा सकता है
    • Australia में मेरा local bank NAB उसी base account में card number बदलने पर भी इसे बनाए रखता है। यहाँ ज़्यादातर credit cards में यह काफी आम होगा

  • Matt Birchler के लेख में यह paragraph जोड़ा गया है: “पिछले version में मैंने कहा था कि DPAN हर merchant के लिए बदलता है, लेकिन वह गलती थी। बहुत जल्दबाज़ी में लिखना मेरी गलती थी।” लेकिन article का बाकी हिस्सा अब भी ऐसा दिखता है जैसे हर merchant के लिए अलग unique DPAN होता हो, और मुझे इसका आधार नहीं मिल रहा
    Apple का अपना document https://support.apple.com/en-us/HT203027 भी कहता है कि DPAN, जिसे यहाँ Device Account Number कहा गया है, सिर्फ device-level पर unique होता है। जब card Apple Pay में add किया जाता है, तो उस device का DPAN बनाया जाता है, और card को delete करके फिर से add न किया जाए तो बाद में नहीं बदलता
    इसलिए अगर उसी card को iPhone और Apple Watch दोनों devices पर इस्तेमाल करें तो DPAN अलग होंगे और tracking मुश्किल होगी, लेकिन उसी device पर उसी card को कई merchants के यहाँ इस्तेमाल करें तो data broker इसे track कर सकता है, ऐसा लगता है

    • payments industry में DPAN को आम तौर पर stable identifier नहीं माना जाता। card add/delete से स्वतंत्र रूप से इसे समय-समय पर rotate किया जा सकता है
    • अगर bank credit card data बेच रहा है, तो PAN अलग है इससे ज्यादा फर्क नहीं पड़ता
    • Apple Pay से payment करते समय मैंने देखा है कि card के आखिरी चार digits हर बार बदल जाते हैं। मैं मुख्यतः Apple Watch इस्तेमाल करता हूँ, और यह न सिर्फ merchant बदलने पर बल्कि उसी merchant पर भी अलग था

  • समझ नहीं आता कि SSO और mobile payments ऐसे standard interfaces क्यों नहीं हैं जिनके लिए कोई भी provider बना सके। “Login with Google” या “Login with Apple” की जगह “मेरे default SSO provider से login” होना चाहिए, है न? “मेरे default payment provider से pay” भी वैसा ही होना चाहिए
    इससे भी बुरा यह है कि अक्सर provider या sites इन providers में से सिर्फ कुछ को ही support करते हैं, जिससे SSO असल में SSO नहीं रह जाता
    वजहें होंगी, लेकिन मैंने गहराई से खोजा नहीं। लगता है सभी providers के पालन करने के लिए कोई common agreed specification होनी चाहिए, और अगर नहीं है तो कभी न कभी कानून से ऐसा करवाए जाने की संभावना ज्यादा है

    • SSO में आप जो ढूंढ रहे हैं, वह RFC 7591[0] के करीब है। यह OAuth IdP में तुरंत registration करने का तरीका बताता है। RFC 8414[1] registration process का metadata लाने के लिए well-known location बताता है
      standards पहले से हैं, और theoretical तौर पर login form में email डालने या browser के autocomplete करने पर उस domain के OAuth login तक जाना चाहिए, और अगर server पहली बार उस domain से communicate कर रहा हो तो तुरंत client registration भी कर सकता है। मैंने इसे असल में इस्तेमाल होते नहीं देखा, लेकिन ऐसा हो तो अच्छा होगा
      [0] https://datatracker.ietf.org/doc/html/rfc7591
      [1] https://datatracker.ietf.org/doc/html/rfc8414
    • वजह “growth and engagement” है। 2010 के आसपास से technology, users को empower करने वाले tool से बदलकर users का time spam से बर्बाद कराने वाला tool बन गई
      services देने और fair fees लेने से हटकर, users को spam भेजने या data collect करके बाद में और spam भेजने की तरफ shift हो गया
      open standards मौजूदा providers नहीं चाहते। क्योंकि ऐसा होने पर users आसानी से किसी दूसरे विकल्प पर switch कर लेंगे और फिर “engage” नहीं करेंगे
    • user verification के तरीके हर business में काफी अलग होते हैं, इसलिए हर business को review करके भरोसा करना पड़ता है कि SSO provider उनके मांगे हुए standards का पालन करता है या नहीं। अगर लाखों SSO providers हों, तो यह जानना मुश्किल होगा कि कौन किन standards का पालन करता है
    • “Login with Google” support करने के लिए Google side पर setup चाहिए। उन्हें बताना पड़ता है कि यह app क्या है, authentication के बाद किस URL पर redirect करना है, वगैरह। नहीं तो security issues हो जाते हैं
    • क्योंकि वह दर्दनाक है और fraud inflow का magnet है। जब Stack Overflow ने हर जगह OpenID इस्तेमाल करने के लिए encourage किया था, तब problems आई थीं

  • दिलचस्प है कि Apple Pay को Australia के local बड़े banks द्वारा contactless payments का use बढ़ाने के लिए कई साल तक push करने के बाद launch किया गया था। इसलिए जब Apple आई और US-style fees मांगने लगी, तब infrastructure banks खुद पहले ही बिछा चुके थे
    Australia के बड़े banks ने कई साल तक Apple Pay support करने से बचने की कोशिश की, लेकिन customer pressure इतना बढ़ गया कि आखिरकार उन्हें झुकना पड़ा
    आज भी वे सभी इस बात से बहुत नाराज हैं, और अगर regulator NFC chip खोलने को force करे तो वे तुरंत Apple Pay छोड़ देंगे। लेकिन अब तक देश के सबसे बड़े banks की शिकायतों से सहानुभूति रखने वाला कोई ढूंढना मुश्किल रहा है

    • मजेदार बात यह है कि Australian banks ने ACCC से Apple Pay की conditions को लेकर Apple के साथ jointly negotiate करने और boycott करने के लिए cartel बनाने की अनुमति मांगी थी, लेकिन उसे reject कर दिया गया
      https://www.accc.gov.au/media-release/accc-denies-authorisat...
    • जब तक users चुपचाप नहीं बैठते, banks के लिए Apple Pay छोड़ना मुश्किल होगा
      Canadian banks ने भी Android पर TD Pay जैसे अपने contactless payments try किए थे, लेकिन किसी को नहीं चाहिए थे। आखिरकार उन्होंने छोड़कर Google Pay दे दिया
      मुझे लगता है यह भी वैसा ही चलेगा। Apple NFC payments खोल भी दे, तो भी कोई bank app इस्तेमाल नहीं करेगा और Apple Pay या Google Pay जैसे first-party support को prefer करेगा
      बस यह देख लें कि Samsung Pay और Google Pay में से असल में कितने लोग Samsung Pay इस्तेमाल करते हैं
    • ऐसा भी नहीं है कि Apple ने US का contactless payment infrastructure बनाया। contactless interface पहले से था, उसका अपना logo भी था, और उसे tap cards के साथ इस्तेमाल किया जा सकता था
      CVS जैसे कुछ retailers ने Apple Pay introduce होने पर tap payments बंद कर दिए थे
    • https://www.apple.com/newsroom/2024/01/apple-announces-chang...
    • याद है कि Apple Pay से पहले NAB जैसे banks फोन के पीछे चिपकाने वाले NFC stickers इस अंदाज में देते थे कि “देखो, यह Apple Pay जितना ही अच्छा है”

  • “merchant checkout में जितनी personal information चाहिए मांग सकता है, और Apple Pay इसे रोकता नहीं” वाला हिस्सा offline shopping में भी होता है या नहीं, यह जानने की उत्सुकता है
    supermarket से अंडे खरीदने के लिए मेरे नाम और address की जरूरत नहीं है। Apple/Google पक्का मेरी consent मांगते हैं क्या, जब वे ऐसी जानकारी भी share करते हैं जिसकी जरूरत साफ तौर पर नहीं है? क्या यह terms या shrink-wrap EULA की तरह take-it-or-leave-it है?
    मैंने ऐसे payment systems कभी इस्तेमाल नहीं किए

    • POS payment में आम तौर पर merchant के साथ सिर्फ device account number, यानी DPAN, share होता है। नाम भी आम तौर पर छिपा होता है, और यह contactless card जैसा है, chip/magnetic payments से अलग
      article में बताई गई extra information सिर्फ “online” payments में share होती है। हालांकि इसमें फोन से QR code scan करके Safari या App Clip में payment करने वाले cases भी शामिल हैं, जो आजकल मैंने कुछ restaurants में देखा है
      ऐसा करने पर restaurant जितनी information मांगता है, उसे मिलती है। इसमें name, address, email address तक शामिल हो सकते हैं। आम तौर पर यह payment sheet में दिखता लगता है, लेकिन जब मैंने पहली बार restaurant में इस्तेमाल किया था तो ठीक से notice नहीं किया
      अब मैं waiter से कहता हूं कि actual terminal लाकर tap करने दें, या बस physical card दे देता हूं

  • थोड़ा विषय से हटकर है, लेकिन मैं अब भी नहीं समझ पाया कि Apple Pay transaction approve करने से पहले screen पर अभी pay की जाने वाली amount क्यों नहीं दिखा पाता
    यह user experience की समस्या नहीं लगती, बल्कि लगता है कि Apple device को वह amount पता ही नहीं होती। वजह क्या हो सकती है?

    • phone को बस plastic card की तरह सोचिए। phone NFC reader की request का इंतज़ार करता है, और request आने पर “card number” भेज देता है, बस
      यह समझने में मुझे थोड़ा समय लगा। मैं समझ नहीं पा रहा था कि airplane mode में Apple Pay कैसे काम करता है, लेकिन जाहिर है कि वह काम करता है। क्योंकि मौजूदा Visa card भी internet connection के बिना ठीक से चलते हैं
      मूल रूप से दोनों एक ही चीज़ हैं। अगर सब कुछ standard के मुताबिक काम करे, तो अलग से “support” करने को कुछ नहीं रहता—वजह भी यही है। jjcm की sibling comment देखें: https://news.ycombinator.com/item?id=39846117
      इसलिए मेरा मानना है कि NFC reader payment amount को “broadcast” नहीं करता। plastic card के पास उस जानकारी को process करने का कोई तरीका नहीं था, और iPhone के पास भी वह जानकारी लेकर “रुको, user swipe करके approve करे तब तक इंतज़ार करो” कहने का तरीका नहीं है

  • पता नहीं Gruber ने कहाँ कहा कि “यह सिर्फ Apple Pay करता है।” लेखक ने बस यह बताया है कि Gruber ने कुछ गलतियाँ कीं या details ठीक से नहीं पकड़ीं, और मामला इतना ही लगता है

    • https://daringfireball.net/linked/2024/03/21/garland-monopol...
      [Update: अरे, मैं गलत था। payment industry में काम करने वाले Matt Birchler ने इसका काम करने का तरीका अच्छी तरह समझाया है, और यह सामने आया है कि बड़े banks और credit card companies tap-to-pay transactions में merchant-specific “DPAN” numbers generate करती हैं। फिर भी मेरा दावा बना रहता है कि Apple Wallet कम से कम card issuer द्वारा दिए गए किसी भी digital payment app जितना ही सुरक्षित, या उससे अधिक सुरक्षित है.]
      यह original author Gruber की पोस्ट है
    • “banks या credit card issuers को NFC tap-to-pay access मिल जाने से वे खुद ऐसा करेंगे, इसकी संभावना बहुत कम है” वाले हिस्से पर Birchler ने बताया कि banks ने असल में ऐसा किया है
      Gruber ने भी अपनी गलती मानी
      Gruber खुले तौर पर Apple fan हैं, लेकिन आम तौर पर facts सही रखते थे, जो नहीं जानते थे उसे स्वीकार करते थे, और उस क्षेत्र के experts को link करते थे
      लेकिन EU DMA पर Apple के कदमों के बाद से लगता है कि उन्होंने objectivity पूरी तरह खो दी है। जैसे EC से भी बेहतर legal wording समझने का दिखावा करना, Europe की काफी अलग legislative approach पर अमेरिकी तरीका लागू करना, और Apple के bad-faith statements को ज्यों का त्यों स्वीकार कर लेना
      यह बदलाव Apple के EU के प्रति अजीब तरह के bad-faith रवैये के साथ मेल खाता है, इसलिए मूल समस्या शायद यह हो सकती है कि Gruber Apple पर बहुत ज़्यादा भरोसा करते हैं
      लगता है कि वे अमेरिकी सरकार के antitrust lawsuit पर भी वही रवैया जारी रख रहे हैं
      निष्पक्ष होकर देखें तो social media पर legal experts होने का दिखावा करने वाले Apple समर्थकों की भरमार है और वे लगभग हर चीज़ गलत बताते हैं, इसलिए शायद उनके लिए कोई legitimate opposing view देखना मुश्किल हो
    • “Apple Pay यह करता है” और “सिर्फ Apple Pay यह करता है” में बड़ा फर्क है। लगता है Gruber ने पहला कहा था, लेकिन लेखक ने किसी तरह उसे दूसरा समझ लिया

  • “Apple ने ऐसे digital wallet को लोकप्रिय बनाने में शानदार काम किया, लेकिन वे जो करते हैं वह industry में unique नहीं है” वाले हिस्से पर, मेरी याद गलत हो सकती है, पर मुझे लगता है कि जब Apple Pay पहली बार आया था, तब यह काफी unique था। इसलिए इसे support करने वाली जगहें बहुत कम थीं
    दूसरे phone payment systems, जैसे शुरुआती Samsung Pay, शायद terminal को card number सीधे भेजते थे

    • अमेरिका में यह दुर्लभ था। Europe और Asia में contactless payment कुछ समय से supported था, और UK में यह 2007 से संभव था। हालांकि UK में, कम से कम शुरुआत में, limit काफी कम थी
      दिलचस्प बात यह है कि UK में शायद अभी भी £100 limit है, जबकि अमेरिका में मैंने Android phone contactless payment से $2000 से अधिक की amount भी pay की है
    • उस समय भी एक-दो दूसरी approaches थीं, लेकिन वे शायद बढ़ा-चढ़ाकर कही गई autocomplete जैसी थीं। मुझे याद है कि Google Pay का कोई version websites में जानकारी भरता था, और background में किसी तरह actual card number pass करता था
      शायद वह सीधे सिर्फ bank को भेजता था ताकि merchant उसे न देख सके, लेकिन फिर भी वह real number था। DPAN इस्तेमाल करने की बात मैंने पहली बार Apple के बारे में सुनी थी
    • EMVCo की contactless specification हमेशा tokenized card number थी। Samsung Pay ने online payments में PAN pass किया हो सकता है
    • मेरे हिसाब से Apple Pay market में आई आखिरी major implementations में से एक था। EMV standard पर आधारित पहली implementation असल में Google Wallet थी, और Google की typical global launch failure की वजह से अटक गई
      अमेरिका कई वजहों से card payment technology में बहुत पीछे है। जब मैं Poland से दुनिया भर में कई सालों से इस्तेमाल किया गया card लेकर गया था, तो cashier को payment करवा सकने के लिए पहले एक special workaround सीखना पड़ा था