{ "version": 1, "generatedAt": "2026-07-16T00:00:00.000Z", "documents": [ { "id": "future-payments", "locale": "ar", "title": "مستقبل الدفع ليس زرًا أسرع", "description": "زاوية تعليمية تشرح لماذا ينتقل التنافس من تنفيذ العملية إلى إدارة سياقها الكامل.", "url": "/ar/docs/academy/future-payments", "category": "academy", "text": "السرعة أصبحت شرطًا لا ميزة كافية عندما تستطيع منصات كثيرة نقل قيمة خلال ثوانٍ، لا يعود الفرق الحقيقي في عدد الثواني وحده. ينتقل التنافس إلى ما يحيط بالدفع: الهوية، الصلاحية، تجربة العميل، ارتباطه بالطلب، وضوح الرسوم، معالجة الاستثناء، والتسوية والمصالحة. من قناة إلى بنية القناة تجيب: كيف أدفع؟ أما البنية فتجيب أيضًا: لماذا سمح بالدفع؟ إلى أي نشاط وفرع ينتمي؟ كيف نحميه من التكرار؟ ماذا يحدث إن انقطع الاتصال؟ كيف يظهر في التقارير؟ ومن يراجع الاسترداد؟ ما الذي تحتاجه الأعمال مستقبلًا؟ هوية يمكن استخدامها عبر خدمات متعددة دون نسخ الحسابات. محفظة تتعامل مع العملات والحالات بوضوح. صلاحيات تتبع الشخص والدور والفرع. دفع يندمج في التشغيل بدل أن ينتج جزيرة بيانات جديدة. سجل مالي يسمح بالنمو والمراجعة في الوقت نفسه. تجربة تقلل الاحتكاك للمستخدم العادي وترفع التحقق عند الحساسية. القيمة التسويقية الحقيقية لا يشتري التاجر «مستقبلًا» كشعار، بل يشتري قدرة على فتح فرع جديد دون فقد السيطرة، وإضافة وسيلة دفع دون إعادة بناء التقارير، وخدمة عميل بسرعة دون التضحية بالأثر المالي. هذا هو الاتجاه الذي تجمعه LuxPay في منظومة واحدة وتترجمه إلى تشغيل يومي.", "lastReviewedAt": "2026-07-16" }, { "id": "operational-wallet", "locale": "ar", "title": "المحفظة كأداة تشغيل", "description": "كيف تتحول المحفظة من مخزن رصيد إلى نقطة وصل بين الفرد والعمل والرواتب والمدفوعات.", "url": "/ar/docs/academy/operational-wallet", "category": "academy", "text": "المحفظة القديمة تحفظ، والمحفظة التشغيلية تربط إذا كانت المحفظة تعرض رصيدًا وتحويلًا فقط، فهي أداة مالية منفصلة. أما المحفظة التشغيلية فتربط هوية الشخص بعضويته في العمل، واستلام راتبه، ودفعه، وسجل نشاطه، وحدوده، وتجربته عبر الخدمات. ثلاث قيم مترابطة للفرد وصول واضح إلى الرصيد والحالات، واستلام أموال ورواتب، ودفع دون إعادة تعريف الهوية في كل خدمة. للعمل صرف منضبط، وربط الموظفين والموردين، وفهم أثر الدفعات بدل إرسال ملفات ثم انتظار نتائج غامضة. للمنظومة هوية وسجل موحدان يسمحان بإضافة خدمات جديدة دون إنشاء حساب مالي معزول لكل ميزة. الحدود ضرورية الربط لا يعني خلط الملكيات. محفظة الشخص لا تصبح رصيد الشركة، وعضوية الموظف لا تمنحه رؤية في أموال زملائه. الوحدة المطلوبة في الهوية والتجربة، مع فصل صارم للملكية والصلاحية والعملة. لماذا هذا يبيع المستقبل؟ لأنه يقلل تكلفة كل خدمة جديدة. عندما تكون الهوية والمحفظة والسجل جاهزة، يصبح إطلاق راتب أو دفع تاجر أو خدمة فرع امتدادًا مضبوطًا، لا مشروعًا يبدأ من الصفر. تعرّف على المحافظ والأرصدة والعملات والرواتب والمدفوعات الجماعية.", "lastReviewedAt": "2026-07-16" }, { "id": "financial-discipline", "locale": "ar", "title": "الانضباط المالي دون احتكاك زائد", "description": "كيف تجمع تجربة الدفع الجيدة بين السهولة وقابلية التدقيق والضبط.", "url": "/ar/docs/academy/financial-discipline", "category": "academy", "text": "المفاضلة الزائفة يقال أحيانًا إن الأمان يعطل الاستخدام، أو إن التجربة السهلة تتطلب تخفيف الضوابط. لكن المشكلة غالبًا ليست في وجود الضبط، بل في وضعه في المكان الخطأ. مطالبة المستخدم بتحقق ثقيل لكل عملية صغيرة سيئة، وكذلك السماح باسترداد كبير اعتمادًا على جلسة قديمة. الضبط المتناسب تجمع التجربة الجيدة عدة إشارات: الجهاز، حداثة التحقق، الدور، الفرع، المبلغ، نمط السلوك، ونوع العملية. تمر الأفعال الروتينية بسلاسة عندما تكون الثقة كافية، وترتفع المتطلبات عند تغير السياق أو زيادة الحساسية. ما الذي يبقى خلف الواجهة؟ منع التكرار حتى لو ضغط المستخدم مرتين. استخراج هوية النشاط والفرع من سياق موثوق. تسجيل القرار دون تسجيل الأسرار. فصل تنفيذ العملية عن مراجعتها عند الحاجة. المحافظة على سجل الحالات بدل تعديل النتيجة بصمت. فشل مغلق عندما لا يمكن إثبات الصلاحية في عملية حساسة. النتيجة التجارية الانضباط ليس عبئًا تنظيميًا فقط؛ هو ما يسمح للنشاط بالتوسع. بفضله يمكن تفويض الفروع، وإطلاق استردادات، واستخدام مزودين، ودفع رواتب، مع بقاء الإدارة قادرة على تفسير حركة المال. اربط هذا المفهوم بـالأدوار والصلاحيات وأمان الحساب والتحقق.", "lastReviewedAt": "2026-07-16" }, { "id": "branches-operators", "locale": "ar", "title": "الفروع والمشغلون", "description": "تنظيم الفروع ونقاط التشغيل والمستخدمين بحيث تعكس التقارير الواقع الفعلي.", "url": "/ar/docs/business/branches-operators", "category": "business", "text": "الفرع سياق مالي، لا مجرد عنوان يحدد الفرع مكان العملية ومسؤوليتها وحدودها وتسويتها. لذلك ينبغي أن يحمل اسمًا ثابتًا، ورمزًا داخليًا واضحًا، ونطاق تشغيل، وحالة نشطة أو موقوفة. تغيير اسم الفرع لا يجب أن يمحو هويته التاريخية. إضافة المشغلين أضف المستخدم من خلال عضوية موثقة، ثم حدد دوره والفروع التي يعمل فيها. تجنب الحسابات المشتركة؛ فكل عملية يجب أن تنسب إلى شخص ودور وجهاز وسياق يمكن مراجعته. دورة حياة المشغل 1. دعوة العضو والتحقق من هويته. 2. تعيين الدور والنطاق. 3. اعتماد الجهاز أو نقطة التشغيل. 4. بدء العمل ضمن وردية أو جلسة عند الحاجة. 5. مراجعة النشاط دوريًا. 6. تعليق العضوية أو إزالة الوصول عند انتهاء العلاقة. نقل موظف بين الفروع لا تعدل تاريخ العمليات السابقة. أنهِ النطاق القديم في وقت محدد، ثم فعّل النطاق الجديد. بهذه الطريقة تظل تقارير الأمس مرتبطة بالفرع الذي حدثت فيه العمليات فعلًا. مؤشرات الضبط راجع المستخدمين غير النشطين، والأدوار الواسعة، والأجهزة القديمة، والعمليات خارج ساعات العمل المعتادة. ثم اربط ذلك بـالأدوار والصلاحيات والتشغيل والإغلاق اليومي.", "lastReviewedAt": "2026-07-16" }, { "id": "roles-permissions", "locale": "ar", "title": "الأدوار والصلاحيات", "description": "تصميم صلاحيات تقلل الخطأ وتفصل التنفيذ عن المراجعة والاعتماد.", "url": "/ar/docs/business/roles-permissions", "category": "business", "text": "ابدأ بالمهام لا بالأسماء لا يكفي إنشاء أدوار باسم مدير وموظف. اكتب الأفعال التي يحتاجها كل دور: استقبال دفعة، عرض تقرير، إنشاء استرداد، اعتماد استرداد، إدارة مستخدم، أو مراجعة تسوية. ثم امنح أقل مجموعة لازمة. فصل الواجبات في العمليات الحساسة، افصل بين: من ينشئ العملية ومن يعتمدها. من يسترد الأموال ومن يراجع الاستردادات. من يدير المستخدمين ومن يراجع السجل. من يجهز التسوية ومن يصادق عليها. هذا الفصل لا يعني تعطيل العمل؛ يمكن استخدام حدود مبلغية أو موافقة إضافية فقط عندما تتجاوز العملية نطاقًا معتادًا. النطاق والمدة الصلاحية يجب أن تحدد ما الفعل و أين يسري و إلى متى . صلاحية مدير فرع لا تمتد تلقائيًا إلى كل الفروع، والوصول المؤقت ينبغي أن ينتهي تلقائيًا. مراجعة دورية راجع الصلاحيات عند تغيير وظيفة الموظف، أو انتقاله، أو انتهاء عقده، وبعد أي حادث. لا تعتمد على الذاكرة؛ استخدم تقرير عضويات نشطة وأجهزة مرتبطة وأفعال حساسة. منح صلاحية واسعة أسرع لحظة الإعداد، لكنه يحول كل خطأ صغير إلى أثر مالي أكبر. اقرأ أيضًا الهوية بين الشخص والنشاط وأمان الحساب والتحقق.", "lastReviewedAt": "2026-07-16" }, { "id": "daily-operations", "locale": "ar", "title": "التشغيل والإغلاق اليومي", "description": "روتين عملي للكاشير ومدير الفرع من بدء الوردية حتى مراجعة اليوم.", "url": "/ar/docs/business/daily-operations", "category": "business", "text": "بداية اليوم تحقق من الجهاز والفرع والمستخدم النشط، ثم راجع حالة الاتصال والتنبيهات والحدود. لا تبدأ على جلسة مستخدم آخر، ولا تتجاهل رسالة تفيد أن الجهاز أو الفرع غير مصرح به. أثناء التشغيل أنشئ كل دفعة من الطلب الحقيقي ولا تعدل المبلغ بعد التأكيد خارج المسار المعتمد. راقب الحالات المعلقة قبل تكرار المحاولة. استخدم الاسترداد المرتبط بالعملية الأصلية بدل تحويل يدوي. لا تشارك الحساب عند تبدل الكاشير؛ أنهِ الجلسة وافتح جلسة جديدة. دوّن سبب أي استثناء تشغيلي ضمن الحقل المخصص، لا في رسائل شخصية. نهاية الوردية 1. أوقف إنشاء عمليات جديدة للحظة المراجعة. 2. راجع الناجح والفاشل والمعلق والملغى. 3. افحص الاستردادات والتعديلات ذات القيمة العالية. 4. قارن إجمالي نقطة البيع بتقرير LuxPay حسب العملة. 5. صنف الفروقات: توقيت، عملية معلقة، إدخال، أو حالة تحتاج تصعيدًا. 6. أغلق الجلسة وصدّر التقرير المصرح به. ما الذي لا ينبغي فعله؟ لا تجعل هدف الإغلاق إجبار الأرقام على التطابق بتعديل يدوي. الهدف هو تفسير الفرق وربطه بعملية أو حالة. استخدم المصالحة المالية للحالات التي تتجاوز الوردية.", "lastReviewedAt": "2026-07-16" }, { "id": "payment-lifecycle", "locale": "ar", "title": "دورة حياة عملية الدفع", "description": "من إنشاء نية الدفع إلى النتيجة النهائية والسجل والتسوية.", "url": "/ar/docs/payments/payment-lifecycle", "category": "payments", "text": "لماذا توجد دورة حياة؟ الدفع ليس طلبًا واحدًا ينجح أو يفشل فورًا دائمًا. قد يحتاج إنشاء، وتأكيد، ومعالجة لدى مزود، وتحققًا من النتيجة، ثم تسجيلًا ماليًا وتسوية. دورة الحياة تمنع واجهة المستخدم من تفسير غياب الرد بوصفه فشلًا مؤكدًا. المراحل الرئيسية 1. الإنشاء: تحديد المبلغ والعملة والتاجر والمرجع بطريقة لا تنفذ الأثر مرتين. 2. التأكيد: موافقة صاحب الصلاحية أو العميل على البيانات النهائية. 3. المعالجة: إرسال العملية عبر المسار المالي المعتمد. 4. النتيجة: نجاح أو فشل أو إلغاء أو انتظار تحقق إضافي. 5. التسجيل: حفظ الأثر والمرجع وسلسلة الحالات. 6. التسوية: ضم العملية المؤهلة إلى دورة تسوية. 7. المصالحة: مطابقة العملية والتسوية والتقرير. منع التكرار إذا انقطع الاتصال بعد التأكيد، لا يعني ذلك أن العملية لم تنفذ. تستخدم الأنظمة المالية مفتاحًا ثابتًا للمحاولة المنطقية حتى تعيد الاستعلام بدل إنشاء دفعة جديدة. ما الذي يراه المستخدم؟ يجب أن يرى حالة مفهومة وخطوة تالية: انتظر، أعد الاستعلام، صحح البيانات، أو تواصل مع الدعم. التفاصيل الداخلية للمزود لا ينبغي أن تتحول إلى رسالة غامضة للعميل. تابع إلى حالات عملية الدفع ودورة التسوية.", "lastReviewedAt": "2026-07-16" }, { "id": "payment-statuses", "locale": "ar", "title": "حالات عملية الدفع", "description": "معنى الحالات الناجحة والفاشلة والمعلقة والملغاة وكيفية التعامل معها.", "url": "/ar/docs/payments/payment-statuses", "category": "payments", "text": "الحالة توجه الفعل التالي لا تُعرض الحالة للزينة؛ هي عقد تشغيلي. يجب ألا يتعامل الكاشير مع المعلق كفشل، ولا الإدارة مع المنشأ كدخل محقق، ولا العميل مع رسالة الهاتف كمرجع يتقدم على سجل العملية. الحالات الشائعة منشأة: تم حفظ الطلب ولم يتم التأكيد بعد. تحتاج تأكيدًا: تنتظر إجراءً من المستخدم أو صاحب الصلاحية. قيد المعالجة: أرسلت للمسار المالي ولا توجد نتيجة نهائية بعد. ناجحة: اكتملت وفق شروط النجاح وسجل أثرها. فاشلة: لم تنفذ ويظهر سبب آمن وخطوة قابلة للتصحيح عند الإمكان. ملغاة أو منتهية: أغلقت قبل التنفيذ النهائي. مستردة جزئيًا أو كليًا: رُد جزء أو كل القيمة عبر مسار مرتبط بالأصل. ماذا تفعل مع المعلق؟ انتظر المدة الإرشادية، ثم حدّث الحالة باستخدام المرجع نفسه. لا تنشئ عملية جديدة لمجرد أن الشاشة لم تتغير. إذا تجاوزت الحالة نافذة المعالجة، صعّدها ببيانات آمنة. الرسائل الجيدة تشرح ما حدث وما الذي يمكن فعله دون كشف معلومات أمنية أو تفاصيل مزود غير مفيدة. مثال: «العملية قيد التحقق؛ لا تعِد الدفع قبل تحديث الحالة» أفضل من «خطأ 500». للحالات اليومية استخدم استكشاف أخطاء الدفع.", "lastReviewedAt": "2026-07-16" }, { "id": "refunds-reversals", "locale": "ar", "title": "الاسترداد والعكس المالي", "description": "الفرق بين إلغاء عملية قبل الاستقرار واسترداد قيمة بعد النجاح.", "url": "/ar/docs/payments/refunds-reversals", "category": "payments", "text": "مصطلحان لا ينبغي خلطهما العكس يعيد أثر عملية لم تستقر نهائيًا أو يعالج نتيجة متعارضة ضمن المسار المالي. الاسترداد هو عملية جديدة مرتبطة بدفعة ناجحة تعيد جزءًا أو كل القيمة وفق سياسة وصلاحية. كلاهما يحتاج مرجعًا واضحًا، لكن سببه وتوقيته وأثره المحاسبي يختلفان. الاسترداد الصحيح 1. افتح العملية الأصلية، لا تنشئ تحويلًا منفصلًا للعميل. 2. تحقق من المبلغ القابل للاسترداد والعملة. 3. سجل السبب بصورة مهنية وغير حساسة. 4. طبّق الموافقة إذا تجاوز المبلغ أو الدور الحد. 5. تابع حالة الاسترداد حتى النهاية. 6. تأكد من ظهوره في تقارير الفرع والتسوية والمصالحة. لماذا لا نستخدم تحويلًا يدويًا؟ لأنه يكسر العلاقة بين البيع والإرجاع، ويجعل التقارير تعرض إيرادًا كاملًا وتحويلًا غير مفسر، وقد يكرر الرد إذا عولج الاسترداد الأصلي لاحقًا. القيود التشغيلية لا يجوز أن يتجاوز مجموع الاستردادات القيمة الأصلية، ولا أن يغير العملة بصمت، ولا أن يحذف أثر العملية الناجحة. يجب أن يرى المراجع من طلب الاسترداد ومن اعتمده ومتى تغيرت حالته. راجع الأدوار والصلاحيات والمصالحة المالية.", "lastReviewedAt": "2026-07-16" }, { "id": "payroll-payouts", "locale": "ar", "title": "الرواتب والمدفوعات الجماعية", "description": "إعداد دفعات الرواتب والموردين بمراجعة وموافقة وتتبع واضح لكل مستفيد.", "url": "/ar/docs/payouts/payroll-payouts", "category": "payouts", "text": "الدفعة الجماعية ليست تحويلًا واحدًا كبيرًا تتكون دفعة الرواتب أو الموردين من ملف رئيسي ومجموعة مستفيدين، ولكل عنصر مبلغ وعملة وحالة وسبب فشل مستقل. نجاح بعض العناصر لا يعني نجاح الدفعة كلها، وفشل مستفيد لا ينبغي أن يعيد صرف من نجحوا. دورة العمل المقترحة 1. جهّز قائمة المستفيدين من مصدر معتمد. 2. طابق الهوية والمحفظة والعملة قبل إضافة المبلغ. 3. احسب الإجمالي وعدد العناصر وقارنها بالمصدر. 4. افصل بين من يجهز الدفعة ومن يعتمدها. 5. ثبّت القائمة بعد الاعتماد، وأي تعديل يعيدها للمراجعة. 6. نفّذ باستخدام مرجع ثابت يمنع التكرار. 7. تابع كل عنصر، ثم عالج الفاشل فقط وفق سبب واضح. الخصوصية لا تعرض راتب موظف لموظف آخر، ولا تضع بيانات حساسة في اسم الملف أو الملاحظات العامة. التقارير يجب أن تطبق الصلاحيات وتظهر الحد الأدنى اللازم للمراجع. إعادة المعالجة لا تنشئ دفعة جماعية جديدة لكل القائمة إذا فشل عدد محدود. أنشئ إعادة معالجة مرتبطة بالدفعة الأصلية وللعناصر المؤهلة فقط، مع الاحتفاظ بالتاريخ. بعد التنفيذ، استخدم دورة التسوية والمصالحة المالية للتأكد من الأثر الكلي.", "lastReviewedAt": "2026-07-16" }, { "id": "luxpay-ecosystem", "locale": "ar", "title": "كيف تعمل منظومة LuxPay؟", "description": "خريطة مبسطة تربط الهوية والمحفظة والأعمال والمدفوعات والتسوية.", "url": "/ar/docs/platform/luxpay-ecosystem", "category": "platform", "text": "الخريطة المبسطة تعمل LuxPay كسلسلة مترابطة: شخص موثوق → محفظة → عضوية في نشاط → فرع وصلاحية → عملية دفع → سجل مالي → تسوية ومصالحة . كل طبقة تجيب عن سؤال مختلف، ولا ينبغي اختصارها في رقم حساب واحد. الطبقات الأساسية الهوية تثبت من هو الشخص، ثم تسمح له بالانضمام إلى نشاط أو أكثر دون خلط هويته الشخصية بصلاحياته الوظيفية. المحفظة تحمل القيمة حسب العملة والحالة، وتفصل المتاح عن المعلق، وتعرض سجلًا مفهومًا للحركة. سياق العمل يحدد النشاط والفرع والدور والحدود. لا يجوز أن يختار العميل سياقًا ماليًا حساسًا بمجرد إرساله داخل الطلب. الدفع يدير دورة العملية، ويحميها من التكرار، ويتعامل مع المزودين دون جعل اختلافاتهم مرئية لكل مستخدم. السجل والتسوية يسجل الأثر المالي، ثم يجمع العمليات المؤهلة في تسويات يمكن مطابقتها بالتقارير والفروع. لماذا هذا الفصل مهم؟ لأن الشخص قد يكون عميلًا في موقف، وكاشيرًا في فرع، ومديرًا في نشاط آخر. الهوية واحدة، لكن الصلاحية والسياق يتغيران. هذا الفصل يسمح بالنمو دون نسخ الحسابات أو فقدان قابلية التدقيق. اقرأ بعد ذلك الهوية بين الشخص والنشاط ودورة حياة عملية الدفع.", "lastReviewedAt": "2026-07-16" }, { "id": "person-business-identity", "locale": "ar", "title": "الهوية بين الشخص والنشاط", "description": "كيف تفصل LuxPay هوية الإنسان عن عضوياته وأدواره داخل الأعمال.", "url": "/ar/docs/platform/person-business-identity", "category": "platform", "text": "هوية واحدة، أدوار متعددة تتعامل LuxPay مع الإنسان بوصفه شخصًا أولًا. بعد ذلك يحصل الشخص على عضويات داخل الأنشطة التجارية، ولكل عضوية دور ونطاق وحالة. لا يحتاج المستخدم إلى حساب جديد لكل فرع، ولا تمنحه هويته وحدها صلاحية مالية داخل أي نشاط. ما الذي تنتمي إليه كل طبقة؟ الشخص: الاسم، الهاتف الموثق، وسائل الاسترداد، والأجهزة. العضوية: علاقة الشخص بالنشاط وحالتها. الدور: مجموعة الأفعال المسموح بها. النطاق: النشاط أو الفروع التي يسري فيها الدور. القرار التشغيلي: السماح بالفعل في لحظته بناءً على الحالة والحدود. مثال عملي قد يملك أحمد محفظة شخصية، ويعمل كاشيرًا في الفرع الأول، ويملك صلاحية مراجعة فقط في الفرع الثاني. عند تسجيل الدخول لا تتغير هويته، لكن كل عملية تُقيّم ضمن العضوية والفرع والدور الفعلي. ضوابط مهمة إلغاء العضوية لا يحذف هوية الشخص أو سجله الشخصي. تغيير الدور لا يعيد كتابة العمليات السابقة. الفرع لا يؤخذ من إدخال غير موثوق إذا كان يمكن استنتاجه من الجلسة والجهاز. العمليات الحساسة قد تحتاج موافقة أو تحققًا إضافيًا حتى لو كان الدور يسمح بها عمومًا. هذا النموذج هو أساس الأدوار والصلاحيات والأجهزة الموثوقة.", "lastReviewedAt": "2026-07-16" }, { "id": "account-security", "locale": "ar", "title": "أمان الحساب والتحقق", "description": "طبقات الحماية التي تقلل الاستيلاء على الحساب دون تعقيد الاستخدام اليومي.", "url": "/ar/docs/security/account-security", "category": "security", "text": "الأمان يبدأ من الهوية تحمي LuxPay الحساب عبر طبقات: تحقق من وسيلة الاتصال، كلمة مرور أو وسيلة دخول قوية، جهاز معروف، جلسة محدودة، وتحقق إضافي عند العمليات الحساسة. لا تعتمد الحماية على سر واحد يمكن سرقته. ممارسات المستخدم استخدم كلمة مرور فريدة ومدير كلمات مرور إن أمكن. فعّل القياسات الحيوية على جهازك بعد تسجيل دخول موثوق. لا تشارك رمز التحقق حتى مع شخص يدعي أنه من الدعم. راجع إشعارات تسجيل الدخول والجهاز الجديد. أغلق الجلسات التي لا تعرفها وغيّر بيانات الدخول عند الاشتباه. اكتب عنوان LuxPay بنفسك أو استخدم التطبيق الرسمي بدل روابط الرسائل. العمليات الحساسة قد تطلب LuxPay تحققًا إضافيًا عند تغيير جهاز، أو استرداد حساب، أو رفع حدود، أو استرداد مبلغ كبير. هذا لا يعني أن الجلسة فشلت؛ بل أن حساسية القرار أعلى من مستوى الثقة الحالي. ما الذي لن يطلبه الدعم؟ لن يحتاج موظف الدعم إلى كلمة المرور أو رمز التحقق الكامل أو المفتاح السري. يمكنه طلب مرجع آمن ومعلومات تعريف محدودة لتحديد الحالة. عند فقد الجهاز، انتقل إلى الأجهزة الموثوقة. وللتصعيد الآمن، اقرأ التصعيد إلى الدعم.", "lastReviewedAt": "2026-07-16" }, { "id": "trusted-devices", "locale": "ar", "title": "الأجهزة الموثوقة", "description": "إدارة الأجهزة والجلسات والاستجابة لفقد الهاتف أو ظهور جهاز غير معروف.", "url": "/ar/docs/security/trusted-devices", "category": "security", "text": "ما هو الجهاز الموثوق؟ الجهاز الموثوق جهاز ربط بحسابك بعد تسجيل دخول وتحقق ناجحين. الثقة لا تمنح الجهاز صلاحية مفتوحة إلى الأبد؛ تظل الجلسة والدور والعملية والحدود عوامل مستقلة. عند إضافة جهاز راجع نوع الجهاز والوقت والموقع التقريبي إن ظهر، ولا توافق على إشعار لم تبدأه. سمِّ الأجهزة بطريقة تساعدك على تمييزها، خصوصًا في نقاط البيع والفروع. مراجعة الأجهزة احذف الأجهزة القديمة، وأوقف أجهزة الموظفين المنتقلين، ولا تستخدم جهازًا مشتركًا بحساب مشترك. في الأعمال، اربط الجهاز بنقطة تشغيل وفرع معتمدين، ثم راقب تغيير السياق غير المعتاد. فقدان الهاتف 1. استخدم جهازًا آمنًا للوصول إلى استرداد الحساب. 2. ألغِ جلسات الجهاز المفقود وثقته. 3. راجع النشاط منذ آخر وقت كنت تملكه فيه. 4. أبلغ عن أي عملية غير معروفة دون محاولة عكسها بتحويل يدوي. 5. غيّر وسيلة الدخول إذا كان احتمال كشفها قائمًا. جهاز غير معروف تعامل معه كحادث محتمل: ألغِ الجلسة، غيّر بيانات الدخول، راجع العضويات والصلاحيات، ثم صعّد بالوقت ونوع الجهاز والمرجع المتاح. راجع أمان الحساب والتحقق والتصعيد إلى الدعم.", "lastReviewedAt": "2026-07-16" }, { "id": "settlement-cycle", "locale": "ar", "title": "دورة التسوية", "description": "كيف تنتقل العمليات المؤهلة من الفروع إلى تقرير تسوية قابل للمراجعة.", "url": "/ar/docs/settlements/settlement-cycle", "category": "settlements", "text": "ما هي التسوية؟ التسوية هي تجميع منضبط للعمليات المالية المؤهلة ضمن فترة وسياق وعملة، ثم احتساب الإجمالي والرسوم والاستردادات وصافي القيمة. لا تعني أن كل عملية ناجحة تظهر فورًا في أي تقرير؛ فقد تختلف نافذة التسوية عن لحظة الدفع. المكونات فترة بداية ونهاية واضحة. النشاط والفروع المشمولة. العملة، فلا تخلط العملات في صافي واحد. العمليات الناجحة المؤهلة. الاستردادات والتعديلات المرتبطة. الرسوم أو الاستقطاعات الموثقة. صافي التسوية وحالتها. الحالات قد تكون التسوية قيد التجهيز، جاهزة للمراجعة، معتمدة، منفذة، أو تحتاج معالجة. تغيير الحالة يجب أن يسجل من اتخذ القرار وسببه، ولا يغير تفاصيل الدفعات الأصلية. قراءة التقرير ابدأ بعدد العمليات والإجمالي، ثم راجع الاستردادات والرسوم، ثم صافي المبلغ. بعد ذلك افحص العناصر المستبعدة أو المعلقة؛ فهي تفسر غالبًا الفرق بين مبيعات الفترة وصافي التسوية. ما بعد التسوية التسوية لا تغني عن المصالحة. المصالحة تثبت أن سجل العمليات والتسوية والتحويل أو القيد المقابل تتفق أو أن الفروقات مفسرة. تابع إلى المصالحة المالية.", "lastReviewedAt": "2026-07-16" }, { "id": "reconciliation", "locale": "ar", "title": "المصالحة المالية", "description": "مطابقة المدفوعات والتسويات والتقارير دون تعديل الأرقام لإخفاء الفروقات.", "url": "/ar/docs/settlements/reconciliation", "category": "settlements", "text": "هدف المصالحة المصالحة لا تجعل رقمين متساويين بالقوة، بل تفسر العلاقة بينهما. تقارن سجل العمليات بمخرجات نقاط البيع والتسويات والتحويلات أو القيود ذات الصلة، ثم تصنف الفروقات وتثبت طريقة معالجتها. طبقات المطابقة 1. الطلب مقابل الدفع: هل لكل طلب مدفوع عملية صحيحة؟ 2. الدفع مقابل السجل: هل الحالة والمبلغ والعملة مسجلة دون تكرار؟ 3. السجل مقابل التسوية: هل دخلت العمليات المؤهلة الدورة الصحيحة؟ 4. التسوية مقابل المقابل المالي: هل يساوي الصافي التحويل أو القيد المتوقع؟ أنواع الفروقات فرق توقيت بين نهاية اليوم ونافذة التسوية. عملية معلقة أو نتيجة متأخرة. استرداد سُجل في فترة مختلفة. رسم موثق لم يدخل مقارنة نقطة البيع. تكرار في نظام طرفي أو نقص في استيراد. فرق حقيقي يحتاج تحقيقًا واعتمادًا. قاعدة المعالجة لا تعدل العملية الأصلية لمجرد إغلاق الفرق. أنشئ حالة أو قيد تصحيح أو استثناء مرتبطًا بالمصدر، مع سبب وموافقات وأثر يمكن تتبعه. مخرجات المراجعة يجب أن تعرض المصالحة: ما تم مطابقته، وما بقي، وعمر الفرق، والمالك المسؤول، والخطوة التالية. اربطها بـالتشغيل والإغلاق اليومي والاسترداد والعكس المالي.", "lastReviewedAt": "2026-07-16" }, { "id": "what-is-luxpay", "locale": "ar", "title": "ما هي LuxPay؟", "description": "مدخل عملي لفهم LuxPay بوصفها بنية تشغيل للهوية والمحافظ والمدفوعات والتسوية.", "url": "/ar/docs/start/what-is-luxpay", "category": "start", "text": "الفكرة في دقيقة LuxPay ليست شاشة دفع منفصلة، بل منظومة تربط من يدفع و لمن تُدفع الأموال و بأي صلاحية و كيف تُسجل العملية و متى تصبح قابلة للتسوية . تبدأ الرحلة بهوية شخص موثوقة، ثم تُنشأ المحافظ والعضويات التجارية والفروع، وبعدها تمر كل دفعة عبر سجل واضح يمكن متابعته ومصالحته. هذا التصور يحوّل الدفع من لحظة عابرة إلى جزء من تشغيل العمل. فنجاح العملية مهم، لكن الأهم أن تعرف الإدارة أين حدثت، ومن نفذها، وما حالتها، وإلى أي تسوية تنتمي. ما الذي تجمعه المنصة؟ هوية موحدة للفرد، مع عضويات منفصلة في الأنشطة التجارية. محافظ وأرصدة حسب العملة والغرض التشغيلي. فروع ومشغلون وصلاحيات وحدود لا تُستمد من بيانات يرسلها المستخدم بنفسه. دورة دفع واضحة من الإنشاء إلى النجاح أو الفشل أو الإلغاء. تسوية ومصالحة تربطان العمليات بالتقارير المالية. سجل تدقيق يوضح القرارات والحالات دون كشف أسرار أو بيانات حساسة. لماذا يختلف هذا عن مجرد بوابة دفع؟ بوابة الدفع تنفذ العملية. أما البنية المالية الجيدة فتجعل العملية قابلة للفهم والضبط بعد تنفيذها. عندما يعمل النشاط عبر عدة فروع، أو يستخدم أكثر من مزود، أو يدفع رواتب وموردين، تصبح الرؤية الموحدة أهم من زر الدفع نفسه. مبدأ LuxPay: السهولة التي تتجاهل الانضباط المالي تتحول إلى مخاطرة، والأمان الذي يضيف احتكاكًا بلا ضرورة يصبح غير قابل للاستخدام. ابدأ من مسارك إن ك", "lastReviewedAt": "2026-07-16" }, { "id": "first-wallet", "locale": "ar", "title": "إنشاء أول محفظة", "description": "خطوات إعداد محفظة LuxPay وفهم الرصيد والعملات والأمان قبل أول عملية.", "url": "/ar/docs/start/first-wallet", "category": "start", "text": "قبل البدء المحفظة ليست اسم مستخدم ورصيدًا فقط؛ هي علاقة مالية مرتبطة بهوية موثوقة وأجهزة مصرح بها. جهّز رقم هاتف يمكنك الوصول إليه، وأدخل بياناتك كما تظهر في وثائقك، ولا تشارك رمز التحقق مع أي شخص. خطوات الإعداد 1. أنشئ حساب الشخص وأكمل التحقق المطلوب. 2. راجع اسمك ورقم هاتفك قبل اعتماد الهوية. 3. فعّل وسيلة دخول قوية، ثم أضف القياسات الحيوية بعد أول دخول ناجح إن كانت متاحة. 4. أنشئ المحفظة بالعملة المدعومة المناسبة لاستخدامك. 5. راجع حدود المحفظة وحالات الرصيد قبل استقبال الأموال. 6. نفّذ عملية صغيرة أولًا وتأكد من ظهورها في سجل النشاط. فهم الأرصدة الرصيد المتاح هو الجزء الذي يمكن استخدامه الآن. الرصيد المعلق يرتبط بعملية لم تنتهِ بعد أو ما زالت تحت المعالجة. لا تعتبر إشعارًا أو صورة شاشة دليلًا نهائيًا؛ المرجع هو حالة العملية داخل LuxPay وسجلها. حماية المحفظة من اليوم الأول لا تستخدم كلمة مرور معاد استخدامها في خدمة أخرى. لا توافق على جهاز لا تعرفه. راجع اسم المستفيد والمبلغ والعملة قبل التأكيد. عند فقدان الهاتف، استخدم مسار استعادة الحساب وألغِ ثقة الجهاز القديم. لا ترسل معلومات الهوية أو الرموز السرية إلى الدعم عبر قنوات غير معتمدة. الخطوة التالية بعد الإعداد، تعرّف على المحافظ والأرصدة والعملات، ثم جرّب إرسال واستقبال الأموال.", "lastReviewedAt": "2026-07-16" }, { "id": "first-business", "locale": "ar", "title": "إنشاء أول نشاط تجاري", "description": "إعداد ملف النشاط والفروع والمشغلين قبل استقبال أول دفعة.", "url": "/ar/docs/start/first-business", "category": "start", "text": "ابدأ بالكيان قبل جهاز الدفع الخطأ الشائع هو إضافة أجهزة أو كاشير قبل تعريف النشاط والفروع والصلاحيات. في LuxPay يبدأ الإعداد بالكيان التجاري، ثم العضويات، ثم الفروع، ثم نقاط التشغيل. هذا الترتيب يجعل كل دفعة مرتبطة بسياق موثوق بدل الاعتماد على حقول يرسلها الجهاز. التسلسل الموصى به 1. أنشئ ملف النشاط وأكمل التحقق والبيانات القانونية المطلوبة. 2. عيّن المالكين والإدارة المالية بصلاحيات منفصلة. 3. أضف الفروع بأسمائها ومواقعها ونطاقاتها التشغيلية. 4. أنشئ أدوارًا مثل مدير فرع وكاشير ومراجع، ولا تمنح الجميع صلاحية المدير. 5. اربط كل مشغل بفرع أو نطاق واضح. 6. اضبط حدود العمليات والموافقات والاسترداد. 7. اختبر عملية ودورة إغلاق يومي قبل الإطلاق العام. قراران يجب حسمهما مبكرًا حدد من يملك حق استرداد الأموال ومن يملك حق اعتماد التسوية أو مراجعتها . فصل هذه الصلاحيات يقلل الأخطاء ويمنع أن يكون الشخص نفسه منشئ العملية ومصححها ومراجعها. ما الذي يعنيه الجاهزية؟ لا تعني الجاهزية أن شاشة الدفع تعمل فقط. تعني أن الفروع صحيحة، والمستخدمين مقيدون، والإيصالات واضحة، والحالات المعلقة لها مسار، والتقارير اليومية قابلة للمراجعة. تابع إلى الفروع والمشغلين والأدوار والصلاحيات.", "lastReviewedAt": "2026-07-16" }, { "id": "payment-troubleshooting", "locale": "ar", "title": "استكشاف أخطاء الدفع", "description": "تشخيص العمليات المعلقة أو المكررة ظاهريًا أو غير المتطابقة دون خلق أثر مالي جديد.", "url": "/ar/docs/support/payment-troubleshooting", "category": "support", "text": "ابدأ بالحالة لا بإعادة المحاولة عند تعطل شاشة أو انقطاع اتصال، افتح سجل العملية وابحث بالمرجع والوقت والمبلغ. لا تعتبر غياب الإيصال فشلًا، ولا تعتبر خصمًا ظاهرًا نجاحًا نهائيًا قبل تطابق الحالة. عملية معلقة انتظر نافذة المعالجة المعتمدة، ثم حدّث الحالة بالمرجع نفسه. تحقق من اتصال الجهاز دون مسح بياناته أو إنشاء عملية بديلة. إذا تجاوزت النافذة، صعّدها. عمليتان متشابهتان قارن المرجع والوقت والمبلغ والحالة. قد تكون إحداهما محاولة لم تنفذ، أو قد يكون هناك تكرار حقيقي. لا تسترد أو تحول قبل تحديد العملية الأصلية والأثر المالي لكل مرجع. نجح الدفع ولم يتحدث الطلب افصل بين حالة الدفع وحالة نظام الطلب. احتفظ بالدفعة الناجحة، ثم أعد مزامنة الطلب أو اربطه بالمرجع المعتمد. لا تطلب من العميل الدفع ثانية لتصحيح مشكلة عرض. فشل الاسترداد تحقق من أهلية المبلغ والعملة وحالة العملية الأصلية والصلاحية. تابع حالة طلب الاسترداد القائم بدل إنشاء طلبات متعددة. بيانات التصعيد جهز الوقت والمنطقة الزمنية والمبلغ والعملة والفرع والمرجع الآمن والحالة الظاهرة. لا ترسل كلمة مرور أو رمز تحقق أو بيانات بطاقة كاملة. اقرأ التصعيد إلى الدعم.", "lastReviewedAt": "2026-07-16" }, { "id": "support-escalation", "locale": "ar", "title": "التصعيد إلى الدعم", "description": "متى تصعّد المشكلة وما المعلومات الآمنة التي تختصر زمن التشخيص.", "url": "/ar/docs/support/support-escalation", "category": "support", "text": "متى تحتاج إلى تصعيد؟ صعّد عندما تتجاوز العملية نافذة المعالجة، أو يظهر أثر مالي غير معروف، أو تتعطل وظيفة حرجة لعدة مستخدمين، أو تشك في جهاز أو حساب، أو لا يفسر الدليل التشغيلي الحالة. قبل فتح الحالة تأكد من أنك تستخدم القناة الرسمية. ابحث عن العملية بالمرجع نفسه. سجل الرسالة كما ظهرت دون مشاركة أسرار. حدد هل التأثير يخص مستخدمًا أو فرعًا أو عدة فروع. لا تجرب تغييرات مالية عشوائية بهدف اختبار المشكلة. المعلومات المفيدة والآمنة أرسل اسم النشاط أو معرفًا عامًا معتمدًا، الفرع، الوقت والمنطقة الزمنية، نوع العملية، المبلغ والعملة عند الحاجة، المرجع الآمن، الحالة الحالية، والخطوات التي سبقت المشكلة. أخفِ البيانات الشخصية غير الضرورية. معلومات لا ترسلها كلمة المرور، رمز التحقق، مفاتيح سرية، بيانات بطاقة كاملة، صور وثائق عبر قناة غير مخصصة، أو قاعدة بيانات وملفات سجل كاملة. درجات الأولوية الحادث الأمني أو توقف الدفع الواسع أعلى من سؤال استخدام. لكن لا ترفع الأولوية بإخفاء المعلومات؛ الوصف الدقيق للأثر يساعد الفريق على الاستجابة الصحيحة. ابدأ التشخيص بـاستكشاف أخطاء الدفع، وللاشتباه الأمني راجع أمان الحساب.", "lastReviewedAt": "2026-07-16" }, { "id": "wallet-balances-currencies", "locale": "ar", "title": "المحافظ والأرصدة والعملات", "description": "فهم بنية المحفظة والفرق بين الرصيد المتاح والمعلق والعملات المنفصلة.", "url": "/ar/docs/wallet/wallet-balances-currencies", "category": "wallet", "text": "المحفظة ليست رقمًا واحدًا قد يمتلك الشخص أو النشاط أكثر من محفظة بحسب العملة أو الغرض. لا يُجمع رصيد عملتين في رقم واحد، ولا تُعرض قيمة تحويل تقديرية بوصفها رصيدًا فعليًا. كل عملة تحتفظ بسجلها وحدودها وتسويتها. حالات الرصيد متاح: يمكن استخدامه ضمن الحدود الحالية. معلق: مرتبط بعملية لم تستقر نهائيًا. محجوز: مخصص مؤقتًا لالتزام أو عملية قيد التنفيذ. غير متاح: قيمة لا يمكن التصرف بها بسبب ضبط أو مراجعة أو قيد. قد تنجح واجهة الطلب بينما يبقى الأثر المالي قيد المعالجة؛ لذلك يجب متابعة حالة العملية بدل إجراء حساب يدوي على الإشعارات. العملات تعرض LuxPay كل محفظة بعملة واضحة، وتفصل أي نوعين من العملة المحلية عندما تكون لهما قواعد تشغيل أو تقييم مختلفة. التحويل بين العملات، إن توفر، هو عملية مستقلة بمعدل وسجل وموافقة، وليس تعديلًا صامتًا على الرقم. كيف تقرأ الحركة؟ راجع الوصف، المبلغ، العملة، الحالة، المرجع الزمني، والجهة المقابلة. إذا تغيرت الحالة، يحتفظ السجل بالتسلسل بدل إخفاء المرحلة السابقة. للاستخدام العملي، تابع إلى إرسال واستقبال الأموال واستكشاف أخطاء الدفع.", "lastReviewedAt": "2026-07-16" }, { "id": "send-receive-money", "locale": "ar", "title": "إرسال واستقبال الأموال", "description": "دليل آمن لفهم المستفيد والتأكيد وحالة التحويل وإثبات الاستلام.", "url": "/ar/docs/wallet/send-receive-money", "category": "wallet", "text": "قبل الإرسال تحقق من هوية المستفيد والمبلغ والعملة والغرض. لا تعتمد على اسم متشابه وحده، ولا تستجب لمن يطلب منك تنفيذ تحويل تجريبي ثم إعادة الأموال خارج المسار الأصلي. رحلة التحويل 1. اختر المحفظة والعملة الصحيحة. 2. حدد المستفيد من وسيلة موثوقة مثل QR أو سجل محفوظ. 3. راجع الرسوم والحدود والملخص النهائي. 4. أكد العملية مرة واحدة وانتظر النتيجة. 5. إذا كانت الحالة معلقة، لا تنشئ تحويلًا ثانيًا قبل فحص السجل. 6. شارك مرجعًا آمنًا عند الحاجة، وليس رمز دخول أو رمز تحقق. استقبال الأموال اعرض هوية استقبال مناسبة، وراجع أن العملية ظهرت داخل LuxPay بالحالة المتوقعة. صورة شاشة من هاتف المرسل أو رسالة غير موثقة لا تكفي لإطلاق بضاعة مرتفعة القيمة. عند وجود مشكلة لا تحاول تعويض العملية بتحويل يدوي غير مرتبط. وثّق الوقت والمبلغ والعملة والمرجع الآمن، ثم استخدم دليل استكشاف أخطاء الدفع. إذا احتاج الأمر تدخلًا، راجع التصعيد إلى الدعم.", "lastReviewedAt": "2026-07-16" }, { "id": "qr-payments", "locale": "ar", "title": "الدفع عبر QR", "description": "كيف تستخدم رموز QR للاستقبال والدفع دون تحويل الرمز إلى نقطة ثقة عمياء.", "url": "/ar/docs/wallet/qr-payments", "category": "wallet", "text": "ما الذي يفعله رمز QR؟ رمز QR يختصر إدخال بيانات الاستقبال أو جلسة الدفع، لكنه لا يلغي خطوة المراجعة. قد يكون الرمز ثابتًا لهوية تاجر، أو ديناميكيًا لعملية محددة بمبلغ ومدة صلاحية. في الحالتين يجب أن تعرض شاشة التأكيد اسم الجهة والمبلغ والعملة قبل تنفيذ العملية. للتاجر والكاشير استخدم الرمز الصادر من LuxPay أو من نقطة تشغيل معتمدة. لا تطبع رمزًا من لقطة شاشة مجهولة المصدر. اجعل الرمز الديناميكي مرتبطًا بطلب واحد ومدة محددة. لا تسلم الطلب بناءً على حركة في هاتف العميل؛ تحقق من حالة العملية داخل نقطة البيع. عند انتهاء الجلسة أنشئ رمزًا جديدًا بدل إعادة استخدام رمز منتهي. للعميل امسح الرمز من مصدر تثق به، ثم راجع اسم التاجر والفرع والمبلغ والعملة. إذا ظهرت جهة مختلفة أو طلب التطبيق إدخال بيانات حساسة خارج تجربة LuxPay، أوقف العملية. ما بعد المسح المسح لا يعني الدفع. تمر العملية بإنشاء جلسة، ثم تأكيد، ثم معالجة، ثم حالة نهائية أو معلقة. إن بقيت معلقة، اتبع حالات عملية الدفع ولا تكرر المسح والدفع تلقائيًا.", "lastReviewedAt": "2026-07-16" }, { "id": "future-payments", "locale": "en", "title": "The future of payments is not a faster button", "description": "Why competition is moving from transaction execution to management of its complete context.", "url": "/en/docs/academy/future-payments", "category": "academy", "text": "Speed is now a requirement, not a complete advantage When many platforms can move value in seconds, the difference is no longer the number of seconds alone. Competition moves to the context around payment: identity, authority, customer experience, order linkage, fee clarity, exception handling, settlement, and reconciliation. From channel to infrastructure A channel answers: how do I pay? Infrastructure also answers: why was the payment allowed, which business and branch own it, how is duplication prevented, what happens after connectivity loss, how does it enter reports, and who reviews a refund? What businesses need next Identity usable across services without duplicating accounts. Wallets that make currency and state explicit. Permissions following person, role, and branch. Payments integrated into operations instead of creating another data island. Financial records that support growth and review at the same time. Low friction for routine use and higher verification for sensitive decisions. The real commercial value A merchant does not buy “the future” as a slogan. The merchant buys the ability to open a branch without losing control, add a payment method without rebuilding rep", "lastReviewedAt": "2026-07-16" }, { "id": "operational-wallet", "locale": "en", "title": "The wallet as an operating tool", "description": "How a wallet moves from balance storage to a connection between people, work, payroll, and payments.", "url": "/en/docs/academy/operational-wallet", "category": "academy", "text": "A traditional wallet stores; an operational wallet connects If a wallet only shows balance and transfer, it remains a separate financial tool. An operational wallet connects person identity with work membership, salary receipt, payments, activity history, limits, and the experience across services. Three connected values For the person Clear balance states, receipt of money and payroll, and payment without redefining identity for every service. For the business Controlled payouts, employee and supplier linkage, and understandable batch outcomes instead of sending files and waiting for obscure results. For the platform Unified identity and records that allow new services without creating a separate financial account for every feature. Boundaries still matter Connection does not mean mixing ownership. A personal wallet does not become company funds, and employee membership does not reveal colleagues’ balances. Identity and experience can be unified while ownership, authority, and currency remain strictly isolated. Why this represents the future It lowers the cost of every new service. With identity, wallet, and records already in place, payroll, merchant payment, or a branch service ", "lastReviewedAt": "2026-07-16" }, { "id": "financial-discipline", "locale": "en", "title": "Financial discipline without excessive friction", "description": "How a strong payment experience combines ease, auditability, and control.", "url": "/en/docs/academy/financial-discipline", "category": "academy", "text": "The false trade off Security is sometimes described as an obstacle to usability, or ease as requiring weaker control. The problem is usually not the existence of controls but their placement. Heavy verification for every small routine payment is poor design, and so is allowing a large refund from an old session. Proportionate control A good experience combines device, verification age, role, branch, amount, behavior pattern, and operation type. Routine actions remain smooth when trust is sufficient, while requirements increase when context changes or sensitivity rises. What remains behind the interface? Duplicate prevention even when a user clicks twice. Deriving business and branch identity from trusted context. Recording the decision without logging secrets. Separating execution and review where required. Preserving state history instead of silently editing outcomes. Failing closed when sensitive authority cannot be established. The commercial result Discipline is not only a compliance burden; it is what makes scale possible. A business can delegate branches, offer refunds, use providers, and pay salaries while management can still explain money movement. Connect this concept wit", "lastReviewedAt": "2026-07-16" }, { "id": "branches-operators", "locale": "en", "title": "Branches and operators", "description": "Structure branches, operating points, and users so reports reflect operational reality.", "url": "/en/docs/business/branches-operators", "category": "business", "text": "A branch is financial context, not only an address A branch determines where a transaction belongs, who is responsible, which limits apply, and how settlement is reported. Give it a stable name, clear internal code, operating scope, and active or suspended state. Renaming must not erase historical identity. Add operators Add a user through a verified membership, then define the role and branches where it applies. Avoid shared accounts: every action should be attributable to a person, role, device, and reviewable context. Operator lifecycle 1. Invite and verify the member. 2. Assign role and scope. 3. Approve the device or operating point. 4. Start a work session or shift when required. 5. Review activity periodically. 6. Suspend membership or remove access when the relationship ends. Moving an employee between branches Do not rewrite previous transaction history. End the old scope at a defined time and activate the new scope. Yesterday’s reports then remain attached to the branch where activity actually occurred. Control signals Review inactive users, broad roles, old devices, and activity outside expected hours. Connect this with Roles and permissions and Daily operations and clos", "lastReviewedAt": "2026-07-16" }, { "id": "roles-permissions", "locale": "en", "title": "Roles and permissions", "description": "Design permissions that reduce error and separate execution, review, and approval.", "url": "/en/docs/business/roles-permissions", "category": "business", "text": "Start with tasks, not titles Roles called manager and employee are not enough. List the actions each role needs: accept payment, view reports, create a refund, approve a refund, manage users, or review settlement. Then grant the smallest useful set. Separation of duties For sensitive operations, separate: The person creating an action from the person approving it. The person refunding funds from the person reviewing refunds. User administration from audit review. Settlement preparation from settlement approval. Separation does not have to block routine work. Amount thresholds or step up approval can apply only when an action exceeds the ordinary range. Scope and duration Authority should define what action , where it applies , and for how long . A branch manager does not automatically control all branches, and temporary access should expire automatically. Periodic review Review access after role changes, transfers, contract termination, and incidents. Do not rely on memory; use active membership, device, and sensitive action reports. Broad permission is faster during setup, but it turns every small mistake into a larger financial effect. Also read Person and business identity and A", "lastReviewedAt": "2026-07-16" }, { "id": "daily-operations", "locale": "en", "title": "Daily operations and close", "description": "A practical routine for cashiers and branch managers from opening through daily review.", "url": "/en/docs/business/daily-operations", "category": "business", "text": "Start of day Verify the device, branch, and active user, then review connectivity, alerts, and limits. Never begin work in another user’s session or ignore a message that the device or branch is unauthorized. During operations Create every payment from the real order and do not alter the amount outside the approved flow after confirmation. Review pending states before retrying. Use a refund linked to the original transaction instead of a manual transfer. Do not share an account when cashiers change; end the session and open a new one. Record operational exceptions in the designated field, not personal messages. End of shift 1. Pause new transactions during review. 2. Review successful, failed, pending, and cancelled activity. 3. Inspect high value refunds and adjustments. 4. Compare point of sale totals with the LuxPay report by currency. 5. Classify differences as timing, pending activity, entry error, or escalation. 6. Close the session and export the authorized report. What not to do Do not force numbers to match through an arbitrary manual adjustment. Closing is about explaining a difference and linking it to a transaction or state. Use Financial reconciliation for issues exten", "lastReviewedAt": "2026-07-16" }, { "id": "payment-lifecycle", "locale": "en", "title": "The payment lifecycle", "description": "From payment intent creation to final state, financial record, and settlement.", "url": "/en/docs/payments/payment-lifecycle", "category": "payments", "text": "Why a lifecycle exists A payment is not always one request that immediately succeeds or fails. It can require creation, confirmation, provider processing, outcome verification, financial recording, and settlement. A lifecycle prevents the interface from interpreting a missing response as confirmed failure. Main stages 1. Creation: define amount, currency, merchant, and reference without executing the same effect twice. 2. Confirmation: the authorized person or customer approves the final details. 3. Processing: submit through the approved financial path. 4. Outcome: success, failure, cancellation, or additional verification. 5. Recording: preserve financial effect, reference, and state history. 6. Settlement: include eligible activity in a settlement cycle. 7. Reconciliation: match transaction, settlement, and report. Duplicate protection If connectivity ends after confirmation, it does not prove the payment did not execute. Financial systems use a stable key for the logical attempt so the client can retrieve the outcome instead of creating a new payment. What the user should see The interface should present an understandable state and next step: wait, refresh status, correct data,", "lastReviewedAt": "2026-07-16" }, { "id": "payment-statuses", "locale": "en", "title": "Payment states", "description": "Understand successful, failed, pending, cancelled, and refunded states and the correct response to each.", "url": "/en/docs/payments/payment-statuses", "category": "payments", "text": "State directs the next action A state is not decoration; it is an operational contract. A cashier should not treat pending as failed, finance should not treat created as realized revenue, and a phone message should not override the transaction record. Common states Created: the request exists but is not confirmed. Requires confirmation: waiting for the customer or authorized operator. Processing: submitted to the financial path without a final outcome. Succeeded: completion conditions are met and the effect is recorded. Failed: not executed, with a safe reason and corrective step when possible. Cancelled or expired: closed before final execution. Partially or fully refunded: value returned through a flow linked to the original transaction. What to do with pending Wait for the documented interval, then refresh using the same reference. Do not create a new transaction only because the screen did not change. If the state exceeds its processing window, escalate with safe evidence. Good messages They explain what happened and what can be done without exposing security data or irrelevant provider internals. “The payment is being verified; do not pay again before refreshing status” is bet", "lastReviewedAt": "2026-07-16" }, { "id": "refunds-reversals", "locale": "en", "title": "Refunds and reversals", "description": "Distinguish a reversal before finality from a refund after a successful payment.", "url": "/en/docs/payments/refunds-reversals", "category": "payments", "text": "Two terms that should not be confused A reversal restores the effect of a transaction that did not reach finality or resolves a contradictory financial outcome. A refund is a new action linked to a successful payment that returns part or all of the value under policy and authority. Both need a clear reference, but their reason, timing, and accounting effect differ. The correct refund flow 1. Open the original transaction instead of creating a separate transfer. 2. Verify refundable amount and currency. 3. Record a professional, non sensitive reason. 4. Apply approval when amount or role exceeds the limit. 5. Follow the refund state to completion. 6. Confirm that it appears in branch, settlement, and reconciliation reports. Why not use a manual transfer? It breaks the relationship between sale and return, leaving reports with full revenue and an unexplained transfer. It can also duplicate the return if the original refund later completes. Operational constraints Total refunds cannot exceed original value, silently change currency, or delete the successful payment record. Reviewers should see who requested the refund, who approved it, and when the state changed. Review Roles and perm", "lastReviewedAt": "2026-07-16" }, { "id": "payroll-payouts", "locale": "en", "title": "Payroll and bulk payouts", "description": "Prepare payroll and supplier batches with review, approval, and clear per-beneficiary tracking.", "url": "/en/docs/payouts/payroll-payouts", "category": "payouts", "text": "A bulk payout is not one large transfer Payroll or supplier payout consists of a parent batch and multiple beneficiary items. Every item has its own amount, currency, state, and failure reason. Partial success does not make the whole batch successful, and one failed beneficiary must not cause successful recipients to be paid again. Recommended workflow 1. Prepare beneficiaries from an approved source. 2. Match identity, wallet, and currency before assigning value. 3. Compare total amount and item count with the source. 4. Separate preparation from approval. 5. Freeze the list after approval; any edit returns it to review. 6. Execute with a stable reference that prevents duplication. 7. Track every item and reprocess only eligible failures. Privacy Do not expose one employee’s salary to another or place sensitive information in filenames and general notes. Reports must enforce permissions and reveal only what a reviewer needs. Reprocessing Do not create a new batch for the full list when only a few items fail. Create a retry linked to the original batch and containing only eligible items while preserving history. After execution, use The settlement cycle and Financial reconciliation", "lastReviewedAt": "2026-07-16" }, { "id": "luxpay-ecosystem", "locale": "en", "title": "How the LuxPay ecosystem works", "description": "A simplified map connecting identity, wallets, businesses, payments, settlement, and reconciliation.", "url": "/en/docs/platform/luxpay-ecosystem", "category": "platform", "text": "The simplified map LuxPay works as a connected chain: trusted person → wallet → business membership → branch and authority → payment → financial record → settlement and reconciliation . Each layer answers a different question and should not be collapsed into one account number. Core layers Identity It establishes who the person is, then lets that person join one or more businesses without confusing personal identity with job authority. Wallet It holds value by currency and state, separates available from pending funds, and presents understandable movement history. Business context It determines business, branch, role, and limits. A client cannot obtain sensitive financial authority simply by submitting a context value in a request. Payment It manages the transaction lifecycle, protects against duplicate execution, and absorbs provider differences instead of exposing them to every user. Record and settlement It records financial effect, then groups eligible transactions into settlements that can be matched against branch and finance reports. Why separation matters The same person can be a customer in one moment, a cashier in a branch, and a manager in another business. Identity stay", "lastReviewedAt": "2026-07-16" }, { "id": "person-business-identity", "locale": "en", "title": "Person and business identity", "description": "How LuxPay separates a human identity from memberships and roles inside businesses.", "url": "/en/docs/platform/person-business-identity", "category": "platform", "text": "One identity, many roles LuxPay treats the human as a person first. The person then receives memberships in businesses, each with its own role, scope, and status. A user does not need a new identity for every branch, and identity alone never grants financial authority in a business. What belongs to each layer? Person: name, verified phone, recovery methods, and devices. Membership: the relationship between the person and a business. Role: the set of permitted actions. Scope: the business or branches where the role applies. Operational decision: permission at the moment of action based on state and limits. Practical example Ahmed can own a personal wallet, work as a cashier in branch one, and have read only review authority in branch two. His identity does not change at sign in, but every action is evaluated against the active membership, branch, and role. Important controls Revoking a membership does not delete the person identity or personal history. Changing a role does not rewrite past transactions. Branch context should not come from an untrusted input when it can be derived from the session and device. Sensitive actions can require approval or step up verification even when th", "lastReviewedAt": "2026-07-16" }, { "id": "account-security", "locale": "en", "title": "Account security and verification", "description": "Protection layers that reduce account takeover without making daily use unnecessarily difficult.", "url": "/en/docs/security/account-security", "category": "security", "text": "Security starts with identity LuxPay protects accounts through layers: verified contact, a strong sign in method, a known device, a bounded session, and additional verification for sensitive operations. Protection does not depend on one secret that can be stolen. User practices Use a unique password and a password manager when possible. Enable biometrics after a trusted sign in on your device. Never share a verification code, even with someone claiming to be support. Review new sign in and device notifications. Close unfamiliar sessions and change credentials when suspicious. Type the LuxPay address or use the official app instead of message links. Sensitive operations LuxPay can request step up verification for a new device, account recovery, higher limits, or a high value refund. This does not mean the session failed; it means the decision requires more trust than the current session provides. What support will not request Support does not need your password, complete verification code, or secret key. It can use a safe reference and limited identifying information to locate the case. If a device is lost, continue to Trusted devices. For safe escalation, read Support escalation.", "lastReviewedAt": "2026-07-16" }, { "id": "trusted-devices", "locale": "en", "title": "Trusted devices", "description": "Manage devices and sessions and respond to a lost phone or an unfamiliar device.", "url": "/en/docs/security/trusted-devices", "category": "security", "text": "What is a trusted device? A trusted device is linked to the account after successful sign in and verification. Trust does not grant unlimited authority forever; session, role, operation, and limits remain independent controls. When adding a device Review device type, time, and approximate location when available. Never approve a prompt you did not initiate. Give devices recognizable names, especially for points of sale and branches. Device review Remove old devices, disable devices belonging to transferred staff, and avoid shared devices with shared accounts. For business use, bind each device to an approved operating point and branch, then monitor unusual context changes. Lost phone 1. Use a secure device to access account recovery. 2. Revoke sessions and trust for the lost device. 3. Review activity since the last time you controlled it. 4. Report unknown transactions without trying to reverse them through a manual transfer. 5. Change the sign in method when exposure is possible. Unfamiliar device Treat it as a potential incident: revoke the session, change credentials, review memberships and permissions, then escalate with time, device type, and available safe reference. Review ", "lastReviewedAt": "2026-07-16" }, { "id": "settlement-cycle", "locale": "en", "title": "The settlement cycle", "description": "How eligible branch transactions become a reviewable settlement report.", "url": "/en/docs/settlements/settlement-cycle", "category": "settlements", "text": "What is settlement? Settlement is the controlled grouping of eligible financial transactions by period, context, and currency, followed by calculation of gross value, fees, refunds, and net value. A successful payment does not always appear immediately in every report because the settlement window can differ from payment time. Components Clear start and end period. Included business and branches. Currency, without combining currencies into one net value. Eligible successful transactions. Linked refunds and adjustments. Documented fees or deductions. Net settlement and state. States A settlement can be preparing, ready for review, approved, executed, or requiring attention. Every transition should record who made the decision and why, without rewriting original payment details. Reading the report Begin with transaction count and gross value, then review refunds and fees, and finally net value. Inspect excluded or pending items next; these often explain the difference between period sales and settlement net. After settlement Settlement does not replace reconciliation. Reconciliation proves that transaction records, settlement, and the corresponding transfer or entry agree—or that dif", "lastReviewedAt": "2026-07-16" }, { "id": "reconciliation", "locale": "en", "title": "Financial reconciliation", "description": "Match payments, settlements, and reports without editing numbers to hide differences.", "url": "/en/docs/settlements/reconciliation", "category": "settlements", "text": "The goal of reconciliation Reconciliation does not force two numbers to match. It explains the relationship between them. It compares transaction records with point of sale output, settlements, transfers, or related entries, then classifies differences and documents resolution. Matching layers 1. Order to payment: does each paid order have the correct transaction? 2. Payment to record: are state, amount, and currency recorded without duplication? 3. Record to settlement: did eligible transactions enter the correct cycle? 4. Settlement to financial counterpart: does net value match the expected transfer or entry? Difference types Timing between daily close and settlement window. Pending transaction or delayed outcome. Refund recorded in a different period. Documented fee absent from the point of sale comparison. Duplication in an external system or incomplete import. A real difference requiring investigation and approval. Resolution rule Do not edit the original transaction merely to close a difference. Create a correction, exception, or state linked to the source with reason, approval, and traceable effect. Review output Reconciliation should show what matched, what remains, differ", "lastReviewedAt": "2026-07-16" }, { "id": "what-is-luxpay", "locale": "en", "title": "What is LuxPay?", "description": "A practical introduction to LuxPay as operating infrastructure for identity, wallets, payments, and settlement.", "url": "/en/docs/start/what-is-luxpay", "category": "start", "text": "The idea in one minute LuxPay is not an isolated payment screen. It connects who pays , who receives , which authority permits the action , how the transaction is recorded , and when it becomes eligible for settlement . The journey starts with a trusted person identity, then adds wallets, business memberships, and branches. Every payment moves through a clear state model that can be traced and reconciled. This turns payment from a passing event into part of business operations. Approval matters, but an operator also needs to know where the payment happened, who initiated it, what state it is in, and which settlement contains it. What the platform brings together One person identity with separate memberships in businesses. Wallets and balances organized by currency and operating purpose. Branches, operators, permissions, and limits derived from trusted context. A clear payment lifecycle from creation to success, failure, or cancellation. Settlement and reconciliation that connect transactions to financial reports. An audit trail that explains decisions without exposing secrets or sensitive data. Why this is more than a payment gateway A gateway executes a transaction. Financial infr", "lastReviewedAt": "2026-07-16" }, { "id": "first-wallet", "locale": "en", "title": "Create your first wallet", "description": "Set up a LuxPay wallet and understand balances, currencies, and security before the first transaction.", "url": "/en/docs/start/first-wallet", "category": "start", "text": "Before you begin A wallet is not only a username and balance. It is a financial relationship connected to a trusted identity and authorized devices. Prepare a phone number you control, enter identity details exactly as documented, and never share a verification code. Setup steps 1. Create the person account and complete the required verification. 2. Review your name and phone number before confirming the identity. 3. Enable a strong sign in method, then add biometrics after the first successful login when available. 4. Create the wallet in the supported currency appropriate for your use. 5. Review wallet limits and balance states before receiving funds. 6. Run a small first transaction and confirm that it appears in activity history. Understand the balances Available balance can be used now. Pending balance belongs to a transaction that is incomplete or still processing. A notification or screenshot is not final proof of payment; the LuxPay transaction state and its record are the authoritative reference. Protect the wallet from day one Do not reuse a password from another service. Never approve an unfamiliar device. Review beneficiary, amount, and currency before confirmation. If ", "lastReviewedAt": "2026-07-16" }, { "id": "first-business", "locale": "en", "title": "Create your first business", "description": "Configure the business, branches, and operators before accepting the first payment.", "url": "/en/docs/start/first-business", "category": "start", "text": "Start with the entity, not the terminal A common mistake is adding devices or cashiers before defining the business, branches, and authority model. LuxPay starts with the business entity, then memberships, branches, and operating points. This makes every payment inherit trusted context rather than relying on fields sent by a device. Recommended sequence 1. Create the business profile and complete required legal verification. 2. Assign owners and finance operators with separate permissions. 3. Add branches with clear names, locations, and operating scope. 4. Define roles such as branch manager, cashier, and reviewer; do not make everyone an administrator. 5. Bind each operator to a clear branch or scope. 6. Configure transaction, approval, and refund limits. 7. Test a payment and daily close cycle before public launch. Two decisions to make early Decide who can refund funds and who can approve or review settlement . Separating these authorities reduces errors and prevents one person from initiating, correcting, and reviewing the same financial action. What readiness means Readiness is not only a working payment screen. It means branches are correct, users are constrained, receipts a", "lastReviewedAt": "2026-07-16" }, { "id": "payment-troubleshooting", "locale": "en", "title": "Payment troubleshooting", "description": "Diagnose pending, apparently duplicated, or mismatched payments without creating new financial effect.", "url": "/en/docs/support/payment-troubleshooting", "category": "support", "text": "Start with state, not retry When a screen fails or connectivity drops, open transaction history and search by reference, time, and amount. Missing receipt is not proof of failure, and a visible debit is not final proof of success until the state is verified. Pending transaction Wait for the approved processing window, then refresh using the same reference. Check connectivity without clearing data or creating a substitute payment. Escalate if it exceeds the window. Two similar transactions Compare reference, time, amount, and state. One can be an unexecuted attempt, or there can be a real duplicate. Do not refund or transfer before identifying the original and the financial effect of each reference. Payment succeeded but order did not update Separate payment state from order system state. Preserve the successful payment, then resynchronize or link the order to the approved reference. Do not ask the customer to pay again to correct a display issue. Refund failed Verify refundable amount, currency, original transaction state, and authority. Follow the existing refund request rather than creating several requests. Escalation evidence Prepare time and timezone, amount, currency, branch,", "lastReviewedAt": "2026-07-16" }, { "id": "support-escalation", "locale": "en", "title": "Support escalation", "description": "Know when to escalate and which safe information shortens diagnosis time.", "url": "/en/docs/support/support-escalation", "category": "support", "text": "When should you escalate? Escalate when a transaction exceeds its processing window, an unknown financial effect appears, a critical capability fails for several users, a device or account is suspicious, or the operating guide does not explain the state. Before opening a case Confirm that you are using an official channel. Search for the transaction with the same reference. Record the message exactly without sharing secrets. Identify whether impact affects one user, one branch, or several branches. Do not make random financial changes to test the problem. Useful and safe information Provide business name or approved public identifier, branch, time and timezone, transaction type, amount and currency when relevant, safe reference, current state, and the steps before the issue. Remove unnecessary personal data. Information not to send Passwords, verification codes, secret keys, full card data, identity documents through an unsuitable channel, or complete databases and log archives. Priority levels A security incident or broad payment outage is more urgent than a usage question. Do not inflate priority by hiding details; an accurate impact description helps the team respond correctly. ", "lastReviewedAt": "2026-07-16" }, { "id": "wallet-balances-currencies", "locale": "en", "title": "Wallets, balances, and currencies", "description": "Understand wallet structure, available and pending balances, and isolated currency positions.", "url": "/en/docs/wallet/wallet-balances-currencies", "category": "wallet", "text": "A wallet is not one number A person or business can hold more than one wallet by currency or operating purpose. Two currencies are not combined into one balance, and an estimated converted value is not presented as actual funds. Each currency keeps its own record, limits, and settlement context. Balance states Available: usable within current limits. Pending: connected to a transaction that has not reached finality. Reserved: temporarily allocated to an obligation or in flight action. Unavailable: restricted by a control, review, or financial condition. A request interface can complete while its financial effect remains processing. Follow the transaction state rather than manually calculating from notifications. Currencies LuxPay displays every wallet with an explicit currency and separates local currency variants when they have different operating or valuation rules. Currency conversion, when offered, is a distinct action with a rate, record, and approval—not a silent balance edit. How to read an entry Review description, amount, currency, state, timestamp reference, and counterparty. When a state changes, history keeps the sequence rather than hiding the earlier stage. For practi", "lastReviewedAt": "2026-07-16" }, { "id": "send-receive-money", "locale": "en", "title": "Send and receive money", "description": "A safe guide to beneficiaries, confirmation, transfer states, and proof of receipt.", "url": "/en/docs/wallet/send-receive-money", "category": "wallet", "text": "Before sending Verify beneficiary identity, amount, currency, and purpose. Do not rely on a similar display name alone, and do not follow requests to make a test transfer and return funds outside the original flow. Transfer journey 1. Choose the correct wallet and currency. 2. Select the beneficiary through a trusted method such as a QR code or saved record. 3. Review fees, limits, and the final summary. 4. Confirm once and wait for the result. 5. If the state is pending, do not create a second transfer before checking history. 6. Share a safe transaction reference when needed, never a sign in or verification code. Receiving funds Present an appropriate receiving identity and confirm that the transaction appears in LuxPay with the expected state. A screenshot from the sender’s phone or an unverified message is not sufficient evidence for releasing high value goods. When something goes wrong Do not compensate with an unrelated manual transfer. Record time, amount, currency, and safe reference, then use Payment troubleshooting. When intervention is required, follow Support escalation.", "lastReviewedAt": "2026-07-16" }, { "id": "qr-payments", "locale": "en", "title": "QR payments", "description": "Use QR codes for payment and acceptance without treating the code as blind trust.", "url": "/en/docs/wallet/qr-payments", "category": "wallet", "text": "What does a QR code do? A QR code shortens entry of receiving details or a payment session, but it does not remove review. A code can be static for a merchant identity or dynamic for one transaction with an amount and expiry. In both cases, the confirmation screen should show recipient, amount, and currency before execution. For merchants and cashiers Use a code issued by LuxPay or an approved operating point. Do not print a code copied from an unknown screenshot. Bind dynamic codes to one order and a limited lifetime. Do not release an order based on movement on the customer’s phone; verify the state in the point of sale. Create a new code after session expiry instead of reusing the expired one. For customers Scan from a source you trust, then review merchant, branch, amount, and currency. Stop if the recipient differs or the experience requests sensitive data outside LuxPay. After scanning Scanning is not payment. The flow creates a session, receives confirmation, processes the transaction, and reaches a final or pending state. If pending, follow Payment states and do not automatically scan and pay again.", "lastReviewedAt": "2026-07-16" } ] }