Facturación y finanzas

API de recibos PDF para pagos ecommerce y SaaS

Genere recibos PDF desde datos de pedido, pago, impuestos y reembolso, con códigos QR, códigos de barras, ajustes PDF/A y salida de plantilla repetible.

API PRINCIPAL JSON Render
ENDPOINT /api/v1/pdf/render
SISTEMAS backend ecommerce / backend de facturación / plataforma SaaS / servicio de exportación POS
Trabajo a resolver

Convertir datos de pedido completado, pago, reembolso e impuestos en un recibo PDF que pueda enviarse por email, almacenarse, imprimirse o adjuntarse a una cuenta de cliente sin obligar a cada cliente a mantener código de dibujo PDF.

Cuándo usar esta API

  • Su sistema ya controla el estado del pago, número de recibo, líneas de impuestos y datos del cliente.
  • Necesita un recibo PDF para email, historial de cuenta, soporte o exportación de auditoría.
  • Quiere incluir códigos QR o códigos de barras en el recibo para búsqueda, reembolso o recogida.
  • Necesita una plantilla de recibo estable después de aprobar el diseño.

Qué no sustituye

  • Necesita procesamiento de pagos o ejecución de reembolsos. gPdf renderiza el recibo; su sistema de pagos controla el movimiento de dinero.
  • Necesita empaquetado legal de factura electrónica. Use el endpoint E-Invoice Render para salida Factur-X o ZUGFeRD.
  • Necesita control de hardware POS o lógica de caja registradora.

Qué endpoint llamar

PRINCIPAL

/api/v1/pdf/render

JSON Render es la ruta predeterminada para este flujo.

SECUNDARIO 1

/api/v1/template-render

Úsalo cuando el flujo necesite la ruta API relacionada, un contrato de plantilla o una consulta de capacidades.

Solicitud mínima

POST /api/v1/pdf/render - recibo compacto con un código QR de búsqueda.

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

Qué gestiona gPdf

  • Renderizado de páginas de recibo desde datos de JSON Render.
  • Texto, totales, líneas de artículos, códigos QR, códigos de barras, metadatos y ajustes PDF/A opcionales.
  • Vinculación con Template Render cuando se reutiliza el mismo diseño de recibo.
  • Salida PDF binaria con el envoltorio de errores compartido de gPdf en caso de fallo.

Qué controla su sistema

  • Autorización de pago, captura, reembolso, cálculo de impuestos y numeración de recibos.
  • Identidad del cliente, estado del pedido, formato de moneda y política de retención.
  • Entrega por email, almacenamiento en cuenta y manejo de recibos duplicados.

Checklist de producción

  1. Use un número de recibo estable y pase un X-Request-Id en cada renderizado.
  2. Decida si los recibos deben regenerarse desde datos fuente o almacenarse después del primer renderizado.
  3. Pruebe nombres de artículo largos, reembolsos, descuentos, varias líneas de impuestos y pedidos de valor cero.
  4. Pase a Template Render cuando los equipos de soporte y finanzas aprueben el diseño.
  5. Mantenga las decisiones de pago e impuestos fuera de la solicitud de renderizado.

Límites de la promesa

  • gPdf no procesa pagos, no calcula impuestos ni emite reembolsos.
  • Un recibo PDF no es automáticamente una factura electrónica legal.
  • Su sistema controla la verdad empresarial; gPdf renderiza la representación PDF.

Los recibos PDF son salidas de renderizado

No es un endpoint separado de pagos o POS. Su backend ecommerce, de facturación o POS decide que existe un recibo y luego envía el contenido del recibo a gPdf como DocumentRequest o como datos para una plantilla publicada.

La capa de renderizado debe seguir siendo determinista. Si un agente de soporte solicita el mismo recibo de nuevo, su sistema puede reproducir los datos fuente o devolver un PDF previamente almacenado según su política de retención.

Ruta de plantillas para recibos repetidos

Los diseños de recibo suelen estabilizarse rápido. Una vez aprobado el diseño, publique una plantilla y llame a POST /api/v1/template-render con los campos del recibo. Así los sistemas de pago se concentran en los datos y la propiedad del diseño queda en un solo lugar.

FAQ

¿gPdf puede calcular el total del recibo?
No. Su sistema de pagos o comercio controla totales, descuentos, impuestos y estado de reembolso. gPdf renderiza los valores que usted envía.
¿Los recibos deberían usar JSON Render o Template Render?
Use JSON Render mientras diseña la composición. Use Template Render cuando el diseño del recibo y el contrato de campos sean estables.
¿El recibo puede incluir un código QR?
Sí. gPdf admite elementos de código de barras QR en la salida PDF. Su sistema controla la URL o los datos codificados en el QR.
¿Es lo mismo que la API de factura electrónica?
No. Los recibos PDF ordinarios usan JSON Render o Template Render. El empaquetado Factur-X y ZUGFeRD usa el endpoint E-Invoice Render.