Skip to main content
تمنح حزمة @dodopayments/tanstack مشروع TanStack Start الخاص بك ثلاثة معالجات للطلبات. يعيد Checkout عناوين URL لـ checkout، ويرسل CustomerPortal العميل إلى Customer Portal، بينما يتحقق Webhooks من أحداث webhook ويوجّهها إلى التعليمات البرمجية الخاصة بك. يأخذ كل معالج Request قياسيًا ويعيد Response، لذا تستدعيه من معالج مسار خادم.

Checkout Handler

أنشئ عناوين URL لـ checkout باستخدام تدفقات ثابتة وديناميكية وتدفقات checkout session.

Customer Portal

اسمح للعملاء بإدارة اشتراكاتهم وتفاصيلهم.

Webhooks

استقبل أحداث webhook الخاصة بـ Dodo Payments وعالجها.

التثبيت

1

Install the Package

شغّل هذا الأمر في جذر مشروعك:
تحتاج الحزمة أيضًا إلى zod 3.25 أو إصدار أحدث، وتدرجه باعتباره peer dependency.
2

Set Up Environment Variables

أنشئ ملف .env في جذر مشروعك. أنشئ API key ضمن Developer → API Keys. أضف endpoint الخاص بـ webhook ضمن Developer → Webhooks، وانسخ Signing secret الخاص به إلى DODO_PAYMENTS_WEBHOOK_KEY:
يحمّل TanStack Start ملفات .env، وتقرأ مسارات الخادم القيم من process.env. يمثّل DODO_PAYMENTS_RETURN_URL المكان الذي يصل إليه العملاء بعد checkout. إذا لم تمرر environment، تستخدم المعالجات live_mode. لا يعمل test mode API key إلا مع test_mode.
لا ترفع ملف .env أو الأسرار إلى نظام التحكم بالإصدارات.

أمثلة على معالجات المسارات

الأمثلة عبارة عن مسارات خادم في TanStack Start ضمن src/routes/api/. يعرّف كل مثال معالجاته ضمن server.handlers في createFileRoute. تحدد إصدارات TanStack Start الأقدم، مثل 1.129، مسارات الخادم باستخدام createServerFileRoute من @tanstack/react-start/server واستدعاء .methods() بدلًا من ذلك. تعمل معالجات Dodo Payments بالطريقة نفسها مع كلتا الواجهتين البرمجيتين: مرّر إليها request.
استخدم هذا المعالج لإضافة Dodo Payments checkout إلى تطبيقك. يخدم معالج GET checkout الثابت. ويخدم معالج POST checkout sessions، أو checkout الديناميكي عند تعيين type: "dynamic". يفترض مثال checkout الديناميكي أنك عيّنت type: "dynamic".

معالج مسار checkout

يدعم معالج checkout الطرق الثلاث جميعها لتحصيل المدفوعات باستخدام Dodo Payments:
  • Static Payment Links: عناوين URL قابلة للمشاركة لتحصيل المدفوعات دون كتابة تعليمات برمجية.
  • Dynamic Payment Links: روابط دفع تنشئها مع تفاصيل مخصصة. تستخدم endpoints مهملة.
  • Checkout Sessions: checkout مستضاف يتضمن عربة منتجات وتفاصيل العميل وخيارات التخصيص. وهذا هو التدفق الموصى به.
يأخذ Checkout الخيارات التالية: يخدم المعالج checkout الثابت لطلبات GET. وبالنسبة إلى طلبات POST، ينشئ رابط دفع ديناميكيًا عندما تكون type هي dynamic، وينشئ checkout session في الحالات الأخرى.

Query Parameters المدعومة

string
مطلوب
معرّف المنتج، مثل ?productId=pdt_nZuwz45WAs64n3l07zpQR.
integer
افتراضي:"1"
كمية المنتج.
string
الاسم الكامل للعميل. يتم تجاهله إذا تم توفير firstName أو lastName.
string
الاسم الأول للعميل.
string
اسم العائلة للعميل.
string
عنوان البريد الإلكتروني للعميل.
string
بلد العميل، وفقًا لرمز ISO 3166-1 alpha-2.
string
عنوان الشارع للعميل.
string
مدينة العميل.
string
ولاية العميل أو مقاطعته.
string
الرمز البريدي للعميل.
boolean
عيّن القيمة إلى true لتعطيل حقل الاسم الكامل.
boolean
عيّن القيمة إلى true لتعطيل حقل الاسم الأول.
boolean
عيّن القيمة إلى true لتعطيل حقل اسم العائلة.
boolean
عيّن القيمة إلى true لتعطيل حقل البريد الإلكتروني.
boolean
عيّن القيمة إلى true لتعطيل حقل البلد.
boolean
عيّن القيمة إلى true لتعطيل حقل سطر العنوان.
boolean
عيّن القيمة إلى true لتعطيل حقل المدينة.
boolean
عيّن القيمة إلى true لتعطيل حقل الولاية.
boolean
عيّن القيمة إلى true لتعطيل حقل الرمز البريدي.
string
عملة الدفع، مثل USD.
boolean
افتراضي:"true"
إظهار أو إخفاء محدد العملة.
number
يثبّت المبلغ المفوتر، بوحدات العملة الرئيسية، مثل 12.5 مقابل $12.50. يعمل مع منتجات Pay What You Want فقط، ويتم تجاهله إذا كان أقل من السعر الأدنى للمنتج.
boolean
افتراضي:"true"
إظهار أو إخفاء قسم الخصومات.
string
يُمرَّر أي query parameter يبدأ بـ metadata_ إلى checkout باعتباره metadata، مثل metadata_orderId=123.
لا يسري disable flag إلا عندما يحتوي الحقل المطابق على قيمة، مثل email مع disableEmail=true. يضيف المعالج returnUrl من إعداداته إلى الرابط باعتباره redirect_url.
إذا كان productId مفقودًا، يعيد المعالج استجابة 400. كما تعيد query parameters غير الصالحة، أو المنتج غير الموجود في حسابك، استجابة 400.

تنسيق الاستجابة

يعيد checkout الثابت استجابة JSON تحتوي على عنوان URL لـ checkout. في test mode، يستخدم عنوان URL القيمة test.checkout.dodopayments.com:
  • أرسل المعلمات باعتبارها JSON body في طلب POST.
  • يدعم المدفوعات لمرة واحدة والمدفوعات المتكررة. يسترجع المعالج المنتج، ثم ينشئ اشتراكًا إذا كان المنتج متكررًا، أو دفعة لمرة واحدة بخلاف ذلك.
  • يحتاج body إلى billing (مع street وcity وstate وcountry وzipcode) وcustomer، بالإضافة إلى product_id أو product_cart. تحتاج الاشتراكات إلى product_id.
  • للاطلاع على كل body field مدعوم، راجع:
يعمل checkout الديناميكي كوسيط لـ POST /payments وPOST /subscriptions، وهما endpointان مهملان. ويستمر في العمل مع عمليات الدمج الحالية، لكن ينبغي لعمليات الدمج الجديدة استخدام checkout sessions.

تنسيق الاستجابة

يعيد checkout الديناميكي استجابة JSON تحتوي على رابط الدفع باعتباره عنوان URL لـ checkout:
تنشئ checkout sessions checkout مستضافًا لعمليات الشراء لمرة واحدة والاشتراكات، مع تحكم كامل في التخصيص. يُعد product_cart الحقل المطلوب الوحيد، ويحتاج إلى منتج واحد على الأقل. إذا لم يتضمن body قيمة return_url، يستخدم المعالج returnUrl من إعداداته.يعمل كل checkout_url مرة واحدة وينتهي بعد 24 ساعة، أو بعد 15 دقيقة عند تمرير confirm: true. ولا يعيد session الذي أُنشئ باستخدام payment_method_id أي checkout_url، لذا يعيد المعالج استجابة 400.لمزيد من التفاصيل والاطلاع على كل حقل مدعوم، راجع Checkout Sessions Integration Guide.

تنسيق الاستجابة

تعيد checkout sessions استجابة JSON تحتوي على عنوان URL لـ checkout:

معالج مسار Customer Portal

ينشئ معالج مسار Customer Portal جلسة Customer Portal للعميل الذي تمرره، ثم يعيد توجيه المتصفح إليها. يأخذ CustomerPortal خيارات bearerToken وenvironment نفسها التي يأخذها Checkout.
لا يتحقق المعالج من هو المتصل به. يحصل أي شخص يطلبه باستخدام customer ID على بوابة ذلك العميل. احمِ المسار باستخدام authentication الخاص بك، ومرّر customer ID للمستخدم الذي سجّل الدخول فقط.

Query Parameters

string
مطلوب
customer ID لجلسة البوابة، مثل ?customer_id=cus_123.
boolean
إذا عيّنت القيمة إلى true، يرسل Dodo Payments أيضًا رابط البوابة إلى العميل عبر البريد الإلكتروني.
يعيد المعالج 400 إذا كانت customer_id مفقودة، و500 إذا تعذر إنشاء جلسة البوابة.

معالج مسار webhook

يتحقق معالج مسار webhook من كل طلب باستخدام webhook secret الخاص بك، الذي يُمرَّر باعتباره webhookKey، قبل تشغيل التعليمات البرمجية الخاصة بك:
  • Method: لا تُدعم إلا طلبات POST. وتعيد الطرق الأخرى 405.
  • Signature Verification: يتحقق من رؤوس webhook-id وwebhook-timestamp وwebhook-signature باستخدام webhookKey، وفقًا لمواصفات Standard Webhooks. ويعيد 401 عند فشل التحقق.
  • Payload Validation: يتحقق من صحة payload باستخدام Zod. ويعيد 400 عند وجود payload غير صالح.
  • Error Handling:
    • 401: توقيع غير صالح
    • 400: payload غير صالح
    • 500: خطأ داخلي أثناء التحقق
  • Event Routing: يستدعي onPayload لكل حدث، ثم يستدعي المعالج الخاص بنوع الحدث، ويعيد 200.
لا يلتقط adaptor الأخطاء التي تُطرح في المعالجات الخاصة بك. تنتقل هذه الأخطاء إلى TanStack Start، ويفشل الطلب.

معالجات أحداث webhook المدعومة

كل معالج اختياري وغير متزامن، ويتلقى payload الذي تم التحقق منه لنوع الحدث الخاص به:
لمعرفة معنى كل حدث، راجع Webhook Event Guide.

Prompt for LLM

انسخ هذا prompt إلى AI coding assistant لإضافته إلى مشروعك. ولتزويد agent الخاص بك أيضًا بوثائق Dodo Payments والمهارات، ثبّت Agent Plugin.
آخر تعديل في ٢٦ سبتمبر ٢٠٢٦