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

Checkout Handler

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

Customer Portal

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

Webhooks

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

التثبيت

1

Install the Package

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

Set Up Environment Variables

أنشئ ملف .env في جذر مشروعك. أنشئ مفتاح API ضمن Developer → API Keys. أضف نقطة نهاية webhook ضمن Developer → Webhooks، وانسخ Signing secret الخاص بها إلى DODO_PAYMENTS_WEBHOOK_KEY:
يحدد DODO_PAYMENTS_RETURN_URL المكان الذي يصل إليه العملاء بعد checkout. إذا لم تمرر بيئة، فستستخدم المعالجات live_mode. يعمل مفتاح API الخاص بوضع الاختبار فقط مع test_mode.
لا تُرسل ملف .env أو الأسرار إلى نظام التحكم في الإصدارات.

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

الأمثلة هي نقاط نهاية خادم Astro في src/pages/api/. يجب أن تُعرض نقاط النهاية التي تستدعي Dodo Payments عند الطلب، لذا أضف server adapter إلى مشروع Astro. في وضع الإخراج static الافتراضي في Astro، تُعرض نقاط النهاية أثناء الإنشاء، ولذلك يصدّر كل مثال prerender = false لعرض نقطة النهاية مع كل طلب بدلًا من ذلك.
استخدم هذا المعالج لإضافة checkout الخاص بـ Dodo Payments إلى تطبيقك. يقدّم المعالج GET checkout الثابت. ويقدّم المعالج POST checkout sessions، أو checkout الديناميكي عند ضبط type: "dynamic". يمكن لملف نقطة النهاية تصدير معالج POST واحد فقط، لذلك يفترض مثال checkout الديناميكي ضبط type: "dynamic".

معالج مسار checkout

يدعم معالج checkout الطرق الثلاث جميعها لتحصيل المدفوعات باستخدام Dodo Payments:
  • Payment Links الثابتة: عناوين URL قابلة للمشاركة تجمع المدفوعات دون تعليمات برمجية.
  • Payment Links الديناميكية: روابط دفع تنشئها بتفاصيل مخصصة. وتستخدم نقاط نهاية متوقفة عن العمل.
  • 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. في وضع الاختبار، يستخدم عنوان 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. ويستمر في العمل مع عمليات التكامل الحالية، لكن ينبغي لعمليات التكامل الجديدة استخدام checkout sessions.

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

يعيد checkout الديناميكي استجابة JSON تتضمن payment link باعتباره عنوان 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.

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

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

معالج مسار Customer Portal

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

Query Parameters

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

معالج مسار Webhook

يتحقق معالج مسار webhook من كل طلب باستخدام سر webhook الخاص بك، المُمرَّر باعتباره 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 الأخطاء التي تطرحها المعالجات الخاصة بك. تنتقل هذه الأخطاء إلى Astro، ويفشل الطلب.

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

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

Prompt لـ LLM

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