Fatturazione e finanza

API per PDF di ricevuta per pagamenti ecommerce e SaaS

Genera PDF di ricevute da dati di ordine, pagamento, imposte e rimborso, con QR code, codici a barre, impostazioni PDF/A e output template ripetibile.

API PRINCIPALE JSON Render
ENDPOINT /api/v1/pdf/render
SISTEMI backend ecommerce / backend di fatturazione / piattaforma SaaS / servizio export POS
Lavoro da svolgere

Trasformare dati di ordine completato, pagamento, rimborso e imposte in una ricevuta PDF che può essere inviata via email, archiviata, stampata o allegata a un account cliente senza chiedere a ogni sistema chiamante di possedere codice di disegno PDF.

Quando usare questa API

  • Il vostro sistema possiede già stato del pagamento, numero ricevuta, righe fiscali e dati cliente.
  • Vi serve una ricevuta PDF per email, storico account, processi di supporto o esportazioni di audit.
  • Volete QR code o codici a barre dentro la ricevuta per ricerca, rimborso o ritiro.
  • Vi serve un template ricevuta stabile dopo l'approvazione del layout.

Cosa non sostituisce

  • Vi serve elaborazione dei pagamenti o esecuzione dei rimborsi. gPdf renderizza la ricevuta; il vostro sistema di pagamento possiede i movimenti di denaro.
  • Vi serve packaging di fattura elettronica legale. Usate l'endpoint E-Invoice Render per output Factur-X o ZUGFeRD.
  • Vi serve controllo hardware POS o logica del cassetto contanti.

Quale endpoint chiamare

PRIMARIO

/api/v1/pdf/render

JSON Render è il percorso predefinito per questo flusso.

SECONDARIO 1

/api/v1/template-render

Usalo quando il flusso richiede l'API collegata, un contratto di template o una verifica delle capacità.

Request minimo

POST /api/v1/pdf/render - ricevuta compatta con QR code di ricerca.

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

Cosa gestisce gPdf

  • Rendering di pagine ricevuta da contenuti JSON Render.
  • Testo, totali, righe articolo, QR code, codici a barre, metadati e impostazioni PDF/A opzionali.
  • Associazione Template Render quando viene riusato lo stesso layout ricevuta.
  • Output PDF binario con envelope di errore gPdf condiviso in caso di fallimento.

Cosa controlla il tuo sistema

  • Autorizzazione pagamento, capture, rimborso, calcolo fiscale e numerazione ricevuta.
  • Identità cliente, stato ordine, formattazione valuta e criteri di conservazione.
  • Consegna email, archiviazione account e gestione dei duplicati di ricevuta.

Checklist di produzione

  1. Usate un numero ricevuta stabile e passate un X-Request-Id a ogni rendering.
  2. Decidete se rigenerare le ricevute dai dati sorgente o salvarle dopo il primo rendering.
  3. Testate nomi articolo lunghi, rimborsi, sconti, più righe fiscali e ordini a valore zero.
  4. Passate a Template Render quando supporto e finance approvano il layout.
  5. Tenete decisioni di pagamento e fiscali fuori dalla richiesta di rendering.

Limiti della promessa

  • gPdf non elabora pagamenti, non calcola imposte e non emette rimborsi.
  • Una ricevuta PDF non è automaticamente una fattura elettronica legale.
  • Il vostro sistema possiede la verità di business; gPdf renderizza la rappresentazione PDF.

I PDF di ricevuta sono output di rendering

Questo non è un endpoint separato per pagamenti o POS. Il vostro backend ecommerce, di fatturazione o POS decide che una ricevuta esiste, poi invia a gPdf il contenuto della ricevuta come DocumentRequest o come data per un template pubblicato.

Il livello di rendering dovrebbe restare deterministico. Se un agente del supporto richiede di nuovo la stessa ricevuta, il vostro sistema può riprodurre i dati sorgente oppure restituire un PDF già salvato, secondo i vostri criteri di conservazione.

Percorso template per ricevute ripetute

I layout delle ricevute di solito si stabilizzano rapidamente. Una volta approvato il design, pubblicate un template e chiamate POST /api/v1/template-render con i campi della ricevuta. Così i sistemi di pagamento restano concentrati sui dati e la responsabilità del layout rimane in un unico punto.

FAQ

gPdf può calcolare il totale della ricevuta?
No. Il vostro sistema di pagamento o commerce possiede totali, sconti, imposte e stato del rimborso. gPdf renderizza i valori che inviate.
Le ricevute dovrebbero usare JSON Render o Template Render?
Usate JSON Render mentre progettate il layout. Usate Template Render quando layout ricevuta e contratto dei campi sono stabili.
La ricevuta può includere un QR code?
Sì. gPdf supporta elementi codice a barre QR code nell'output PDF. Il vostro sistema possiede l'URL o il contenuto codificato nel QR code.
È la stessa cosa dell'API per fattura elettronica?
No. Le ricevute PDF ordinarie usano JSON Render o Template Render. Il packaging Factur-X e ZUGFeRD usa l'endpoint E-Invoice Render.