gPdf คำนวณ receipt total ได้หรือไม่

ไม่ payment หรือ commerce system ของคุณเป็นเจ้าของ totals, discounts, tax และ refund state gPdf เรนเดอร์ค่าที่คุณส่งมา

receipt ควรใช้ JSON Render หรือ Template Render

ใช้ JSON Render ระหว่างออกแบบ layout ใช้ Template Render เมื่อ layout และ field contract ของ receipt เสถียร

receipt ใส่ QR code ได้หรือไม่

ได้ gPdf รองรับ QR code barcode elements ใน PDF output ระบบของคุณเป็นเจ้าของ URL หรือ payload ที่ encode ใน QR code

นี่เหมือน e-invoice API หรือไม่

ไม่ ordinary receipt PDFs ใช้ JSON Render หรือ Template Render ส่วน Factur-X และ ZUGFeRD packaging ใช้ E-Invoice Render endpoint

ใบแจ้งหนี้และการเงิน

Receipt PDF API สำหรับ ecommerce และ SaaS payments

สร้าง receipt PDF จากข้อมูล order, payment, tax และ refund พร้อม QR codes, barcodes, PDF/A settings และ output จากเทมเพลตที่ repeat ได้

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS ecommerce backend / billing backend / SaaS platform / บริการ POS export

ลองใน Playground อ่านเอกสาร

งานที่ต้องทำให้เสร็จ

แปลงข้อมูล completed order, payment, refund และ tax เป็น receipt PDF ที่ email, store, print หรือ attach กับ customer account ได้ โดยไม่ต้องให้ caller ทุกตัวเป็นเจ้าของ PDF drawing code

ควรใช้ API นี้เมื่อใด

ระบบของคุณเป็นเจ้าของ payment status, receipt number, tax lines และ customer data อยู่แล้ว
คุณต้องการ receipt PDF สำหรับ email, account history, support workflows หรือ audit export
คุณต้องการ QR codes หรือ barcodes ใน receipt สำหรับ lookup, refund หรือ pickup flows
คุณต้องการ receipt template ที่เสถียรหลัง layout ได้รับอนุมัติ

สิ่งที่ไม่ได้ทดแทน

คุณต้องการ payment processing หรือ refund execution gPdf เรนเดอร์ receipt ส่วน payment system ของคุณเป็นเจ้าของ money movement
คุณต้องการ legal e-invoice packaging ใช้ E-Invoice Render สำหรับ output Factur-X หรือ ZUGFeRD
คุณต้องการ POS hardware control หรือ cash drawer logic

ควรเรียก endpoint ใด

PRIMARY

/api/v1/pdf/render

JSON Render คือ path หลักสำหรับเวิร์กโฟลว์นี้.

SECONDARY 1

/api/v1/template-render

ใช้เมื่อเวิร์กโฟลว์ต้องการ API path ที่เกี่ยวข้อง สัญญาเทมเพลต หรือการค้นหา capability.

Minimal request

POST /api/v1/pdf/render - receipt ขนาดกะทัดรัดพร้อม lookup QR code

{
  "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 จัดการอะไร

การเรนเดอร์หน้า receipt จาก JSON Render payloads
text, totals, item lines, QR codes, barcodes, metadata และ optional PDF/A settings
Template Render binding เมื่อใช้ layout receipt เดิมซ้ำ
binary PDF output พร้อม error envelope ร่วมของ gPdf เมื่อเกิด failure

ระบบของคุณรับผิดชอบอะไร

payment authorization, capture, refund, tax calculation และ receipt numbering
customer identity, order state, currency formatting และ retention policy
email delivery, account storage และ duplicate receipt handling

Production checklist

ใช้ receipt number ที่เสถียรและส่ง X-Request-Id กับทุก render
ตัดสินใจว่า receipt ควรถูก regenerate จาก source data หรือจัดเก็บหลัง render ครั้งแรก
ทดสอบ item names ที่ยาว, refunds, discounts, multi-tax lines และ zero-value orders
เปลี่ยนไปใช้ Template Render เมื่อทีม support และ finance อนุมัติ layout แล้ว
เก็บ payment และ tax decisions ไว้นอก rendering request

ขอบเขตของ claim

gPdf ไม่ประมวลผล payments ไม่คำนวณ tax และไม่ issue refunds
receipt PDF ไม่ได้เป็น legal e-invoice โดยอัตโนมัติ
ระบบของคุณเป็นเจ้าของ business truth; gPdf เรนเดอร์ PDF representation

Receipt PDFs คือ rendering outputs

นี่ไม่ใช่ endpoint สำหรับ payment หรือ POS แยกต่างหาก ecommerce, billing หรือ POS backend ของคุณตัดสินว่า receipt มีอยู่แล้วส่งเนื้อหา receipt ให้ gPdf เป็น DocumentRequest หรือเป็น data สำหรับ published template

rendering layer ควร deterministic หาก support agent ขอ receipt เดิมอีกครั้ง ระบบของคุณสามารถ replay source data หรือส่ง PDF ที่จัดเก็บไว้ก่อนหน้าได้ตาม retention policy

เส้นทาง template สำหรับ receipts ที่ใช้ซ้ำ

layout ของ receipt มักเสถียรเร็ว เมื่อ design อนุมัติแล้ว ให้ publish template และเรียก POST /api/v1/template-render พร้อม fields ของ receipt วิธีนี้ทำให้ payment systems โฟกัสที่ data และเก็บ ownership ของ layout ไว้ที่เดียว

FAQ

gPdf คำนวณ receipt total ได้หรือไม่: ไม่ payment หรือ commerce system ของคุณเป็นเจ้าของ totals, discounts, tax และ refund state gPdf เรนเดอร์ค่าที่คุณส่งมา
receipt ควรใช้ JSON Render หรือ Template Render: ใช้ JSON Render ระหว่างออกแบบ layout ใช้ Template Render เมื่อ layout และ field contract ของ receipt เสถียร
receipt ใส่ QR code ได้หรือไม่: ได้ gPdf รองรับ QR code barcode elements ใน PDF output ระบบของคุณเป็นเจ้าของ URL หรือ payload ที่ encode ใน QR code
นี่เหมือน e-invoice API หรือไม่: ไม่ ordinary receipt PDFs ใช้ JSON Render หรือ Template Render ส่วน Factur-X และ ZUGFeRD packaging ใช้ E-Invoice Render endpoint