لما تبدأ العمل على فيتشر مثل Add to Google Wallet داخل تطبيق بنكي، هتسمع عدة مصطلحات تبدو وكأنها تصف الشيء نفسه:

• Google Wallet
• Google Pay
• Provisioning
• Tokenization
• Push Provisioning
• DPAN & FPAN

وهنا يبدأ الإلتباس…

• هل احنا بنضيف البطاقة إلى Google Pay أم Google Wallet ؟
• هل Tokenization تعني إضافة البطاقة ؟
• وما الذي يحدث فعليًا عندما يضغط اليوزر على زر Add to Google Wallet ؟

لفهم الموضوع بسهولة، دعنا نبدأ من المشكلة…

تخيل أن لديك تطبيقًا بنكيًا، واليوزر بيشوف ال card داخل التطبيق:
بطاقة Debit
تنتهي بـ 1234
وتريد إضافة زر: Add to Google Wallet
عندما يضغط اليوزر على الزر، يظهر الكارد بعد ذلك داخل تطبيق Google Wallet، ويستطيع استخدامها للدفع عن طريق تقريب الهاتف من جهاز الدفع.
من الخارج، قد يبدو أن التطبيق أرسل رقم الكارد إلى Google Wallet وانتهى الأمر.
لكن هذا ليس ما يحدث!
رقم الكارد الحقيقي لا يتم تخزينه واستخدامه مباشرة في عمليات الدفع من الهاتف. بدلًا من ذلك، تمر العملية بعدة مراحل، وأهم مرحلة فيها هي Tokenization.

أولًا: ما هو Google Wallet؟

هو التطبيق الذي يحتفظ فيه المستخدم بالعناصر الرقمية التي يمكن استخدامها لاحقًا.
مثل:

• Payment Cards
• Boarding Passes
• Event Tickets
• Loyalty Cards
• Transit Passes
• Digital Keys

بالنسبة للبطاقات البنكية، Google Wallet هو المكان الذي يرى فيه المستخدم بطاقته الرقمية ويديرها.
يمكن تشبيه Google Wallet بالمحفظة الموجودة في جيبك.
المحفظة نفسها لا تنفذ عملية الدفع، لكنها تحتفظ بالبطاقات التي تستخدمها عند الدفع.

ثانيًا: ما هو Google Pay؟

هو خدمة أو طريقة الدفع التي تستخدم البطاقة المحفوظة داخل Google Wallet.
عندما يقرب المستخدم هاتفه من جهاز الدفع، يتم تنفيذ عملية الدفع باستخدام Google Pay.

يمكن تبسيط العلاقة بهذا الشكل:

• المستخدم يضيف البطاقة إلى Google Wallet

        ↓

• يستخدم البطاقة في الدفع من خلال Google Pay

ثالثًا: ما هو Provisioning؟

كلمة Provisioning تعني عملية تجهيز البطاقة وإضافتها إلى Google Wallet لكي تصبح جاهزة للاستخدام في الدفع.
هي ليست خطوة واحدة فقط، بل عملية كاملة تتضمن عدة خطوات.

مثلًا:

اليوزر يختار البطاقة

      ↓

يطلب إضافتها إلى Google Wallet

      ↓

يتم إرسال بيانات البطاقة بشكل آمن

      ↓

يتم إنشاء Token

      ↓

قد يتم التحقق من المستخدم

      ↓

يتم تفعيل البطاقة داخل Wallet

إذًا يمكن تعريف Provisioning بأنه:
العملية الكاملة التي يتم من خلالها تحويل البطاقة البنكية إلى بطاقة رقمية جاهزة للاستخدام داخل Google Wallet.

أنواع Provisioning:

هناك أكثر من طريقة لبدء عملية Provisioning.

Manual Provisioning

في هذه الحالة يبدأ المستخدم من تطبيق Google Wallet.

Google Wallet

      ↓

Add payment card

      ↓

إدخال بيانات البطاقة

      ↓

التحقق من البنك

      ↓

إضافة البطاقة

Push Provisioning

في هذه الحالة تبدأ العملية من تطبيق البنك نفسه.

مثلًا:

تطبيق البنك

    ↓

صفحة البطاقة

    ↓

Add to Google Wallet

    ↓

Google Wallet

هذه التجربة تكون أسهل للمستخدم، لأن التطبيق البنكي يعرف بالفعل:

• المستخدم
• البطاقة التي اختارها
• بيانات حسابه
• حالة البطاقة

ولا يحتاج المستخدم إلى إدخال ال card number مرة أخرى.

هذا هو ال Push Provisioning وفي بعض الحالات قد يشار إليه باسم App Provisioning. أي أن عملية إضافة البطاقة بدأت من داخل تطبيق البنك.

رابعاً: ما هو Tokenization؟

أثناء عملية Provisioning، لا يتم استخدام ال card number الحقيقي داخل الهاتف في كل عملية دفع. بدلًا من ذلك، يتم إنشاء رقم بديل يسمى Token.

رقم البطاقة الحقيقي يسمى عادة FPAN وهي اختصار Funding Primary Account Number وهو رقم البطاقة المرتبط بحساب العميل.
الرقم البديل (Token) يسمي DPAN وهي اختصار Device Primary Account Number.
مثال:

FPAN الحقيقي
5123 4567 8901 2345

 ↓ Tokenization

DPAN أو Token
5234 9876 1111 5678

عند الدفع باستخدام الهاتف، يتم استخدام الـToken بدلًا من إرسال رقم البطاقة الحقيقي.

لماذا لا يتم استخدام رقم البطاقة الحقيقي ؟

تخيل أن رقم البطاقة الحقيقي تم تخزينه واستخدامه مباشرة على الهاتف. إذا تعرض الهاتف أو بيانات عملية الدفع للاختراق، فقد يتم كشف رقم البطاقة الأساسي الذي يستخدمه العميل في أماكن أخرى. لكن عند استخدام Token، يصبح لكل جهاز رقم مختلف يمثل البطاقة.

مثال:

البطاقة الحقيقية FPAN
        │
        ├── هاتف المستخدم → Token 1
        │
        ├── ساعة المستخدم → Token 2
        │
        └── هاتف آخر      → Token 3

كل هذه الـ Tokens مرتبطة بنفس البطاقة البنكية، لكنها ليست رقم البطاقة الحقيقي.

إذا فقد المستخدم هاتفه، يمكن للبنك أو مزود الخدمة إيقاف Token الخاص بهذا الهاتف فقط، دون الحاجة بالضرورة إلى إلغاء البطاقة الأساسية.

من المسؤول عن إنشاء Token ؟

إنشاء وإدارة الـ Token تتم عادة من خلال جهة تسمى Token Service Provider ويتم اختصارها إلى TSP.

في حالة بطاقات Mastercard، تكون الخدمة غالبًا MDES وهي اختصار Mastercard Digital Enablement Service.

أما في حالة Visa، توجد خدمة مشابهة تسمى VTS أي Visa Token Service.

هذه الخدمات تساعد في:

• إنشاء Token
• ربط Token بالبطاقة الحقيقية
• تفعيل Token
• إيقاف Token
• تعليق Token
• حذف Token
• إدارة دورة حياته

ما دور كل جهة في العملية؟

لنفترض أن لدينا بنكًا يستخدم Mastercard MDES مع Google Wallet، ستكون الأدوار بصورة مبسطة كالتالي:

تطبيق البنك:

• يعرض البطاقة التي يريد المستخدم إضافتها ويوفر زر Add to Google Wallet.

البنك أو Card Issuer يتأكد من أن:

• البطاقة صالحة
• العميل حقيقي
• البطاقة مسموح بإضافتها
• عملية Tokenization يمكن الموافقة عليها

Mastercard MDES:

• يعمل كـToken Service Provider، يقوم بإنشاء وإدارة الـToken المرتبط بالبطاقة.

Google Wallet:

• يعرض البطاقة الرقمية للمستخدم ويحتفظ بمعلوماتها على الجهاز بشكل آمن.

Google Pay:

• يستخدم البطاقة الرقمية والـToken لتنفيذ عمليات الدفع.

الصورة الكاملة

المستخدم يفتح تطبيق البنك
          ↓
يختار بطاقته
          ↓
يضغط Add to Google Wallet
          ↓
تبدأ عملية Push Provisioning
          ↓
يتم التواصل مع Google وTSP
          ↓
تحدث Tokenization
          ↓
يتم إنشاء DPAN أو Payment Token
          ↓
يتم تفعيل Token
          ↓
تظهر البطاقة في Google Wallet
          ↓
يستخدمها العميل للدفع عبر Google Pay

❀ تَمَّ بِحَمْدِ اللهِ ❀