المؤسسات والتطبيقات والبيئات
تضم المؤسسة فريقك وفوترتك؛ وتضم التطبيقات سير العمل ومفاتيح API، وكل تطبيق إما مباشر أو sandbox. ضبط هذا الهيكل بشكل صحيح يمنع معظم السلوكيات المربكة.
المؤسسة = فريقك، ورصيد فوترتك، وسجل التدقيق الخاص بك. التطبيق = سير العمل، ومفتاح API، ووجهات webhook، وسياسة الاحتفاظ - ونمط إما live أو sandbox. معظم مشكلات "غيّرت شيئًا ولم يحدث أي أثر" سببها التواجد في التطبيق الخاطئ.
#المستويان
المؤسسة هي حسابك. وهي تمتلك:
- فريقك وأدوارهم
- رصيد فوترتك وفواتيرك
- سجل التدقيق الخاص بك
- جميع تطبيقاتك
التطبيق هو مساحة عمل داخل المؤسسة. وهو يمتلك:
- سير العمل الخاص به
- مفتاح API الخاص به
- وجهات webhook الخاصة به
- سياسة الاحتفاظ بالبيانات الخاصة به
- نمط: إما
liveأوsandbox
بدّل بين التطبيقات من القائمة المنسدلة أعلى الكونسول.
#لماذا هذا أهم مما يبدو
تعود جل بلاغات "غيّرت الأمر ولم يحدث شيء" إلى هذا الهيكل:
- عدّلت سير عمل في التطبيق A بينما تعمل جلساتك تحت التطبيق B.
- أضفت وجهة webhook إلى تطبيق ما وتوقعت أحداثًا من تطبيق آخر.
- تستدعي باستخدام مفتاح من تطبيق مختلف عن المورد الذي تخاطبه، فتحصل على خطأ 404 أو 403 لشيء موجود بوضوح.
قبل تصحيح أي شيء آخر، تأكد من التطبيق. راجع أخطاء API ومعناها.
#المباشر وsandbox تطبيقان منفصلان
لا يوجد مفتاح تبديل لوضع الاختبار داخل تطبيق مباشر. يُختار النمط لكل تطبيق على حدة، لذا فإن الاختبار يعني إنشاء تطبيق ثانٍ في وضع sandbox واستخدام مفتاحه.
هذا الفصل هو بيت القصيد: فحركة الاختبار وبيانات الإنتاج لا تختلطان أبدًا، ولا يمكن لمفتاح sandbox أن ينفق رصيدًا حقيقيًا عن طريق الخطأ. راجع الاختبار في sandbox.
سمِّ تطبيقاتك بحيث لا تختلط عليك أبدًا من نظرة واحدة - acme-live وacme-sandbox
أفضل من "Application" و"Application (2)". خزّن المفاتيح بأسماء مطابقة في مدير
الأسرار الخاص بك، ولا تترك أبدًا متغير بيئة واحدًا يحمل "أيًا كان المفتاح
الحالي".
#كم عدد التطبيقات التي ينبغي أن تمتلكها؟
في الحد الأدنى، تطبيق مباشر واحد وتطبيق sandbox واحد. وبعد ذلك، افصل حسب أي شيء يحتاج إلى تهيئته الخاصة أو عزله الخاص:
- لكل منتج، عندما تحتاج المنتجات المختلفة إلى سير عمل ونقاط نهاية webhook مختلفة.
- لكل بيئة، إذا كنت تشغّل أكثر من بيئة ما قبل الإنتاج.
- لكل علامة تجارية، إذا كنت تقدّم التحقق تحت عدة علامات تجارية بأنماط مختلفة.
- لكل سياسة احتفاظ، بما أن الاحتفاظ يُضبط لكل تطبيق على حدة.
ما لا ينقسم حسب التطبيق: رصيدك، وهو على مستوى المؤسسة. كل تطبيق يسحب من الرصيد نفسه.
#إنشاء تطبيقات إضافية
تُنشأ التطبيقات الإضافية من الكونسول. إذا كان الخيار مفقودًا، أو احتجت إلى إنشاء تطبيق عبر API بدلًا من الكونسول، فهذه مسألة صلاحيات على مستوى الحساب تستحق سؤال الدعم عنها بدلًا من الالتفاف حولها - خصوصًا في حالة تطبيق مباشر ثانٍ، حيث قد تتعلق الإجابة بخطتك.
#مؤسسات متعددة
ينتمي بريد الشخص الواحد إلى مؤسسة واحدة في كل مرة، ولا توجد طريقة لإنشاء مؤسسات فرعية أو حسابات فرعية تحت مؤسستك. إذا كنت تخدم عدة عملاء لك، فالبنية المدعومة هي تطبيق واحد لكل عميل داخل مؤسستك الوحيدة: لكل تطبيق مسارات عمله وعلامته التجارية ومفاتيح API ونتائجه وتقارير استخدامه، معزولة تمامًا عن غيرها، بينما تبقى الفوترة على مستوى مؤسستك.
#إعادة بيع Didit
إذا أردت دمج Didit في منتجك وتحصيل رسوم من عملائك مقابله، فهذا هو نموذج الموزع. وإليك كيف يعمل، بالشروط التي يقدمها الدعم لكل من يسأل:
- رصيد مدفوع مسبقًا. حد أدنى للشراء الأولي قدره 5,000 دولار أمريكي، مدفوع مسبقًا، باتفاقية لمدة سنة. لا تنتهي صلاحية الرصيد، ويقع على مستوى مؤسستك ويُستهلك عبر جميع العملاء النهائيين الذين تضيفهم، ويتضمن خصمًا على الحجم يزداد مع المبلغ.
- أنت تبني لوحة التحكم. تدمج API الخاصة بـ Didit في واجهتك الأمامية، ويدير عملاؤك هناك مسارات عملهم وعلامتهم التجارية وأدوارهم. Didit لا توفر نسخة بعلامة بيضاء من Business Console؛ شاشات التحقق التي يراها المستخدمون النهائيون يمكن أن تحمل علامتك التجارية (راجع العلامة البيضاء)، أما وحدة التحكم فلا.
- هامش ربحك لك. أنت تحدد السعر الذي يدفعه عملاؤك. تفوترك Didit لكل ميزة مكتملة بأسعار الوحدة الثابتة طوال مدة الاتفاقية.
- ليس برنامج شركاء محليين. تجري Didit العروض التوضيحية والتهيئة والدعم مباشرة مع العملاء ولا تبحث عن شركاء توزيع أو تنفيذ.
إذا فضّلت عدم التعامل مع إعادة البيع، فاستخدم خيار الإحالة بدلًا من ذلك: في الشريط الجانبي لـ Business Console افتح الإحالات، واقبل شروط البرنامج، وشارك رابطك. تكسب عمولة 10% على كل إيداع نقدي تقوم به مؤسسة محالة، لمدة 36 شهرًا من أول إيداع لها، قابلة للاستخدام كرصيد Didit أو للسحب بتحويل مصرفي بعد فترة النضج، دون أي التزامات تسليم أو دعم. يمكنك بناء تكاملك واختباره في الباقة المجانية قبل الالتزام بأي من الخيارين.
#حذف تطبيق
حذف تطبيق يزيل سير العمل الخاص به وتهيئته. بيانات التحقق الخاصة به تتبع سياسة الاحتفاظ وقواعد الحذف الخاصة بتلك البيانات، لا دورة حياة التطبيق - لذا إذا كان هدفك محو بيانات العملاء، احذف البيانات صراحةً بدلًا من افتراض أن إزالة التطبيق تفعل ذلك. راجع حذف الجلسات والبيانات الشخصية.
#كل شيء قابل للإسناد
كل طلب API يسجّل التطبيق الذي ينتمي إليه، في سجل التدقيق، لمدة 365 يومًا. هذا ما يجعل هيكل التطبيقات المتعددة قابلاً للتدقيق لا مجرد هيكل مرتب. راجع استخدام سجلات التدقيق.