Rechnungen und Finanzen

Beleg-PDF-API für E-Commerce- und SaaS-Zahlungen

Erzeugen Sie Beleg-PDFs aus Bestell-, Zahlungs-, Steuer- und Rückerstattungsdaten mit QR-Codes, Barcodes, PDF/A-Einstellungen und wiederholbarer Template-Ausgabe.

PRIMÄRE API JSON Render
ENDPOINT /api/v1/pdf/render
SYSTEME E-Commerce-Backend / Abrechnungs-Backend / SaaS-Plattform / POS-Exportservice
Aufgabe im Workflow

Abgeschlossene Bestell-, Zahlungs-, Rückerstattungs- und Steuerdaten in ein Beleg-PDF umwandeln, das per E-Mail versendet, gespeichert, gedruckt oder einem Kundenkonto angehängt werden kann, ohne dass jeder Aufrufer PDF-Zeichencode besitzen muss.

Wann diese API passt

  • Ihr System besitzt Zahlungsstatus, Belegnummer, Steuerzeilen und Kundendaten bereits.
  • Sie benötigen ein Beleg-PDF für E-Mail, Kontohistorie, Support-Workflows oder Audit-Export.
  • Sie möchten QR-Codes oder Barcodes im Beleg für Lookup-, Refund- oder Pickup-Flows.
  • Sie benötigen nach Layoutfreigabe ein stabiles Beleg-Template.

Was sie nicht ersetzt

  • Sie benötigen Zahlungsabwicklung oder Rückerstattungsausführung. gPdf rendert den Beleg; Ihr Zahlungssystem bewegt das Geld.
  • Sie benötigen rechtliche E-Rechnungspaketierung. Nutzen Sie den E-Invoice Render-Endpunkt für Factur-X- oder ZUGFeRD-Ausgabe.
  • Sie benötigen POS-Hardwaresteuerung oder Kassenschubladenlogik.

Welchen Endpoint aufrufen

PRIMÄR

/api/v1/pdf/render

JSON Render ist der Standardpfad für diesen Workflow.

SEKUNDÄR 1

/api/v1/template-render

Nutzen Sie dies, wenn der Workflow den zugehörigen API-Pfad, einen Template-Vertrag oder eine Capability-Abfrage braucht.

Minimaler Request

POST /api/v1/pdf/render - kompakter Beleg mit 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
        }
      ]
    }
  ]
}

Was gPdf übernimmt

  • Rendering von Belegseiten aus JSON-Render-Nutzdaten.
  • Text, Summen, Artikelzeilen, QR-Codes, Barcodes, Metadaten und optionale PDF/A-Einstellungen.
  • Template-Render-Bindung, wenn dasselbe Beleglayout wiederverwendet wird.
  • Binäre PDF-Ausgabe mit gemeinsamem gPdf-Fehlerumschlag bei Fehlern.

Was Ihr System verantwortet

  • Zahlungsautorisierung, Capture, Rückerstattung, Steuerberechnung und Belegnummerierung.
  • Kundenidentität, Bestellstatus, Währungsformatierung und Aufbewahrungs-Policy.
  • E-Mail-Zustellung, Kontospeicherung und Umgang mit Duplikatbelegen.

Produktions-Checkliste

  1. Nutzen Sie eine stabile Belegnummer und senden Sie bei jedem Rendern einen X-Request-Id.
  2. Entscheiden Sie, ob Belege aus Quelldaten neu erzeugt oder nach dem ersten Rendern gespeichert werden.
  3. Testen Sie lange Artikelnamen, Rückerstattungen, Rabatte, mehrere Steuerzeilen und Nullwertbestellungen.
  4. Wechseln Sie zu Template Render, sobald Support- und Finanzteams das Layout freigeben.
  5. Halten Sie Zahlungs- und Steuerentscheidungen außerhalb des Rendering-Requests.

Aussagegrenzen

  • gPdf verarbeitet keine Zahlungen, berechnet keine Steuern und führt keine Rückerstattungen aus.
  • Ein Beleg-PDF ist nicht automatisch eine rechtliche E-Rechnung.
  • Ihr System besitzt die geschäftliche Wahrheit; gPdf rendert die PDF-Darstellung.

Beleg-PDFs sind Rendering-Ausgaben

Das ist kein separater Zahlungs- oder POS-Endpunkt. Ihr E-Commerce-, Abrechnungs- oder POS-Backend entscheidet, dass ein Beleg existiert, und sendet den Beleginhalt dann als DocumentRequest oder als Daten für eine veröffentlichte Vorlage an gPdf.

Die Rendering-Schicht sollte deterministisch bleiben. Wenn ein Support-Agent denselben Beleg erneut anfordert, kann Ihr System je nach Aufbewahrungs-Policy entweder die Quelldaten erneut abspielen oder ein zuvor gespeichertes PDF zurückgeben.

Template-Pfad für wiederkehrende Belege

Beleglayouts stabilisieren sich meist schnell. Sobald das Design freigegeben ist, veröffentlichen Sie ein Template und rufen POST /api/v1/template-render mit den Belegfeldern auf. So bleiben Zahlungssysteme auf Daten fokussiert, und Layoutverantwortung bleibt an einer Stelle.

FAQ

Kann gPdf die Belegsumme berechnen?
Nein. Ihr Zahlungs- oder Commerce-System besitzt Summen, Rabatte, Steuern und Rückerstattungsstatus. gPdf rendert die Werte, die Sie senden.
Sollten Belege JSON Render oder Template Render nutzen?
Nutzen Sie JSON Render beim Entwerfen des Layouts. Nutzen Sie Template Render, wenn Beleglayout und Feldvertrag stabil sind.
Kann der Beleg einen QR-Code enthalten?
Ja. gPdf unterstützt QR-Code-Barcode-Elemente in der PDF-Ausgabe. Ihr System verantwortet die URL oder Nutzdaten, die im QR-Code codiert werden.
Ist das dasselbe wie die E-Rechnungs-API?
Nein. Normale Beleg-PDFs nutzen JSON Render oder Template Render. Factur-X- und ZUGFeRD-Paketierung nutzt den E-Invoice Render-Endpunkt.