Quick Start
Platform Examples
Checkout Customization
Mobile Recipes
start(...) واحد ومكتوب النوع، مع توفير استرداد الجلسات المتروكة مضمّنًا. استخدم WebView يدويًا فقط إذا لم تناسبك أيٌّ من هذه الحزم.المتطلبات الأساسية
قبل دمج Dodo Payments في تطبيقك المحمول، تأكد من توفر ما يلي:- حساب Dodo Payments: حساب تاجر نشط مع إمكانية الوصول إلى API
- بيانات اعتماد API: مفتاح API ومفتاح سرّي لـ webhook من لوحة التحكم
- مشروع تطبيق محمول: تطبيق Android أو iOS أو React Native أو Flutter
- خادم خلفي: لمعالجة إنشاء جلسات الدفع بأمان
سير عمل التكامل
يتبع التكامل عبر الأجهزة المحمولة عملية آمنة من 4 خطوات، يتولى فيها خادمك الخلفي استدعاءات API ويدير تطبيقك المحمول تجربة المستخدم.status ليس سوى إشارة إلى واجهة المستخدم لما ينبغي عرضه للمستخدم. امنح إمكانية الوصول دائمًا من خلال payment.succeeded / subscription.active webhook على خادمك الخلفي، وليس من نتيجة الجهاز المحمول وحدها.Backend: Create Checkout Session
Checkout Session API Docs
Mobile: Get Checkout URL
- iOS (Swift)
- Android (Kotlin)
- React Native (JavaScript)
- Flutter (Dart)
Mobile: Open Checkout in Browser
Pick your mobile SDK
Backend: Handle Payment Completion
اختر حزمة 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-ios SFSafariViewController. يتطلب iOS 16 أو أحدث.React Native
@dodopayments/react-native-checkout، وهي Turbo Module فوق النواتين الأصليتين. تتطلب React Native 0.76 أو أحدث.Flutter
dodopayments_checkout، وهي قناة Pigeon فوق النواتين الأصليتين. تتطلب Flutter 3.44 أو أحدث.تسجيل مخطط عنوان URL لاستدعاء الإرجاع
تعيد حزم SDK الأربع التحكم إلى تطبيقك من خلال مخطط عنوان URL مخصّص تختاره، مثلmyapp://checkout/return. سجّله مرة واحدة لكل منصة:
- Android
- iOS
- Expo
checkout_url في متصفح النظام للمنصة (Android Custom Tabs / iOS SFSafariViewController)، واعترض عملية التنقل إلى return_url، ثم اقرأ معلَمتي الاستعلام status وpayment_id. تنفّذ حزم SDK أعلاه هذه الخطوات نيابةً عنك.تخصيص المظهر
تقبل كل حزمة SDK معلَمةcustomization اختيارية في start(...) / CheckoutParams، وتتحكم هذه المعلَمة في مظهر سطح المتصفح الأصلي وسلوكه، مثل شريط الأدوات والأزرار وطريقة العرض. وهذا منفصل عن سمة صفحة الدفع نفسها، التي تضبطها من جهة الخادم عبر customization.theme_config في جلسة الدفع.
تُجمّع الخيارات حسب المنصة لأن Custom Tab في Android وSFSafariViewController في iOS يوفّران عناصر تحكم أصلية مختلفة. جميع الحقول اختيارية؛ ويؤدي حذف customization بالكامل إلى استخدام المظهر الافتراضي لكل منصة.
Android - Custom Tab
Android - Custom Tab
default رمز النظام “X”؛ بينما يرسم back سهم رجوع بدلًا منه.iOS - SFSafariViewController
iOS - SFSafariViewController
pageSheet كبطاقة يمكن إغلاقها بالسحب؛ بينما يغطي fullScreen الشاشة بأكملها.presentationStyle هي fullScreen؛ أما pageSheet فيبقي الأشرطة مثبتة بغض النظر عن هذا الإعداد.- React Native
- Flutter
- Android (Kotlin)
- iOS (Swift)
تخصيص صفحة الدفع
يتحكم قسم تخصيص المظهر أعلاه في سطح المتصفح الأصلي، بما يشمل شريط الأدوات والأزرار ونظام الألوان. أما صفحة الدفع نفسها، أي الحقول الظاهرة والسمة وطرق الدفع المعروضة، فتُضبط من جهة الخادم عند إنشاء جلسة الدفع. ولهذه المعلَمات أكبر تأثير في التحويل عبر الأجهزة المحمولة. توجد المعلَمات أدناه في ثلاثة مواضع مختلفة ضمن طلب جلسة الدفع؛ ويحدد عمود موضعها الكائن الذي تنتمي إليه كل معلَمة. ويُعد وضع المعلَمة في الكائن الخطأ أكثر الأخطاء شيوعًا، إذ يتم تجاهلها بصمت.
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.
Full checkout session parameter reference
وصفات محسّنة للأجهزة المحمولة
كل وصفة أدناه هي نص طلب كامل لإنشاء جلسة دفع. انسخ الوصفة المطابقة لسيناريوك، واستبدل معرّف المنتج، ثم مرّرها إلى نقطة النهاية الخاصة بإنشاء الجلسة في خادمك الخلفي.Minimal Mobile Checkout - fastest path to payment
Minimal Mobile Checkout - fastest path to payment
- Node.js SDK
- Python SDK
One-Click Returning Customer - saved card, instant confirmation
One-Click Returning Customer - saved card, instant confirmation
confirm: true لتجاوز نموذج الدفع بالكامل.- Node.js SDK
- Python SDK
status في استجابة الرابط العميق ليس سوى إشارة إلى واجهة المستخدم. أكّد منح الوصول من خلال الاستماع إلى webhook payment.succeeded على خادمك الخلفي.Subscription with Free Trial - trial before first charge
Subscription with Free Trial - trial before first charge
- Node.js SDK
- Python SDK
subscription.active، وليس عند إرجاع SDK المحمول للنتيجة. راجع دليل تكامل الاشتراكات للاطلاع على تدفق webhook الكامل.On-Demand Mandate - save a card for future variable charges
On-Demand Mandate - save a card for future variable charges
- Node.js SDK
- Python SDK
تدفقات الاشتراك من الأجهزة المحمولة
تُنشأ الاشتراكات من خلال تدفق جلسة الدفع نفسه المستخدم للمدفوعات لمرة واحدة؛ إذ تفتح حزمة SDK المحمولة صفحة الدفع المستضافة، ويشترك العميل، ويتعامل تطبيقك مع الاستجابة عبر الرابط العميق. ثم تُدار دورة حياة الاشتراك بالكامل من جهة الخادم الخلفي.الاشتراكات المتكررة العادية
للفوترة على فترات ثابتة (شهرية أو سنوية)، أنشئ جلسة دفع باستخدام منتج اشتراك ورابط عميقreturn_url. سيتلقى خادمك الخلفي subscription.active عند تأكيد الاشتراك.
الاشتراكات عند الطلب
تتيح الاشتراكات عند الطلب تفويض طريقة دفع العميل مرة واحدة وخصم مبالغ متغيرة لاحقًا، وهي مثالية لشحن المحافظ والدفع حسب الاستخدام وأي سيناريو لا يكون فيه مبلغ الخصم معلومًا مسبقًا. راجع وصفة On-Demand Mandate أعلاه لنص الطلب الكامل. اعتبارات مهمة للأجهزة المحمولة:- اضبط
show_on_demand_tag: falseكي لا تعرض صفحة الدفع لغة “اشتراك” أو “عند الطلب”. ففي حالات استخدام ترميز البطاقة، لا يتوقع العملاء مصطلحات الاشتراك. - بعد تفويض التفويض، سيتلقى خادمك الخلفي
subscription.active. خزّنsubscription_id، إذ ستستخدمه في جميع عمليات الخصم المستقبلية.
اشتراك مع فترة تجريبية مجانية
مرّرsubscription_data.trial_period_days في جلسة الدفع لتقديم فترة تجريبية قبل دورة الفوترة الأولى. ويفوّض العميل طريقة الدفع أثناء التسجيل في الفترة التجريبية؛ ويحدث الخصم الأول تلقائيًا عند انتهائها. راجع وصفة Subscription with Free Trial أعلاه لنص الطلب الكامل.
الترقية وخفض الخطة
تُجرى تغييرات الخطة عبر API على خادمك الخلفي، وليس من خلال جلسة دفع جديدة. يحسب Dodo Payments التقسيم النسبي تلقائيًا. لتوفير خيار الخدمة الذاتية للعملاء، ضمّن Customer Portal أو أضف رابطًا إليه.Subscription Integration Guide
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 يكون ذلك العنصر النائب في manifestdodoCallbackScheme؛ وفي iOS وReact Native يكون نوع عنوان URLInfo.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/ AndroidWebView)، ما يعطّل المحافظ وقد يتسبب في تعطل 3-D Secure. افتحها باستخدام حزمة SDK أو في متصفح النظام (Custom Tabs /SFSafariViewController).
موارد إضافية
- دليل تكامل الدفع
- توثيق Webhook
- عملية الاختبار
- الأسئلة الشائعة التقنية
- تخصيص جلسة الدفع
- الاشتراكات عند الطلب
- ترقية/خفض الاشتراك
- استرداد سلة التسوق المتروكة
- Customer Portal
