لمشروعي ، كنت بحاجة إلى إدراك القدرة على التحويل من بطاقة إلى أخرى. للاتصال الرسمي بواجهة أي بنك ، من الضروري إبرام اتفاق والوفاء بعدد من الشروط. لذلك ، تقرر إنشاء بوابة إلى الصفحة العامة للبنك. لهذه الأغراض ، تم اختيار بنكين تينكوف وبنك بن يوفران الفرصة للتحويل إلى بطاقاتهم "بدون". يمكنك العثور على المزيد حول التعريفات والقيود المفروضة على التحويلات على الصفحات ذات الصلة للبنوك. توضح هذه المقالة باختصار تشغيل بوابة تقوم بتنفيذ وظيفة قبول المدفوعات على البطاقة.
يجب تنفيذ عملية نقل من أي بطاقة إلى بطاقة محددة مسبقًا ، مع دعم إجراء ترخيص 3DSecure. 3DSecure هو بروتوكول ترخيص مستخدم آمن لعمليات CNP (بدون وجود بطاقة). يمكنك قراءة المزيد على المواقع المتخصصة ، ويوضح الرسم البياني أدناه مخططًا مبسطًا لكيفية عمل هذا من وجهة نظر المستخدم.
تُظهر الصورة آلية مبسطة لترخيص معاملة ، ما يحدث "تحت الغطاء" عند إجراء عملية دفع أو تحويل من بطاقة إلى أخرى ، وأدخل رمز SMS لتأكيده.
دعنا نفكر خطوة بخطوة:
- أدخل تفاصيل البطاقة والمبلغ ، وأرسله إلى موقع البنك.
- يستخدم البنك خدمة متخصصة (Merchant Plug-In MPI) ، والتي تنشئ طلب PaReq خاصًا ، وهو XML مع توقيع رقمي ، يحتوي على معلمات المعاملة ، وكذلك البيانات التي يجب إرسال هذا الطلب (Access Control Server ACS) ، ومكان إرسالها استجابة إذن (PaRes).
- يعيد البنك إلى المستخدم صفحة تحتوي على معلومات من MPI ويعيد توجيه المتصفح تلقائيًا إلى صفحة ACS للبنك الذي أصدر بطاقة المستخدم. يتم عرض صفحة للمستخدم لإدخال رمز SMS وإرسال رسالة نصية قصيرة إلى رقم الهاتف المسجل في البنك المصدر.
- بعد إدخال رمز SMS ، ينشئ خادم ACS صفحة ذات استجابة تفويض (PaRes) ، حيث يعيد توجيه المستخدم إلى صفحة MPI لإكمال العملية أو يرفض تنفيذها.
للحصول على فهم أعمق للعملية ، اقرأ مستندات Visa أو Mastercard ذات الصلة ، وهذا المستوى يكفي لحل هذه المشكلة.
لضمان التشغيل السلس للبوابة بحيث لا تتوقف آذان الموقع من خلال الترجمة ، يجب دمجها في عملية إعادة توجيه المستعرض بين MPI و ACS. للقيام بذلك ، استبدل العنوان (TermUrl) الذي تم استلامه من MPI. هذا هو العنوان الذي ستتم إعادة توجيه PaRes إليه بعد أن يكمل المستخدم التفويض ، حيث يتم إدخال عنوان البوابة في الطلب عند TermUrl. سيسمح ذلك للبوابة باستلام استجابة (RaRes) لإرسالها إلى خادم MPI وبعد معالجة استجابة MPI ، قم بتوجيه المستخدم إلى صفحة الإتمام الناجح أو غير الناجح للمعاملة.
تعمل البوابة بين متصفح المستخدم والصفحة المصرفية ، وتنفذ وظائف الإدخال / الإخراج التي تحاكي صفحة البنك ، وتكمِّل وتعديل البيانات ، وتعالج الاستجابات والأخطاء من الخدمات المصرفية.
تم توضيح بروتوكول التفاعل مع كل من البنوك يدويًا عن طريق التفاعل الهندسي الخلفي بين المتصفح وموقع البنك ، بشكل عام ، والمنطق هو نفسه ، والفرق في المتغيرات وطرق التحويل. بشكل عام ، هذا اختناق ، وتعتمد وظائف البرنامج على ثبات واجهة برمجة التطبيقات ، بمجرد أن يغير البنك تشغيل الخدمة ، سيتعين أيضًا تغيير منطق البوابة.
دعنا نفكر بمزيد من التفصيل في منطق العمل.
لضمان العمليات في البوابة ، يتم تنفيذ صفحة دفع ، ويتم إجراء المكالمة على العنوان:
http://< >/pay/page?payid=123456&sum=100&text=Test
يحتوي عنوان URL على المتغيرات التالية:
payid - معرِّف المعاملة المطلوب لتحديد نتائج طلب الدفع بعد إتمام المعاملة ؛
المبلغ - مبلغ المعاملة ؛
النص - حقل المعلومات "الغرض من الدفع".
بعد ملء بيانات البطاقة ، والموافقة على شروط التنفيذ ، يتم تقديم طلب عمولة للعملية. يعتمد حجم العمولة والبنك (أحدهما Tinkoff و BIN) الذي سيتم من خلاله النقل على البطاقة المحددة في إعدادات البوابة كمستقبل النقل ومدى توفر الخدمة المصرفية. يتم تطبيق آلية بسيطة للتوجيه ومعالجة الأخطاء في البوابة: يتم تحديد Tinkoff دائمًا ، إذا كانت صفحة البنك غير متوفرة ، ثم يتم تحديد صفحة BIN Bank.
بعد النقر على زر التحويل ، تتم إعادة توجيه النظام إلى صفحة البنك المصدر الذي أصدر البطاقة (ACS) ، والتي سيتم تنفيذ عملية الخصم منها. ستطلب البوابة معلمات PaReq من MPI ، واستبدل TermUrl وأرسل البيانات إلى المستخدم ، بعد تذكر معلمات المعاملة في ذاكرة التخزين المؤقت (Redis).
بعد اكتمال التفويض ، ستنتقل PaRes إلى البوابة ، وبناءً على بيانات ذاكرة التخزين المؤقت ، ستقوم بإعادة توجيهها إلى MPI المقابلة ، ومعالجة الاستجابة ، وإعادة توجيه المستخدم إلى إحدى الصفحات (ERROR_PAGE ، SUCCESS_PAGE) المحددة في إعدادات البوابة.
يحتوي عنوان URL للصفحة لإكمال العملية بنجاح على متغير payid ، الذي ينقل نتائج العملية في شكل JWT مع التوقيع الرقمي.
مثال JWT: eyJhbGciOiJIUzUxMiJ9.eyJqdGkiOiI2Njk2NzFlYi1mYmZlLTVlMTMtYTdkZi05NDEwZjg1N2U5ODkiLCJpYXQiOjE1NzE5MDg5MjgsInN1YiI6ImZpeGVkIiwiaXNzIjoicnUucGhvbmU0cGF5IiwicGF5X2lkIjoiMTIzNDUiLCJzdW0iOiIxMDAuMCIsInRyYW5zYWN0aW9uX2lkIjoiODY4MTE5ODYzIn0.c-IK3FowoR_tVe3-cpT7-rmA4EQhYy8rZkWrWASHZlc0ZzzpQont5XriCSzuDaY7jf7iIC8ZAxknAMwmTNmAHg
من خلال التحقق من محتويات JWT ، يمكنك الحصول على معلومات موثوقة حول نجاح العملية ، ويقوم الرمز المميز JWT بوظيفة مشابهة ل PaReq ويوفر القدرة على الاندماج مع نظام خارجي.
هذا الحل هو نموذج أولي لبوابة الدفع ، التي يمكنك من خلالها تنفيذ الحصول على الإنترنت (قبول المدفوعات عن طريق البطاقة) على موقع الويب الخاص بك أو صفحة الشبكة الاجتماعية. يمكنك تحديد صفحة الدفع الخاصة بك أو الكتابة الخاصة بك ، وتعديل البرنامج بطريقة إبداعية ، والشيء الرئيسي هو نقل مقدار العملية ومعرفها إلى المدخلات والتحقق من المخرجات من أنه لم يتم تغيير أي شيء بطريقة إبداعية من قبل شخص آخر. المصادر وأمثلة العمل متوفرة على
جيثب .
هناك أيضًا بوابة لتجديد محفظة VK.pay الخاصة بك ، والتي يمكن استخدامها أيضًا كبوابة للدفع. بشكل عام ، يتم تطبيق نفس المبادئ ، تم استخدام السيلينيوم لتنفيذ جزء من الوظيفة ، بمساعدة تنفيذ التصريح على الموقع والترخيص للوصول إلى المحفظة.
! هام أي معاملات على الإنترنت قد تكون خطرة ، فقد تُسرق بياناتك ، وتحتاج إلى اتخاذ الاحتياطات اللازمة عند إجراء معاملات الإنترنت.
! هام يتم توفير المسؤولية الجنائية عن سرقة الأموال من البطاقات المصرفية لشخص آخر
(المواد 159.3 ، 159.6 من القانون الجنائي للاتحاد الروسي) .