Skip to main content

Quick Start

شغّل تكامل الدفع عبر الأجهزة المحمولة في 4 خطوات بسيطة

Platform Examples

أمثلة برمجية مكتملة لنظم Android وiOS وReact Native وFlutter

Checkout Customization

اضبط السمات والملء المسبق و14 معلَمة خاصة بالأجهزة المحمولة

Mobile Recipes

إعدادات دفع جاهزة للنسخ واللصق لـ5 سيناريوهات شائعة على الأجهزة المحمولة
يوفّر Dodo Payments حزمة SDK رسمية لصفحة الدفع لأنظمة Android وiOS وReact Native وFlutter. تغلّف كل حزمة النمط الموثّق أدناه (فتح عنوان URL لصفحة الدفع والتقاط الاستجابة وتحليل النتيجة) خلف استدعاء start(...) واحد ومكتوب النوع، مع توفير استرداد الجلسات المتروكة مضمّنًا. استخدم WebView يدويًا فقط إذا لم تناسبك أيٌّ من هذه الحزم.

المتطلبات الأساسية

قبل دمج Dodo Payments في تطبيقك المحمول، تأكد من توفر ما يلي:
  • حساب Dodo Payments: حساب تاجر نشط مع إمكانية الوصول إلى API
  • بيانات اعتماد API: مفتاح API ومفتاح سرّي لـ webhook من لوحة التحكم
  • مشروع تطبيق محمول: تطبيق Android أو iOS أو React Native أو Flutter
  • خادم خلفي: لمعالجة إنشاء جلسات الدفع بأمان

سير عمل التكامل

يتبع التكامل عبر الأجهزة المحمولة عملية آمنة من 4 خطوات، يتولى فيها خادمك الخلفي استدعاءات API ويدير تطبيقك المحمول تجربة المستخدم.
إن عنوان URL للرابط العميق status ليس سوى إشارة إلى واجهة المستخدم لما ينبغي عرضه للمستخدم. امنح إمكانية الوصول دائمًا من خلال payment.succeeded / subscription.active webhook على خادمك الخلفي، وليس من نتيجة الجهاز المحمول وحدها.
1

Backend: Create Checkout Session

Checkout Session API Docs

تعرّف على كيفية إنشاء جلسة دفع في خادمك الخلفي باستخدام Node.js وPython وغيرهما. راجع الأمثلة الكاملة ومراجع المعلَمات في توثيق Checkout Sessions API المخصّص.
الأمان: يجب إنشاء جلسات الدفع على خادمك الخلفي، وليس داخل التطبيق المحمول. يحمي ذلك مفاتيح API ويضمن إجراء التحقق المناسب.
2

Mobile: Get Checkout URL

يستدعي تطبيقك المحمول خادمك الخلفي للحصول على عنوان URL لصفحة الدفع. صادِق على هذا الطلب باستخدام رمز جلسة المستخدم الذي سجّل دخوله.
الأمان: تتواصل التطبيقات المحمولة مع خادمك الخلفي فقط، ولا تتواصل مباشرةً مع Dodo Payments API.
3

Mobile: Open Checkout in Browser

افتح عنوان URL لصفحة الدفع في متصفح آمن داخل التطبيق لمعالجة الدفع. أو تجاوز الإعداد اليدوي بالكامل باستخدام حزمة SDK الرسمية لمنصتك.

Pick your mobile SDK

خطوات التثبيت وإرشادات الإعداد لأنظمة Android وiOS وReact Native وFlutter.
4

Backend: Handle Payment Completion

عالج اكتمال الدفع عبر webhooks وعناوين URL لإعادة التوجيه لتأكيد حالة الدفع.

اختر حزمة SDK

توفّر كل حزمة SDK للأجهزة المحمولة العقد نفسه: إذ يفتح استدعاء start(...) واحد صفحة الدفع المستضافة من Dodo في سطح المتصفح الأصلي للمنصة، ويعيد CheckoutResult مكتوب النوع، تكون قيمة status فيه succeeded أو failed أو cancelled أو pending أو expired. لا تحتوي أيٌّ منها على مفتاح API أو تستدعي Dodo Payments API، وتدعم الحزم الأربع استرداد الجلسات المتروكة.

Android

يفتح com.dodopayments.api:checkout-android علامة تبويب Chrome مخصّصة. يتطلب minSdk 23.

iOS

يفتح dodopayments-mobile-sdk-iosSFSafariViewController. يتطلب iOS 16 أو أحدث.

React Native

@dodopayments/react-native-checkout، وهي Turbo Module فوق النواتين الأصليتين. تتطلب React Native 0.76 أو أحدث.

Flutter

dodopayments_checkout، وهي قناة Pigeon فوق النواتين الأصليتين. تتطلب Flutter 3.44 أو أحدث.
إن status الذي تستلمه هو إشارة إلى واجهة المستخدم، وليس دليلًا على الدفع. أكّد كل عملية دفع من خادمك الخلفي عبر webhook‏ payment.succeeded / subscription.active، أو باسترداد الدفع باستخدام مفتاحك السرّي.

تسجيل مخطط عنوان URL لاستدعاء الإرجاع

تعيد حزم SDK الأربع التحكم إلى تطبيقك من خلال مخطط عنوان URL مخصّص تختاره، مثل myapp://checkout/return. سجّله مرة واحدة لكل منصة:
android/app/build.gradle
يعلن manifest الخاص بحزمة SDK عن نشاط إعادة التوجيه مسبقًا، لذلك لا يلزم إضافة XML إلى manifest.
هل تفضّل بناؤه بنفسك؟ افتح checkout_url في متصفح النظام للمنصة (Android Custom Tabs / iOS‏ SFSafariViewController)، واعترض عملية التنقل إلى return_url، ثم اقرأ معلَمتي الاستعلام status وpayment_id. تنفّذ حزم SDK أعلاه هذه الخطوات نيابةً عنك.
لا تفتح صفحة الدفع داخل WebView مضمّن (WKWebView / Android‏ WebView). هذه أكثر مشكلات تكامل الأجهزة المحمولة شيوعًا؛ إذ يعمل WebView المضمّن على تعطيل Apple Pay وGoogle Pay، وقد يتسبب أيضًا في تعطل تحديات 3-D Secure والملء التلقائي للبطاقات المحفوظة، ما يؤدي إلى ظهور خيارات دفع أقل وفشل عمليات أكثر للعملاء. استخدم حزمة SDK دائمًا، أو افتح checkout_url في متصفح النظام (Custom Tabs / SFSafariViewController). سطح المتصفح الأصلي هذا هو سبب استمرار عمل Apple Pay وGoogle Pay.

تخصيص المظهر

تقبل كل حزمة SDK معلَمة customization اختيارية في start(...) / CheckoutParams، وتتحكم هذه المعلَمة في مظهر سطح المتصفح الأصلي وسلوكه، مثل شريط الأدوات والأزرار وطريقة العرض. وهذا منفصل عن سمة صفحة الدفع نفسها، التي تضبطها من جهة الخادم عبر customization.theme_config في جلسة الدفع. تُجمّع الخيارات حسب المنصة لأن Custom Tab في Android وSFSafariViewController في iOS يوفّران عناصر تحكم أصلية مختلفة. جميع الحقول اختيارية؛ ويؤدي حذف customization بالكامل إلى استخدام المظهر الافتراضي لكل منصة.
Color
لون خلفية شريط الأدوات.
Color
لون شريط التنقل.
Color
لون الفاصل أعلى شريط التنقل.
'default' | 'back'
يعرض default رمز النظام “X”؛ بينما يرسم back سهم رجوع بدلًا منه.
'start' | 'end'
يحدد الجانب الذي يظهر فيه زر الإغلاق على شريط الأدوات.
boolean
يعرض رمز المشاركة في شريط الأدوات.
boolean
يعرض عنوان الصفحة أسفل عنوان URL في شريط الأدوات.
boolean
يتيح لشريط الأدوات الاختفاء تلقائيًا أثناء تمرير الصفحة.
boolean
يعرض “وضع علامة مرجعية على هذه الصفحة” في قائمة المزيد.
boolean
يعرض “تنزيل الصفحة” في قائمة المزيد.
'system' | 'light' | 'dark'
يفرض المظهر الفاتح أو الداكن بغض النظر عن إعداد النظام في الجهاز.
'done' | 'close' | 'cancel'
تسمية زر الإغلاق أو رمزه.
'pageSheet' | 'fullScreen'
يظهر pageSheet كبطاقة يمكن إغلاقها بالسحب؛ بينما يغطي fullScreen الشاشة بأكملها.
boolean
يتيح طيّ شريط الأدوات أثناء التمرير. يظهر فقط عندما تكون قيمة presentationStyle هي fullScreen؛ أما pageSheet فيبقي الأشرطة مثبتة بغض النظر عن هذا الإعداد.
'system' | 'light' | 'dark'
يفرض المظهر الفاتح أو الداكن بغض النظر عن إعداد النظام في الجهاز.

تخصيص صفحة الدفع

يتحكم قسم تخصيص المظهر أعلاه في سطح المتصفح الأصلي، بما يشمل شريط الأدوات والأزرار ونظام الألوان. أما صفحة الدفع نفسها، أي الحقول الظاهرة والسمة وطرق الدفع المعروضة، فتُضبط من جهة الخادم عند إنشاء جلسة الدفع. ولهذه المعلَمات أكبر تأثير في التحويل عبر الأجهزة المحمولة. توجد المعلَمات أدناه في ثلاثة مواضع مختلفة ضمن طلب جلسة الدفع؛ ويحدد عمود موضعها الكائن الذي تنتمي إليه كل معلَمة. ويُعد وضع المعلَمة في الكائن الخطأ أكثر الأخطاء شيوعًا، إذ يتم تجاهلها بصمت.
مرّر دائمًا billing_currency وbilling_address.country معًا. إذا حُذفت إحداهما، فقد تغيّر Adaptive Currency عملة الفوترة بصمت استنادًا إلى عنوان IP الخاص بالعميل. لاحظ أحد التجار تبدّل اشتراك أمريكي إلى EUR عندما سافر العميل إلى أوروبا، لأن بلد الفوترة لم يُحدّد صراحةً.
أكبر تحسين منفرد للتحويل على الأجهزة المحمولة: اضبط show_order_details: false وminimal_address: true. فنقل طرق الدفع إلى الجزء الظاهر من الشاشة وتقليل حقول النموذج هما التغييران الأعلى تأثيرًا.
مقارنة بين صفحتي دفع: تفاصيل الطلب موسّعة (الحقول أسفل الجزء الظاهر) ومطوية (الحقول في الأعلى)

show_order_details: false moves the contact and payment fields above the fold, instead of behind the order summary.

اضبط minimal_address: true لجمع الرمز البريدي فقط بدلًا من حقول الشارع والمدينة والولاية كاملةً:
مقارنة بين صفحتي دفع: نموذج عنوان فوترة كامل ونموذج يطلب الرمز البريدي فقط

minimal_address: true reduces the billing address to a single postcode field.

اضبط theme: "system" لكي تتبع صفحة الدفع تفضيل الجهاز للوضع الفاتح أو الداكن:
مقارنة بين صفحتي دفع: الصفحة نفسها معروضة في الوضع الفاتح والوضع الداكن

With theme: system, the checkout follows the device's light or dark appearance automatically.

يختلف توفر طرق الدفع حسب نوع المنتج. تتوفر Apple Pay وCash App للاشتراكات المتكررة غير الصفرية. أما المدفوعات لمرة واحدة فتتوفر لها جميع الطرق المفعّلة.

Full checkout session parameter reference

راجع كل معلَمة متاحة ونوعها وقيمتها الافتراضية في دليل Checkout Sessions.

وصفات محسّنة للأجهزة المحمولة

كل وصفة أدناه هي نص طلب كامل لإنشاء جلسة دفع. انسخ الوصفة المطابقة لسيناريوك، واستبدل معرّف المنتج، ثم مرّرها إلى نقطة النهاية الخاصة بإنشاء الجلسة في خادمك الخلفي.
استخدم هذه الوصفة عندما تريد أقصر نموذج ممكن: طرق الدفع في الأعلى، والرمز البريدي فقط مطلوب للعنوان، ومن دون حقل للخصم، مع مطابقة السمة لوضع الجهاز.
راجع Checkout Sessions للاطلاع على جميع المعلَمات المتاحة وقيمها الافتراضية.
استخدم هذه الوصفة عندما يجب أن تبدو صفحة الدفع جزءًا من تطبيقك. اضبط ألوان علامتك التجارية وخطًا مخصّصًا وتسمية مترجمة لزر الدفع.
صفحة دفع محمولة تحمل العلامة التجارية مع تطبيق لوحة ألوان كحلية داكنة مخصّصة عبر theme_config
يقبل theme_config كائنَي dark وlight منفصلين، كي تتكيف لوحة الألوان مع المظهر الحالي للجهاز. راجع Checkout Sessions للاطلاع على المرجع الكامل لمفاتيح الألوان.
استخدم هذه الوصفة للمستخدمين المسجّلين الذين سبق لهم الدفع. اجمع بين معرّف العميل وطريقة الدفع المحفوظة الخاصة به وconfirm: true لتجاوز نموذج الدفع بالكامل.
إن status في استجابة الرابط العميق ليس سوى إشارة إلى واجهة المستخدم. أكّد منح الوصول من خلال الاستماع إلى webhook‏ payment.succeeded على خادمك الخلفي.
استخدم هذه الوصفة لمنتجات الاشتراك التي توفر فترة تجريبية مجانية قبل دورة الفوترة الأولى.
امنح الوصول إلى الميزة عندما يتلقى خادمك الخلفي webhook‏ subscription.active، وليس عند إرجاع SDK المحمول للنتيجة. راجع دليل تكامل الاشتراكات للاطلاع على تدفق webhook الكامل.
استخدم هذه الوصفة لترميز بطاقة العميل لاستخدامها في عمليات خصم لاحقة (شحن المحافظ والدفع حسب الاستخدام وBNPL) من دون عرض تسمية “اشتراك”. يفوّض العميل طريقة الدفع مرة واحدة، ثم تخصم مبالغ متغيرة عند الطلب لاحقًا.
هذا هو النمط المستخدم في التطبيقات التي تفرض رسومًا بناءً على الاستخدام، مثل تطبيق فلك يفرض رسومًا لكل جلسة من بطاقة مصرّح بها مسبقًا، بدلًا من جدول ثابت.
تتطلب الرسوم عند الطلب حدًا أدنى قدره 1 USD (100 سنتًا). وسيتم رفض المبالغ الأقل من 1 USD مع "value out of range". ولتفويض بقيمة صفرية، استخدم mandate_only: true كما هو موضح أعلاه، ثم اخصم 1 USD على الأقل في الاستدعاءات اللاحقة.
راجع الاشتراكات عند الطلب للاطلاع على تدفق الخصم الكامل وأحداث webhook وسياسات إعادة المحاولة.

تدفقات الاشتراك من الأجهزة المحمولة

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

الاشتراكات المتكررة العادية

للفوترة على فترات ثابتة (شهرية أو سنوية)، أنشئ جلسة دفع باستخدام منتج اشتراك ورابط عميق return_url. سيتلقى خادمك الخلفي subscription.active عند تأكيد الاشتراك.
تتوفر Apple Pay وCash App للاشتراكات المتكررة غير الصفرية.
للاطلاع على تدفق webhook الكامل في الخادم الخلفي، راجع دليل تكامل الاشتراكات.

الاشتراكات عند الطلب

تتيح الاشتراكات عند الطلب تفويض طريقة دفع العميل مرة واحدة وخصم مبالغ متغيرة لاحقًا، وهي مثالية لشحن المحافظ والدفع حسب الاستخدام وأي سيناريو لا يكون فيه مبلغ الخصم معلومًا مسبقًا. راجع وصفة On-Demand Mandate أعلاه لنص الطلب الكامل. اعتبارات مهمة للأجهزة المحمولة:
  • اضبط show_on_demand_tag: false كي لا تعرض صفحة الدفع لغة “اشتراك” أو “عند الطلب”. ففي حالات استخدام ترميز البطاقة، لا يتوقع العملاء مصطلحات الاشتراك.
  • بعد تفويض التفويض، سيتلقى خادمك الخلفي subscription.active. خزّن subscription_id، إذ ستستخدمه في جميع عمليات الخصم المستقبلية.
الحد الأدنى للخصم هو 1 USD (100 سنت). وسيتم رفض الرسوم عند الطلب التي تقل عن 1 USD مع "value out of range". إما أن تخصم 1 USD على الأقل، أو تستخدم mandate_only: true للتفويض من دون خصم، ثم تجمع المبلغ الفعلي الأول لاحقًا.
تجنب عمليات إعادة المحاولة المتتالية بسرعة. إذا كانت عملية خصم سابقة لا تزال قيد المعالجة، فسيفشل الخصم الجديد على الاشتراك نفسه مع "Cannot create new charge as previous payment is not successful yet". ويشيع ذلك خصوصًا مع وسائل الدفع الهندية (UPI وبطاقات الخصم/الائتمان الهندية)، حيث قد تُبقي قواعد تفويض RBI المعاملة قيد المعالجة لمدة تصل إلى 48 ساعة. أضف فحصًا لفترة انتظار في منطق الخصم قبل إعادة المحاولة.
راجع الاشتراكات عند الطلب للاطلاع على نقطة نهاية الخصم الكاملة وأحداث webhook وسياسات إعادة المحاولة.

اشتراك مع فترة تجريبية مجانية

مرّر subscription_data.trial_period_days في جلسة الدفع لتقديم فترة تجريبية قبل دورة الفوترة الأولى. ويفوّض العميل طريقة الدفع أثناء التسجيل في الفترة التجريبية؛ ويحدث الخصم الأول تلقائيًا عند انتهائها. راجع وصفة Subscription with Free Trial أعلاه لنص الطلب الكامل.

الترقية وخفض الخطة

تُجرى تغييرات الخطة عبر API على خادمك الخلفي، وليس من خلال جلسة دفع جديدة. يحسب Dodo Payments التقسيم النسبي تلقائيًا. لتوفير خيار الخدمة الذاتية للعملاء، ضمّن Customer Portal أو أضف رابطًا إليه.

Subscription Integration Guide

إعداد الخادم الخلفي الكامل: تدفق webhook وتوفير الوصول والإلغاء

On-Demand Subscriptions

تفويض التفويض والمبالغ المتغيرة وسياسات إعادة المحاولة

Upgrade / Downgrade

استراتيجيات التقسيم النسبي وتغييرات الخطة وتعديلات المقاعد

Customer Portal

إدارة الاشتراكات بالخدمة الذاتية لعملائك

تقليل التخلّي عن صفحة الدفع

تشهد صفحات الدفع على الأجهزة المحمولة معدلات تخلٍّ أعلى من الويب؛ فالشاشات الأصغر والمشتتات الكثيرة والنماذج الأطول تسهم جميعًا في ذلك. وتأتي أسرع التحسينات من إعدادات جلسة الدفع نفسها.

تحسين النموذج

الملء المسبق لبيانات العميل

كل حقل لا يضطر العميل إلى كتابته يمثل سببًا إضافيًا لعدم تخلّيه عن العملية:
  • العملاء الجدد: اضبط customer.email وcustomer.name من جلسة المصادقة لديك.
  • العملاء العائدون: اضبط customer.customer_id لملء جميع التفاصيل المخزنة تلقائيًا.
  • العملة: مرّر دائمًا billing_currency وbilling_address.country معًا.

أدوات الاسترداد

Abandoned Cart Recovery

تسلسلات بريد إلكتروني تلقائية لعمليات الدفع غير المكتملة

Payment Retries

منطق إعادة محاولة ذكي لتجديدات الاشتراكات الفاشلة

Subscription Dunning

رسائل بريد إلكتروني لإعادة إشراك الاشتراكات المنتهية

Recovery Overview

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

أفضل الممارسات

  • الأمان: لا تضع مفتاح API في تطبيقك أبدًا. أنشئ جلسات الدفع على خادمك الخلفي ومرّر إلى العميل checkout_url الناتج فقط.
  • المرجعية: تعامل مع CheckoutResult.status على أنه إشارة إلى واجهة المستخدم. امنح الوصول فقط بعد تأكيد خادمك الخلفي للدفع.
  • تجربة المستخدم: اعرض حالة تحميل أثناء إنشاء خادمك الخلفي للجلسة، وتعامل مع cancelled كنتيجة عادية وليس كخطأ.
  • الاختبار: استخدم وضع الاختبار وبطاقات الاختبار، وتحقق من دورة عنوان URL للإرجاع على جهاز حقيقي وكذلك على محاكي.
  • التحويل: اضبط show_order_details: false وminimal_address: true لتحقيق أفضل معدلات إكمال الدفع على الأجهزة المحمولة. فنقل طرق الدفع إلى الجزء الظاهر وتقليل حقول النموذج هما التغييران الأعلى تأثيرًا.
  • العملة: مرّر دائمًا billing_currency وbilling_address.country صراحةً؛ فإذا غاب أحدهما، فقد تغيّر Adaptive Currency عملة الفوترة استنادًا إلى عنوان IP الخاص بالعميل.
  • الفوترة عند الطلب: اضبط show_on_demand_tag: false عند استخدام الاشتراكات عند الطلب لترميز البطاقة. لا يتوقع العملاء الذين يستخدمون تدفق شحن المحفظة رؤية لغة “اشتراك”.
  • الاسترداد: فعّل استرداد سلة التسوق المتروكة في لوحة تحكم Dodo Payments لإعادة إشراك العملاء الذين لا يكملون الدفع تلقائيًا.

استكشاف الأخطاء وإصلاحها

المشكلات الشائعة

  • لا يصل الاستدعاء: يجب أن يطابق المخطط في returnUrl المخطط الذي سجلته. في Android يكون ذلك العنصر النائب في manifest‏ dodoCallbackScheme؛ وفي iOS وReact Native يكون نوع عنوان URL‏ Info.plist.
  • تعود صفحة الدفع إلى المتصفح بدلًا من تطبيقك (iOS): لم تمرّر عنوان URL الوارد. استدعِ DodoCheckout.handleOpenURL(url) من .onOpenURL أو scene(_:openURLContexts:) أو مستمع Linking في React Native.
  • PLATFORM_ERROR في Android: غالبًا ما يكون السبب عدم تطابق المخطط. وقد يظهر أيضًا إذا ضبط MainActivity قيمة android:taskAffinity="" (القيمة الافتراضية القياسية flutter create)، ما يسمح لبعض إصدارات OEM بفقدان جلسة الدفع الجارية.
  • ALREADY_IN_PROGRESS: لا تزال هناك عملية دفع مفتوحة. انتظر العملية السابقة أو أغلقها قبل بدء أخرى.
  • يفشل البناء بسبب عنصر نائب لم يتم حله: أضفت Android SDK لكنك لم تضبط manifestPlaceholders["dodoCallbackScheme"].
  • نجح الدفع لكن لم يُمنح الوصول: هذا متوقع إذا كنت تعتمد على نتيجة الجهاز المحمول. امنح الوصول من webhook‏ payment.succeeded / subscription.active بدلًا من ذلك.
  • لا يظهر Apple Pay / Google Pay على الأجهزة المحمولة: يتم تحميل صفحة الدفع داخل WebView مضمّن (WKWebView / Android‏ WebView)، ما يعطّل المحافظ وقد يتسبب في تعطل 3-D Secure. افتحها باستخدام حزمة SDK أو في متصفح النظام (Custom Tabs / SFSafariViewController).

موارد إضافية

للاستفسارات أو الدعم، تواصل مع support@dodopayments.com.
For questions or support, contact support@dodopayments.com.
آخر تعديل في ٢١ أغسطس ٢٠٢٦