API إيصالات PDF لمدفوعات التجارة الإلكترونية وSaaS
أنشئ إيصالات PDF من بيانات الطلب والدفع والضرائب والمرتجعات، مع QR codes وباركود وإعدادات PDF/A ومخرجات قوالب قابلة للإعادة.
/api/v1/pdf/render تحويل بيانات الطلب المكتمل والدفع والمرتجع والضرائب إلى إيصال PDF يمكن إرساله بالبريد أو تخزينه أو طباعته أو إرفاقه بحساب العميل دون أن يملك كل متصل كود رسم PDF.
متى تستخدم هذه API
- يملك نظامك بالفعل حالة الدفع ورقم الإيصال وبنود الضرائب وبيانات العميل.
- تحتاج إلى إيصال PDF للبريد الإلكتروني أو تاريخ الحساب أو دعم العملاء أو تصدير التدقيق.
- تريد QR codes أو باركود داخل الإيصال للبحث أو المرتجع أو الاستلام.
- تحتاج إلى قالب إيصال مستقر بعد اعتماد التخطيط.
ما الذي لا تستبدله
- تحتاج إلى معالجة الدفع أو تنفيذ المرتجعات. يعرض gPdf الإيصال؛ ويملك نظام الدفع حركة الأموال.
- تحتاج إلى تغليف فاتورة إلكترونية قانونية. استخدم مسار E-Invoice Render لمخرجات Factur-X أو ZUGFeRD.
- تحتاج إلى التحكم في أجهزة POS أو منطق درج النقد.
أي مسار API يجب استدعاؤه
/api/v1/pdf/render
JSON Render هو المسار الافتراضي لسير العمل هذا.
/api/v1/template-render
استخدمه عندما يحتاج سير العمل إلى مسار API مرتبط، أو عقد قالب، أو استعلام capabilities.
طلب مختصر
POST /api/v1/pdf/render - إيصال صغير يتضمن QR للبحث.
{
"pages": [
{
"size": "a6",
"elements": [
{
"type": "text",
"x": 10,
"y": 12,
"content": "Receipt R-2026-1001",
"style": { "font_size": 16, "font_family": "NotoSans-Regular" }
},
{
"type": "text",
"x": 10,
"y": 28,
"content": "Order total: $82.40\nPaid by card ending 4242\nTax: $6.10",
"style": { "font_size": 10, "font_family": "NotoSans-Regular" }
},
{
"type": "barcode",
"format": "qrcode",
"content": "https://example.com/receipts/R-2026-1001",
"x": 10,
"y": 58,
"width": 28,
"height": 28
}
]
}
]
}
ما يتولاه gPdf
- عرض صفحة الإيصال من بيانات JSON Render.
- النص والإجماليات وبنود العناصر وQR codes والباركود والبيانات الوصفية وإعدادات PDF/A اختيارية.
- ربط Template Render عندما يعاد استخدام تخطيط الإيصال نفسه.
- مخرجات PDF ثنائية مع غلاف أخطاء gPdf المشترك عند الفشل.
ما يبقى ضمن مسؤولية نظامك
- تفويض الدفع والتحصيل والمرتجعات وحساب الضرائب وترقيم الإيصالات.
- هوية العميل وحالة الطلب وتنسيق العملة وسياسة الاحتفاظ.
- تسليم البريد الإلكتروني وتخزين الحساب والتعامل مع الإيصالات المكررة.
قائمة فحص الإنتاج
- استخدم رقم إيصال مستقرًا ومرر X-Request-Id مع كل عرض.
- قرر ما إذا كانت الإيصالات ستعاد توليدها من بيانات المصدر أو تخزن بعد أول عرض.
- اختبر أسماء العناصر الطويلة والمرتجعات والخصومات وبنود الضرائب المتعددة والطلبات صفرية القيمة.
- انتقل إلى Template Render بعد موافقة فرق الدعم والمالية على التخطيط.
- أبق قرارات الدفع والضرائب خارج طلب العرض.
حدود الادعاءات
- لا يعالج gPdf المدفوعات ولا يحسب الضرائب ولا يصدر المرتجعات.
- إيصال PDF ليس تلقائيًا فاتورة إلكترونية قانونية.
- يملك نظامك حقيقة الأعمال؛ ويعرض gPdf تمثيل PDF.
إيصالات PDF هي مخرجات عرض
هذا ليس مسارًا منفصلًا للدفع أو POS. يقرر خادم التجارة الإلكترونية أو الفوترة أو POS لديك أن الإيصال موجود، ثم يرسل محتوى الإيصال إلى gPdf كـ DocumentRequest أو كبيانات لقالب منشور.
يجب أن تبقى طبقة العرض حتمية. إذا طلب موظف الدعم الإيصال نفسه مرة أخرى، يستطيع نظامك إما إعادة إرسال بيانات المصدر أو إرجاع PDF مخزن مسبقًا وفق سياسة الاحتفاظ لديك.
مسار القالب للإيصالات المتكررة
عادةً ما تستقر تخطيطات الإيصالات بسرعة. بعد اعتماد التصميم، انشر قالبًا واستدع POST /api/v1/template-render مع حقول الإيصال. هذا يبقي أنظمة الدفع مركزة على البيانات ويجعل مسؤولية التخطيط في مكان واحد.
الأسئلة الشائعة
- هل يستطيع gPdf حساب إجمالي الإيصال؟
- لا. يملك نظام الدفع أو التجارة لديك الإجماليات والخصومات والضرائب وحالة المرتجع. يعرض gPdf القيم التي ترسلها.
- هل يجب أن تستخدم الإيصالات JSON Render أم Template Render؟
- استخدم JSON Render أثناء تصميم التخطيط. واستخدم Template Render عندما يصبح تخطيط الإيصال وعقد الحقول مستقرين.
- هل يمكن أن يتضمن الإيصال QR code؟
- نعم. يدعم gPdf عناصر باركود QR code داخل مخرجات PDF. يملك نظامك URL أو البيانات المشفرة داخل QR code.
- هل هذا هو نفسه API الفواتير الإلكترونية؟
- لا. تستخدم إيصالات PDF العادية JSON Render أو Template Render. أما تغليف Factur-X و ZUGFeRD فيستخدم مسار E-Invoice Render.