@dodopayments/sveltekit تطبيق SvelteKit الخاص بك ثلاثة معالجات مسارات. يعيد Checkout عناوين URL لـ checkout، ويرسل CustomerPortal العميل إلى Customer Portal، ويتحقق Webhooks من أحداث webhook ويوجهها إلى التعليمات البرمجية الخاصة بك.
Checkout Handler
أنشئ عناوين URL لـ checkout من تطبيق SvelteKit الخاص بك.
Customer Portal
اسمح للعملاء بإدارة اشتراكاتهم وبياناتهم.
Webhooks
استلم أحداث webhook الخاصة بـ Dodo Payments وتحقق منها.
التثبيت
1
Install the Package
شغّل هذا الأمر في جذر مشروعك:تدرج الحزمة SvelteKit 2 (
@sveltejs/kit 2.20.3 أو أحدث) وzod 3.25 أو أحدث باعتبارهما تبعيتين نظيرتين.2
Set Up Environment Variables
أنشئ ملف أنشئ مفتاح API ضمن Developer → API Keys. أضف نقطة نهاية webhook ضمن Developer → Webhooks وانسخ سر التوقيع الخاص بها إلى
.env في جذر مشروعك:DODO_PAYMENTS_WEBHOOK_KEY. يمثل DODO_PAYMENTS_RETURN_URL المكان الذي يصل إليه العملاء بعد checkout. إذا لم تمرر بيئة، تستخدم المعالجات live_mode.أمثلة على معالجات المسارات
الأمثلة عبارة عن نقاط نهاية SvelteKit
+server.ts ضمن src/routes/api/. وهي تستورد بيانات اعتمادك من $env/static/private، الذي يبقيه SvelteKit بعيدًا عن التعليمات البرمجية من جهة العميل.- Checkout Handler
- Customer Portal Handler
- Webhook Handler
استخدم هذا المعالج لإضافة checkout من Dodo Payments إلى تطبيق SvelteKit الخاص بك. يعيد
Checkout معالج GET لـ checkout الثابت ومعالج POST لجلسات checkout، أو لـ checkout الديناميكي عند تعيين type: "dynamic". صدّر GET من معالج أُنشئ باستخدام type: "static" أو بدون type، لأن معالج GET لمعالج session أو dynamic يعيد 400.POST من معالج أُنشئ باستخدام type: "dynamic". باستخدام type: "session"، كما في مسار المثال، أرسل طلب جلسة checkout.معالج مسار checkout
يدعم معالج checkout الطرق الثلاث جميعها لتحصيل المدفوعات باستخدام Dodo Payments:- روابط الدفع الثابتة: عناوين URL قابلة للمشاركة لتحصيل المدفوعات دون تعليمات برمجية.
- روابط الدفع الديناميكية: روابط دفع تنشئها مع تفاصيل مخصصة. وهي تستخدم نقاط نهاية مهملة.
- جلسات checkout: checkout مستضاف مع سلة منتجات وتفاصيل العميل وخيارات التخصيص. هذا هو التدفق الموصى به.
Checkout الخيارات التالية:
Static Checkout (GET)
Static Checkout (GET)
Query Parameters المدعومة
يثبّت المبلغ المحصّل بوحدات العملة الأساسية، مثل
12.5 مقابل $12.50. يعمل مع منتجات Pay What You Want فقط، ويتم تجاهله إذا كان أقل من الحد الأدنى لسعر المنتج.returnUrl من إعداداته إلى الرابط باعتباره redirect_url.تنسيق الاستجابة
يعيد checkout الثابت استجابة JSON تحتوي على عنوان URL لـ checkout. في وضع الاختبار، يستخدم عنوان URL القيمةtest.checkout.dodopayments.com.Dynamic Checkout (POST)
Dynamic Checkout (POST)
Checkout Sessions (POST)
Checkout Sessions (POST)
تنشئ جلسات checkout checkout مستضافًا لعمليات الشراء لمرة واحدة والاشتراكات، مع تحكم كامل في التخصيص.
product_cart هو الحقل المطلوب الوحيد. إذا لم يتضمن النص return_url، يستخدم المعالج returnUrl من إعداداته.لمزيد من التفاصيل وجميع الحقول المدعومة، راجع دليل دمج Checkout Sessions.لا يعيد session أُنشئت باستخدام payment_method_id أي عنوان URL لـ checkout، لذلك يعيد المعالج 400. لشحن طريقة دفع محفوظة، أنشئ session باستخدام SDK بدلًا من ذلك.تنسيق الاستجابة
تعيد جلسات checkout استجابة JSON تحتوي على عنوان URL لـ checkout:معالج مسار Customer Portal
ينشئ معالج مسار Customer Portal جلسة Customer Portal للعميل الذي تمرره إليه، ثم يعيد توجيه المتصفح إليها باستجابة 302.Query Parameters
إذا تم تعيينه إلى
true، ترسل Dodo Payments أيضًا رابط البوابة إلى العميل عبر البريد الإلكتروني.معالج مسار Webhook
يتحقق معالج مسار webhook من كل طلب قبل تشغيل التعليمات البرمجية الخاصة بك:- Method: لا يتم دعم سوى طلبات POST. تعيد الطرق الأخرى 405.
- التحقق من التوقيع: يتحقق من نص الطلب الخام والعناوين
webhook-idوwebhook-timestampوwebhook-signatureباستخدامwebhookKey، وفقًا لمواصفات Standard Webhooks. يعيد 401 إذا فشل التحقق. - التحقق من الحمولة: يتحقق من الحمولة باستخدام Zod. يعيد 400 للحمولة غير الصالحة.
- معالجة الأخطاء:
- 401: توقيع غير صالح
- 400: حمولة غير صالحة
- 500: خطأ داخلي أثناء التحقق
- توجيه الأحداث: يستدعي
onPayloadلكل حدث، ثم المعالج الخاص بنوع الحدث، ويعيد 200.