@dodopayments/bun خادم Bun لديك ثلاثة معالجات للطلبات. يعيد Checkout عناوين URL الخاصة بـ checkout، ويرسل CustomerPortal العميل إلى Customer Portal، بينما يتحقق Webhooks من أحداث webhook ويوجهها إلى التعليمات البرمجية لديك. يأخذ كل معالج Request قياسيًا ويعيد Response، لذا تستدعيه من معالج fetch الخاص بـ Bun.serve().
Checkout Handler
أنشئ عناوين URL لـ checkout باستخدام تدفقات ثابتة وديناميكية وتدفقات جلسات checkout.
Customer Portal
اسمح للعملاء بإدارة اشتراكاتهم وتفاصيلهم.
Webhooks
استقبل أحداث webhook الخاصة بـ Dodo Payments وعالجها.
التثبيت
1
Install the Package
شغّل هذا الأمر في جذر مشروعك:تحتاج الحزمة أيضًا إلى
zod 3.25 أو إصدار أحدث، وتدرجه كتبعية نظيرة.2
Set Up Environment Variables
أنشئ ملف يقرأ Bun ملفات
.env في جذر مشروعك. أنشئ مفتاح API ضمن Developer → API Keys. أضف نقطة نهاية webhook ضمن Developer → Webhooks، وانسخ Signing secret الخاص بها إلى DODO_PAYMENTS_WEBHOOK_KEY:.env تلقائيًا، لذا تقرأ الأمثلة هذه القيم من process.env. يمثل DODO_PAYMENTS_RETURN_URL المكان الذي يصل إليه العملاء بعد checkout. إذا لم تمرر بيئة، تستخدم المعالجات live_mode. يعمل مفتاح API الخاص بوضع الاختبار فقط مع test_mode.أمثلة على معالجات المسارات
تستخدم جميع الأمثلة خادم Bun الأصلي، وهو
Bun.serve()، وتوجه الطلبات حسب المسار والطريقة في معالج fetch الخاص به.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
استخدم هذا المعالج لإضافة checkout الخاص بـ Dodo Payments إلى خادم Bun لديك. يخدم المعالج الثابت طلبات
GET. ويخدم المعالجان الخاصان بالجلسات والديناميكي طلبات POST. يفترض مثال checkout الديناميكي أن الخادم يعيد dynamicCheckoutHandler(request) لطلبات POST.معالج مسار checkout
يدعم معالج checkout الطرق الثلاث جميعها لتحصيل المدفوعات باستخدام Dodo Payments:- روابط الدفع الثابتة: عناوين URL قابلة للمشاركة تجمع المدفوعات دون تعليمات برمجية.
- روابط الدفع الديناميكية: روابط دفع تنشئها بتفاصيل مخصصة. وهي تستخدم نقاط نهاية مهجورة.
- جلسات checkout: checkout مستضاف مع سلة منتجات وتفاصيل العميل وخيارات التخصيص. وهذا هو التدفق الموصى به.
Checkout هذه الخيارات:
يخدم المعالج checkout الثابت لطلبات
GET. وبالنسبة إلى طلبات POST، ينشئ رابط دفع ديناميكيًا عندما تكون قيمة type هي dynamic، وينشئ جلسة checkout خلاف ذلك.
Static Checkout (GET)
Static Checkout (GET)
معلمات الاستعلام المدعومة
string
مطلوب
معرّف المنتج، مثل
?productId=pdt_xxx.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
يتم تمرير أي معلمة استعلام تبدأ بـ
metadata_ إلى checkout باعتبارها metadata، مثل metadata_orderId=123.email مع disableEmail=true. يضيف المعالج returnUrl من إعداداته إلى الرابط باسم redirect_url.تنسيق الاستجابة
يعيد checkout الثابت استجابة JSON تحتوي على عنوان URL الخاص بـ checkout. في وضع الاختبار، يستخدم عنوان URLtest.checkout.dodopayments.com:Dynamic Checkout (POST)
Dynamic Checkout (POST)
- أرسل المعلمات في نص JSON ضمن طلب POST.
- يدعم المدفوعات لمرة واحدة والمدفوعات المتكررة. يسترد المعالج المنتج، ثم ينشئ اشتراكًا إذا كان المنتج متكررًا، وإلا ينشئ دفعة لمرة واحدة.
- يحتاج النص إلى
billing(معstreetوcityوstateوcountryوzipcode) وcustomer، بالإضافة إلىproduct_idأوproduct_cart. تحتاج الاشتراكات إلىproduct_id. - للاطلاع على كل حقل مدعوم في النص، راجع:
تنسيق الاستجابة
يعيد checkout الديناميكي استجابة JSON تحتوي على رابط الدفع باعتباره عنوان URL الخاص بـ checkout:Checkout Sessions (POST)
Checkout Sessions (POST)
تنشئ جلسات checkout تجربة checkout مستضافة للمشتريات لمرة واحدة والاشتراكات، مع تحكم كامل في التخصيص. يمثل
product_cart الحقل المطلوب الوحيد، ويحتاج إلى منتج واحد على الأقل. إذا لم يتضمن النص return_url، يستخدم المعالج returnUrl من إعداداته.يعمل كل checkout_url مرة واحدة وتنتهي صلاحيته بعد 24 ساعة، أو بعد 15 دقيقة عند تمرير confirm: true. لا تعيد الجلسة المنشأة باستخدام payment_method_id أي checkout_url، لذا يعيد المعالج استجابة 400.لمزيد من التفاصيل والاطلاع على كل حقل مدعوم، راجع دليل دمج جلسات Checkout.تنسيق الاستجابة
تعيد جلسات checkout استجابة JSON تحتوي على عنوان URL الخاص بـ checkout:معالج مسار Customer Portal
ينشئ معالج مسار Customer Portal جلسة Customer Portal للعميل الذي تمرره، ثم يعيد توجيه المتصفح إليها. يأخذCustomerPortal خياري bearerToken وenvironment نفسيهما اللذين يأخذهما Checkout.
معلمات الاستعلام
string
مطلوب
معرّف العميل الخاص بجلسة البوابة، مثل
?customer_id=cus_123.boolean
إذا تم تعيينه على
true، يرسل Dodo Payments أيضًا رابط البوابة إلى العميل عبر البريد الإلكتروني.customer_id مفقودًا، واستجابة 500 إذا تعذّر إنشاء جلسة البوابة.
معالج مسار Webhook
يتحقق معالج مسار webhook من كل طلب باستخدام سر webhook الخاص بك، الذي يتم تمريره باعتبارهwebhookKey، قبل تشغيل التعليمات البرمجية لديك:
- الطريقة: لا تُدعم إلا طلبات POST. وتعيد الطرق الأخرى 405.
- التحقق من التوقيع: يتحقق من ترويسات
webhook-idوwebhook-timestampوwebhook-signatureباستخدامwebhookKey، وفقًا لمواصفات Standard Webhooks. ويعيد 401 إذا فشل التحقق. - التحقق من الحمولة: يحلل النص باعتباره JSON ويتحقق منه باستخدام Zod. ويعيد 400 عند وجود JSON غير صالح أو حمولة غير صالحة.
- معالجة الأخطاء:
- 401: توقيع غير صالح
- 400: حمولة غير صالحة
- 500: خطأ داخلي أثناء التحقق
- توجيه الأحداث: يستدعي
onPayloadلكل حدث، ثم يستدعي المعالج الخاص بنوع الحدث، ويعيد 200.
Bun.serve()، ويفشل الطلب.