@dodopayments/remix تطبيق Remix لديك ثلاثة معالجات للطلبات. يعيد Checkout عناوين URL الخاصة بـ checkout، ويرسل CustomerPortal العميل إلى Customer Portal، بينما يتحقق Webhooks من أحداث webhook ويوجهها إلى التعليمات البرمجية لديك. يأخذ كل معالج Request ويعيد Response، لذا تستدعيه من loader أو action الخاص بمسار ما.
Checkout Handler
أنشئ عناوين URL لـ checkout من تطبيق Remix لديك.
Customer Portal
اسمح للعملاء بإدارة اشتراكاتهم وتفاصيلهم.
Webhooks
استقبل أحداث webhook من Dodo Payments وتحقق منها.
التثبيت
1
Install the Package
شغّل هذا الأمر في جذر مشروعك:تدرج الحزمة Remix 2 (
remix 2.16.8 أو أحدث) وzod 3.25 أو أحدث باعتبارهما peer dependencies.2
Set Up Environment Variables
أنشئ ملف أنشئ API key ضمن Developer → API Keys. أضف نقطة نهاية webhook ضمن Developer → Webhooks وانسخ signing secret الخاص بها إلى
.env في جذر مشروعك:DODO_PAYMENTS_WEBHOOK_KEY. يمثّل DODO_PAYMENTS_RETURN_URL المكان الذي يصل إليه العملاء بعد checkout. إذا لم تمرر environment، تستخدم المعالجات live_mode.أمثلة على Route Handler
الأمثلة عبارة عن resource routes في Remix، وهي تصدّر
loader لطلبات GET أو action لطلبات POST، ولا تتضمن مكوّنًا. مع flat file routes، يخدم app/routes/api.checkout.tsx /api/checkout.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
استخدم هذا المعالج لإضافة checkout الخاص بـ Dodo Payments إلى تطبيق Remix لديك. يخدم
loader checkout الثابت. ويخدم action checkout الديناميكي هنا. ولخدمة checkout sessions، وهو التدفق الموصى به، أعد checkoutSessionHandler(request) من action بدلًا من ذلك.action قيمة checkoutSessionHandler(request).Checkout Route Handler
يدعم checkout handler الطرق الثلاث جميعها لتحصيل المدفوعات باستخدام Dodo Payments:- Static Payment Links: عناوين URL قابلة للمشاركة لتحصيل المدفوعات من دون تعليمات برمجية.
- Dynamic Payment Links: روابط دفع تنشئها مع تفاصيل مخصصة. وهي تستخدم endpoints مهملة.
- Checkout Sessions: checkout مستضاف يتضمن سلة منتجات وتفاصيل العميل وخيارات التخصيص. وهذا هو التدفق الموصى به.
Checkout الخيارات التالية:
Static Checkout (GET)
Static Checkout (GET)
Query Parameters المدعومة
يثبّت المبلغ المحصّل، بوحدات العملة الرئيسية، مثل
12.5 مقابل $12.50. يعمل مع منتجات Pay What You Want فقط، ويتم تجاهله إذا كان أقل من الحد الأدنى لسعر المنتج.returnUrl من config الخاص به إلى الرابط باعتباره redirect_url.تنسيق الاستجابة
يعيد checkout الثابت استجابة JSON تتضمن عنوان URL الخاص بـ checkout. في test mode، يستخدم عنوان URL القيمةtest.checkout.dodopayments.com.Dynamic Checkout (POST)
Dynamic Checkout (POST)
Checkout Sessions (POST)
Checkout Sessions (POST)
تنشئ checkout sessions عملية checkout مستضافة للمشتريات لمرة واحدة والاشتراكات، مع تحكم كامل في التخصيص. يُعد
product_cart الحقل المطلوب الوحيد. إذا لم يتضمن body قيمة return_url، يستخدم المعالج returnUrl من config الخاص به.للمزيد من التفاصيل والاطلاع على كل field مدعوم، راجع Checkout Sessions Integration Guide.لا يعيد session تم إنشاؤه باستخدام payment_method_id أي عنوان URL لـ checkout، لذلك يعيد المعالج استجابة 400. لتحصيل المدفوعات باستخدام طريقة دفع محفوظة، أنشئ session باستخدام SDK بدلًا من ذلك.تنسيق الاستجابة
تعيد checkout sessions استجابة JSON تتضمن عنوان URL الخاص بـ checkout:Customer Portal Route Handler
ينشئ Customer Portal route handler جلسة Customer Portal للعميل الذي تمرره إليه، ثم يعيد توجيه المتصفح إليها باستجابة 307.Query Parameters
إذا تم ضبطه على
true، يرسل Dodo Payments أيضًا رابط Customer Portal إلى العميل عبر البريد الإلكتروني.Webhook Route Handler
يتحقق webhook route handler من كل طلب قبل تشغيل التعليمات البرمجية لديك:- الطريقة: لا يدعم سوى طلبات POST. وتعيد الطرق الأخرى 405.
- التحقق من التوقيع: يتحقق من raw request body ومن رؤوس
webhook-idوwebhook-timestampوwebhook-signatureباستخدامwebhookKey، وفق مواصفة Standard Webhooks. ويعيد 401 إذا فشل التحقق. - التحقق من Payload: يتحقق من صحة payload باستخدام Zod. ويعيد 400 عند وجود payload غير صالح.
- معالجة الأخطاء:
- 401: توقيع غير صالح
- 400: payload غير صالح
- 500: خطأ داخلي أثناء التحقق
- توجيه الأحداث: يستدعي
onPayloadلكل event، ثم يستدعي المعالج الخاص بنوع event، ويعيد 200.