Can gPdf calculate the receipt total?

No. Your payment or commerce system owns totals, discounts, tax, and refund state. gPdf renders the values you send.

Should receipts use JSON Render or Template Render?

Use JSON Render while designing the layout. Use Template Render when the receipt layout and field contract are stable.

Can the receipt include a QR code?

Yes. gPdf supports QR code barcode elements in PDF output. Your system owns the URL or payload encoded in the QR code.

Is this the same as the e-invoice API?

No. Ordinary receipt PDFs use JSON Render or Template Render. Factur-X and ZUGFeRD packaging uses the E-Invoice Render endpoint.

Invoicing and finance

Receipt PDF API for ecommerce and SaaS payments

Generate receipt PDFs from order, payment, tax, and refund data with QR codes, barcodes, PDF/A settings, and repeatable template output.

PRIMARY API JSON Render

ENDPOINT /api/v1/pdf/render

SYSTEMS ecommerce backend / billing backend / SaaS platform / POS export service

Try in Playground → Read the docs

Job to be done

Turn completed order, payment, refund, and tax data into a receipt PDF that can be emailed, stored, printed, or attached to a customer account without asking every caller to own PDF drawing code.

When to use this API

Your system already owns the payment status, receipt number, tax lines, and customer data.
You need a receipt PDF for email, account history, support workflows, or audit export.
You want QR codes or barcodes inside the receipt for lookup, refund, or pickup flows.
You need a stable receipt template after the layout is approved.

What it does not replace

You need payment processing or refund execution. gPdf renders the receipt; your payment system owns money movement.
You need legal e-invoice packaging. Use the E-Invoice Render endpoint for Factur-X or ZUGFeRD output.
You need POS hardware control or cash drawer logic.

Which endpoint to call

PRIMARY

/api/v1/pdf/render

JSON Render is the default path for this workflow.

SECONDARY 1

/api/v1/template-render

Use this when the workflow needs the related API path, template contract, or capabilities lookup.

Minimal request

POST /api/v1/pdf/render - compact receipt with a 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
        }
      ]
    }
  ]
}

What gPdf handles

Receipt page rendering from JSON Render payloads.
Text, totals, item lines, QR codes, barcodes, metadata, and optional PDF/A settings.
Template Render binding when the same receipt layout is reused.
Binary PDF output with the shared gPdf error envelope on failure.

What your system owns

Payment authorization, capture, refund, tax calculation, and receipt numbering.
Customer identity, order state, currency formatting, and retention policy.
Email delivery, account storage, and duplicate receipt handling.

Production checklist

Use a stable receipt number and pass an X-Request-Id with every render.
Decide whether receipts should be regenerated from source data or stored after the first render.
Test long item names, refunds, discounts, multi-tax lines, and zero-value orders.
Switch to Template Render once support and finance teams approve the layout.
Keep payment and tax decisions outside the rendering request.

Claim boundaries

gPdf does not process payments, calculate tax, or issue refunds.
A receipt PDF is not automatically a legal e-invoice.
Your system owns the business truth; gPdf renders the PDF representation.

Receipt PDFs are rendering outputs

This is not a separate payment or POS endpoint. Your ecommerce, billing, or POS backend decides that a receipt exists, then sends the receipt content to gPdf as a DocumentRequest or as data for a published template.

The rendering layer should stay deterministic. If a support agent requests the same receipt again, your system can either replay the source data or return a previously stored PDF according to your retention policy.

Template path for repeated receipts

Receipt layouts usually stabilize quickly. Once the design is approved, publish a template and call POST /api/v1/template-render with the receipt fields. That keeps payment systems focused on data and keeps layout ownership in one place.

FAQ

Can gPdf calculate the receipt total?: No. Your payment or commerce system owns totals, discounts, tax, and refund state. gPdf renders the values you send.
Should receipts use JSON Render or Template Render?: Use JSON Render while designing the layout. Use Template Render when the receipt layout and field contract are stable.
Can the receipt include a QR code?: Yes. gPdf supports QR code barcode elements in PDF output. Your system owns the URL or payload encoded in the QR code.
Is this the same as the e-invoice API?: No. Ordinary receipt PDFs use JSON Render or Template Render. Factur-X and ZUGFeRD packaging uses the E-Invoice Render endpoint.