Facturatie en finance

Betaalbewijs-PDF-API voor e-commerce en SaaS-betalingen

Genereer betaalbewijs-PDF's uit order-, betalings-, belasting- en terugbetalingsdata met QR-codes, barcodes, PDF/A-instellingen en herhaalbare sjabloonoutput.

PRIMAIRE API JSON Render
ENDPOINT /api/v1/pdf/render
SYSTEMEN e-commercebackend / facturatiebackend / SaaS-platform / POS-exportservice
Taak om op te lossen

Zet afgeronde order-, betalings-, terugbetalings- en belastingdata om naar een betaalbewijs-PDF die kan worden gemaild, opgeslagen, afgedrukt of aan een klantaccount gekoppeld, zonder dat elk aanroepend systeem PDF-tekenlogica hoeft te beheren.

Wanneer deze API past

  • Uw systeem beheert al de betalingsstatus, het betaalbewijsnummer, belastingregels en klantgegevens.
  • U hebt een betaalbewijs-PDF nodig voor e-mail, accounthistorie, supportprocessen of auditexport.
  • U wilt QR-codes of barcodes in het betaalbewijs opnemen voor opzoeken, terugbetaling of afhaalprocessen.
  • U hebt een stabiel betaalbewijssjabloon nodig nadat de lay-out is goedgekeurd.

Wat dit niet vervangt

  • U hebt betalingsverwerking of uitvoering van terugbetalingen nodig. gPdf rendert het betaalbewijs; uw betaalsysteem beheert geldstromen.
  • U hebt juridische E-Invoice-packaging nodig. Gebruik het E-Invoice Render-endpoint voor Factur-X- of ZUGFeRD-output.
  • U hebt POS-hardwarebesturing of kassalade-logica nodig.

Welk endpoint aanroepen

PRIMAIR

/api/v1/pdf/render

JSON Render is het standaardpad voor deze workflow.

SECUNDAIR 1

/api/v1/template-render

Gebruik dit wanneer de workflow een verwant API-pad, templatecontract of capability lookup nodig heeft.

Minimale request

POST /api/v1/pdf/render - compact betaalbewijs met een QR-code voor opzoeken.

{
  "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
        }
      ]
    }
  ]
}

Wat gPdf afhandelt

  • Rendering van betaalbewijspagina's vanuit JSON Render-requestdata.
  • Tekst, totalen, artikelregels, QR-codes, barcodes, metadata en optionele PDF/A-instellingen.
  • Template Render-binding wanneer dezelfde lay-out voor betaalbewijzen opnieuw wordt gebruikt.
  • Binaire PDF-output met de gedeelde gPdf-foutstructuur bij mislukte requests.

Wat uw systeem beheert

  • Betalingsautorisatie, capture, terugbetaling, belastingberekening en nummering van betaalbewijzen.
  • Klantidentiteit, orderstatus, valutaweergave en bewaarbeleid.
  • E-mailaflevering, opslag in accounts en afhandeling van dubbele betaalbewijzen.

Productiechecklist

  1. Gebruik een stabiel betaalbewijsnummer en stuur bij elke render een X-Request-Id mee.
  2. Bepaal of betaalbewijzen opnieuw uit brondata worden gegenereerd of na de eerste render worden opgeslagen.
  3. Test lange artikelnamen, terugbetalingen, kortingen, meerdere belastingregels en orders met nulwaarde.
  4. Schakel over naar Template Render zodra support- en financiële teams de lay-out goedkeuren.
  5. Houd betalings- en belastingbeslissingen buiten de renderrequest.

Grenzen van de claim

  • gPdf verwerkt geen betalingen, berekent geen belasting en voert geen terugbetalingen uit.
  • Een betaalbewijs-PDF is niet automatisch een juridische E-Invoice.
  • Uw systeem beheert de zakelijke waarheid; gPdf rendert de PDF-weergave.

Betaalbewijs-PDF’s zijn renderoutput

Dit is geen apart endpoint voor betalingen of POS-systemen. Uw e-commerce-, facturatie- of POS-backend bepaalt dat een betaalbewijs bestaat en stuurt de inhoud vervolgens naar gPdf als DocumentRequest of als data voor een gepubliceerd sjabloon.

De renderlaag moet deterministisch blijven. Als een supportmedewerker hetzelfde betaalbewijs opnieuw opvraagt, kan uw systeem de brondata opnieuw afspelen of een eerder opgeslagen PDF teruggeven volgens uw bewaarbeleid.

Sjabloonpad voor terugkerende betaalbewijzen

Lay-outs voor betaalbewijzen stabiliseren meestal snel. Publiceer na goedkeuring van het ontwerp een sjabloon en roep POST /api/v1/template-render aan met de velden voor het betaalbewijs. Zo blijven betaalsystemen gericht op data en ligt het beheer van de lay-out op één plek.

FAQ

Kan gPdf het totaal van het betaalbewijs berekenen?
Nee. Uw betaal- of commercesysteem beheert totalen, kortingen, belasting en terugbetalingsstatus. gPdf rendert de waarden die u verstuurt.
Moeten betaalbewijzen JSON Render of Template Render gebruiken?
Gebruik JSON Render tijdens het ontwerpen van de lay-out. Gebruik Template Render wanneer de lay-out en het veldcontract voor betaalbewijzen stabiel zijn.
Kan het betaalbewijs een QR-code bevatten?
Ja. gPdf ondersteunt QR-codebarcode-elementen in PDF-output. Uw systeem beheert de URL of waarde die in de QR-code wordt gecodeerd.
Is dit hetzelfde als de E-Invoice-API?
Nee. Gewone betaalbewijs-PDF's gebruiken JSON Render of Template Render. Factur-X- en ZUGFeRD-packaging gebruikt het E-Invoice Render-endpoint.