Skip to main content

​
الميزات الجديدة

​
1. أكواد الخصم: خصومات المبالغ والجدولة وقواعد الأهلية

لم تعد أكواد الخصم مقتصرة على النسب المئوية. يمكنك الآن استخدام الكود لخصم مبلغ ثابت، وبدء صلاحيته وفق جدول زمني، وتحديد سعر مختلف لكل عملة، وتقييد الأشخاص المسموح لهم باسترداده. خصومات المبالغ عيّن type إلى flat لخصم مبلغ ثابت بدلًا من نسبة مئوية. يُجمع الخصم على مستوى سلة التسوق بالكامل بدلًا من تطبيقه على كل بند.
محرر أكواد الخصم مع تحديد نوع Amount، ويعرض خصمًا ثابتًا قدره 500 INR
الخيارات لكل عملة يتيح currency_options لكود واحد العمل بشكل صحيح عبر كل عملة تبيع بها. يحدد كل إدخال، لعملة واحدة، الحد الأقصى للخصم (الخصم نفسه لكود Amount، والحد الأقصى لكود Percentage) والحد الأدنى لقيمة السلة. يتطلب خصم Amount خيارًا واحدًا على الأقل لعملة تتضمن قيمة افتراضية قابلة للتحديد؛ بينما تظل خيارات العملات اختيارية لخصومات Percentage. أهلية العملاء يتحكم customer_eligibility في الأشخاص الذين يمكنهم استرداد الكود:
قائمة منسدلة لأهلية العملاء تعرض خيارات Any وFirst-time وExisting وSpecific customer
يمكنك إدارة قائمة السماح من لوحة التحكم، أو باستخدام نقاط النهاية الجديدة: GET /discounts/{discount_id}/customers لعرض العملاء المرفقين، وPOST /discounts/{discount_id}/customers لإرفاقهم، وDELETE /discounts/{discount_id}/customers/{customer_id} لفصل أحدهم.
يبدأ كود specific بوجود صفر من العملاء المؤهلين، ويرفض كل عمليات الاسترداد حتى تُرفق العملاء به.
الجدولة والحدود لكل عميل عيّن starts_at لجدولة إطلاق الكود في المستقبل — ويؤدي تركه دون تعيين إلى إبقاء الكود نشطًا فورًا، كما يجب أن يسبق expires_at بشكل صارم. استخدم per_customer_usage_limit لتحديد عدد مرات استرداد العميل الواحد للكود، كحد منفصل لا يمكن أن يتجاوز usage_limit الإجمالي.
تُقاس قيمة السلة الدنيا دائمًا استنادًا إلى الأسعار الأصلية للسلع في السلة، وليس إلى الإجمالي الجاري في منتصف تطبيق مجموعة الخصومات. لذلك لا يغيّر ترتيب تطبيق الخصومات ما إذا كان الحد الأدنى مستوفى.
تعرّف على المزيد: الخصومات | إنشاء خصم

​
2. تجربة Webhooks مُعاد بناؤها

أُعيد بناء قسم webhooks في لوحة التحكم كتجربة native، لتحل محل البوابة المضمّنة. يوجد كل شيء الآن داخل لوحة التحكم، مع جداول ومرشحات وتنقل متناسق، ويعمل بشكل صحيح على الأجهزة المحمولة.
  • نقاط النهاية — أنشئ نقاط النهاية وعدّلها في لوحة جانبية، واختر أنواع الأحداث من شجرة قابلة للبحث، واطّلع سريعًا على معدل الأخطاء خلال آخر 24 ساعة.
  • النشاط والسجلات — راقب محاولات التسليم بمرور الوقت في مخطط نشاط التسليم، وتصفح الرسائل التي تم تسليمها، وافتح صفحة تفاصيل الرسالة لفحص الحمولة وكل محاولات التسليم مع رمز الاستجابة ومدتها. ويمكن إعادة تشغيل كل محاولة من هناك.
  • كتالوج الأحداث — تصفح كل أنواع الأحداث التي يرسلها Dodo Payments، مع مخططها وحمولة نموذجية.
  • نظرة عامة على نقطة النهاية — إحصاءات التسليم لآخر 24 ساعة، وsecret التوقيع لعرضه أو تدويره، وسجل إعادة التشغيل.
  • الاختبار — أرسل حدثًا نموذجيًا إلى نقطة نهاية للتحقق من المستقبِل قبل بدء العمل الفعلي.
  • متقدم — حدّد معدل التسليم، وأدر الرؤوس المخصصة المُرسلة مع كل طلب إلى نقطة النهاية، وعدّل التحويل الخاص بها.
  • إعادة التشغيل الجماعية — استعد الرسائل الفاشلة، أو أعد تشغيل الرسائل التي لم تُرسل قط، أو أعد تشغيل نطاق تمت تصفيته من نقطة النهاية.
  • التنبيهات عبر البريد الإلكتروني — علامة تبويب الإعدادات الجديدة التي تتيح لك إدراج العناوين التي يجب إرسال بريد إلكتروني إليها عند بدء فشل عمليات التسليم إلى نقطة نهاية. افصل بين العناوين المتعددة بفواصل، واترك الحقل فارغًا لإيقاف التنبيهات.
هذا تغيير في لوحة التحكم فقط. لم تتغير نقاط النهاية الحالية، أو أسرار التوقيع، أو التحقق من التوقيع، أو أسماء الأحداث، أو الحمولات — ولا يلزم إجراء أي تغييرات على التكامل.
تعرّف على المزيد: Webhooks | أحداث Webhook

​
3. Cash App Pay للاشتراكات

يمكن الآن استخدام Cash App Pay لدعم اشتراك متكرر، وليس دفعة واحدة فقط. وهو متاح في عمليات الدفع الأمريكية المحاسبة بالدولار الأمريكي، إلى جانب خيارات البطاقات الحالية. تعرّف على المزيد: المحافظ الرقمية

​
4. SEPA Direct Debit

أصبح SEPA Direct Debit متاحًا الآن في جميع أنحاء منطقة اليورو، ما يتيح للعملاء الدفع مباشرة من حساباتهم المصرفية بدلًا من استخدام بطاقة. وهو متاح في عمليات الدفع باليورو للدفعات لمرة واحدة.
إن SEPA Direct Debit ليس فوريًا. يستغرق تأكيد الدفعة 6 أيام عمل، لذا لا تتعامل مع التفويض باعتباره تسوية — لا تنفّذ الطلب إلا بعد وصول الدفعة إلى حالة succeeded.
تعرّف على المزيد: طرق الدفع الأوروبية

​
5. رسائل أوضح لفشل الدفع

عند فشل دفعة، ستظهر لك ولعميلك الآن صياغة مخصصة بدلًا من نص المعالج الخام. يُصنّف كل فشل من خلال 46 رمز خطأ موحدًا، وكل رمز مرتبط بجمهورين:
  • أنت ترى عنوانًا وإجراءً موصى بهما في الدفعة، لتعرف ما إذا كان ينبغي مطالبة العميل بإعادة المحاولة، أو التواصل مع بنكه، أو استخدام بطاقة أخرى. يحمل error_message في كائن Payment هذه الصياغة الآن كلما كان error_code رمزًا موحدًا معروفًا.
  • عميلك يرى شرحًا بلغة واضحة على شاشة فشل الدفع في checkout، وفي Customer Portal، وفي رسائل البريد الإلكتروني الخاصة بمتابعة التحصيل — على سبيل المثال، “لا يبدو أن رمز أمان بطاقتك (CVC) صحيح. يُرجى إعادة إدخاله والمحاولة مرة أخرى.”
بالنسبة إلى حالات الرفض الحساسة للاحتيال — FRAUDULENT وLOST_CARD وSTOLEN_CARD وPICKUP_CARD — يرى العميل دائمًا رسالة عامة حتى لا يُكشف السبب الحقيقي. بينما ترى أنت السبب الفعلي، مع تحذير بعدم مشاركته.
تعرّف على المزيد: فشل المعاملات | الدفعات | الحصول على تفاصيل الدفعة

​
6. السماح للعملاء بإلغاء اشتراكاتهم بأنفسهم

أصبح إعداد السماح بإلغاء الاشتراك إعدادًا أساسيًا ضمن علامة تبويب الاشتراكات في إعدادات لوحة التحكم، ويتم تطبيقه من البداية إلى النهاية. عند إيقافه، يعطّل Customer Portal زر الإلغاء، وترفض API الإلغاء الذي يبدأه العميل باستخدام 403 — سواء الإلغاء الفوري أو مسار “الإلغاء في تاريخ الفوترة التالي”. في السابق، كان الإعداد يخفي الزر فقط، لذلك كان بإمكان عميل مصمم على الإلغاء الاستمرار في ذلك عبر API. يكون الإعداد مفعّلًا افتراضيًا. لا تتأثر عمليات الإلغاء التي تجريها أنت عبر merchant API ولوحة التحكم، ويمكن للعميل دائمًا التراجع عن إلغاء سبق أن جدولَه. تعرّف على المزيد: Customer Portal | الاشتراكات

​
7. Webhooks للدفعات

ستتلقى الآن webhooks لدفعاتك الخاصة، ما يتيح لك مطابقتها في أنظمة المحاسبة لديك دون إجراء استعلامات دورية.
كان يتم إصدار payout.created سابقًا باسم payout.not_initiated. إذا كانت نقطة نهاية حالية تصفي النتائج باستخدام payout.not_initiated، فحدّث المرشح إلى payout.created ليواصل المطابقة. يظل الحقل status في الحمولة يبلّغ عن not_initiated في هذه المرحلة.
تعرّف على المزيد: Webhooks للدفعات | آلية الدفعات

​
8. تغيير بريد تسجيل الدخول من لوحة التحكم

يمكنك الآن تغيير عنوان البريد الإلكتروني الذي تسجّل الدخول به دون التواصل مع الدعم. أُعيد تصميم علامة تبويب الحساب، وتتضمن قسمًا جديدًا باسم تغيير البريد الإلكتروني، مع زر تغيير البريد الإلكتروني لبدء العملية. تتم عملية التحقق على خطوتين: نرسل رمزًا إلى عنوانك الحالي للتأكد من هويتك، ثم رمزًا ثانيًا إلى عنوانك الجديد للتأكد من أنك تملك حق الوصول إليه. بعد التحقق من كليهما:
  • تسجّل الدخول بالعنوان الجديد من الآن فصاعدًا. ويتوقف العنوان السابق عن العمل مع كلمات المرور، وروابط magic links، والرموز المُرسلة عبر البريد الإلكتروني.
  • تُفصل أي موفّرات هوية مرتبطة، مثل تسجيل الدخول باستخدام Google أو GitHub، ويجب إعادة ربطها.
  • تظل كلمة المرور، والأنشطة التجارية، والوصول إلى الفريق، وحالة التحقق دون تغيير.
  • يُرسل إشعار إلى عنوانك السابق حتى لا يمر أي تغيير غير متوقع دون تنبيه.
تعرّف على المزيد: حسابي

​
9. التحليلات: عناصر واجهة جديدة وتحسينات

استنادًا إلى إعادة بناء Analytics v3، يضيف هذا الإصدار تصورات جديدة ويحسّن التصورات الحالية.
  • أصبحت الإيرادات حسب البلد الآن خريطة choropleth بعرض كامل، مع قائمة البلدان المرتبة بجانبها، ويمكن مشاركة البطاقة مثل بقية البطاقات.
  • مخططات الاتجاهات أعيد رسمها مع مؤشر تقاطع عند التمرير، وشارة تاريخ متحركة على المحور x، وتلميح أدوات مدمج.
  • إعدادات تاريخ جديدة مسبقة — يحل آخر 30 يومًا محل آخر 4 أسابيع، وينضم آخر 6 أشهر إلى القائمة.
  • تظل مرشحاتك محفوظة. يستمر الآن إعداد التاريخ المسبق ووضع المقارنة لكل نشاط تجاري، ويتبعانك عبر الأجهزة بدلًا من إعادة ضبطهما إلى الإعدادات الافتراضية في كل جلسة.
  • يُحدَّد العملاء الأعلى إنفاقًا بالاسم، مع الرجوع إلى البريد الإلكتروني عند الحاجة.
  • تعرض الإيرادات حسب البلد الآن ما يصل إلى أفضل 150 بلدًا.
تعرّف على المزيد: تحليلات لوحة التحكم

​
التحسينات وإصلاحات الأخطاء

​
10. تصفية الدفعات حسب العملة

يقبل GET /payments الآن query parameter اختياريًا باسم currency، ما يتيح لك عرض الدفعات التي تمت تسويتها بعملة محددة فقط — مثل GET /payments?currency=EUR. ويتوفر المرشح نفسه في جدول Payments في لوحة التحكم. تعرّف على المزيد: قائمة الدفعات

​
11. تمديد مهلة الرد على النزاع إلى 10 أيام

لديك الآن 10 أيام للرد على النزاع بعد إنشائه، بدلًا من 4 أيام. يعكس العد التنازلي للنزاع في لوحة التحكم، والموعد النهائي للرد الذي تُعيده API، المهلة الأطول. تعرّف على المزيد: النزاعات

​
12. نماذج أوضح للحساب المصرفي الخاص بالدفعات

أصبحت إضافة حساب مصرفي للدفعات أقل التباسًا. تتكيف تسميات الحقول والأوصاف والتلميحات مع نوع نشاطك التجاري، لذلك لا يعود اسم صاحب الحساب واسم المستفيد يبدوان متطابقين لأصحاب الأعمال الفردية. يتيح لك اختيار أخرى كبنك كتابة الاسم بحرية، ويُسمّى رمز البنك المحلي في الصين CNAPS، وتظل صفحة الدفعات ظاهرة في test mode حتى تتمكن من الوصول إلى حساباتك المرتبطة من أي من الوضعين. تعرّف على المزيد: آلية الدفعات

​
إصلاحات وتحسينات أخرى

  • تُعكس أرصدة تغيير الخطة عند فشل الدفعة. لم تعد أرصدة التوزيع النسبي الصادرة أثناء تغيير خطة الاشتراك تُترك عند فشل الدفعة الناتجة.
  • تعرض فواتير التجارب المدفوعة رسوم التجربة بدلًا من السعر المتكرر المعتاد.
  • تحترم الخصومات المئوية الحد الأدنى لقيمة السلة، الذي يُقاس مقابل السعر الأساسي بدلًا من الإجمالي الجاري، كما يعيد انتهاء مهلة قفل الخصم الآن رمز خطأ مميزًا بدلًا من 503 العام.
  • ينجح حذف طريقة دفع أُزيلت بالفعل بدلًا من إرجاع خطأ، ما يجعل الاستدعاء idempotent بأمان.
  • تم إصلاح العملة المستخدمة للحد الأدنى لتفويض الهند عند تحديث طريقة دفع الاشتراك.
  • تُرفض قيود إدخالات دفتر الائتمان التي تتجاوز الحدود المسموح بها باستخدام 400 typed بدلًا من الفشل لاحقًا.
  • تدعم منتجات ادفع ما تريد مبلغًا ثابتًا في روابط checkout المشتركة، كما تظهر معرّفات الاستحقاق في لوحة تفاصيل الاستحقاق.
  • إصلاحات Analytics: سلاسل القيمة طوال فترة العميل، وإدراج الإضافات في MRR، وعدم إجراء مقارنة بالفترة في النطاقات الشاملة لكل الوقت، والسلاسل التي تتوقف عند المجموعة الحالية، وتسميات أوضح للنطاق والمقارنة.
  • إصلاحات طفيفة للأخطاء وتحسينات في الاستقرار عبر المنصة.
آخر تعديل في ٨ أغسطس ٢٠٢٦