Чи може gPdf розрахувати суму квитанції?

Ні. Ваша платіжна система або система електронної комерції відповідає за підсумки, знижки, податок і стан повернення коштів. gPdf рендерить значення, які ви надсилаєте.

Квитанції мають використовувати JSON Render чи Template Render?

Використовуйте JSON Render, доки проєктується макет. Використовуйте Template Render, коли макет квитанції й контракт полів стабільні.

Чи може квитанція містити QR-код?

Так. gPdf підтримує елементи QR-коду в PDF-виводі. Ваша система відповідає за URL або дані, закодовані в QR-коді.

Це те саме, що e-invoice API?

Ні. Звичайні PDF квитанцій використовують JSON Render або Template Render. Пакування Factur-X і ZUGFeRD використовує маршрут E-Invoice Render.

Рахунки та фінанси

Receipt PDF API для електронної комерції й SaaS-платежів

Генеруйте PDF квитанцій із даних замовлення, платежу, податку й повернення коштів із QR-кодами, штрихкодами, налаштуваннями PDF/A та повторюваним template-виводом.

ОСНОВНА API JSON Render

ШЛЯХ API /api/v1/pdf/render

СИСТЕМИ бекенд електронної комерції / білінговий бекенд / SaaS-платформа / сервіс POS-експорту

Спробувати в Playground Читати документацію

Задача сценарію

Перетворити дані завершеного замовлення, платежу, повернення коштів і податків на PDF квитанції, який можна надіслати email, зберегти, надрукувати або прикріпити до облікового запису клієнта, не змушуючи кожен сервіс-викликач володіти кодом малювання PDF.

Коли використовувати цю API

Ваша система вже відповідає за статус платежу, номер квитанції, податкові рядки й дані клієнта.
Потрібен PDF квитанції для email, історії акаунта, процесів підтримки або аудиторського експорту.
Потрібні QR-коди або штрихкоди всередині квитанції для пошуку, повернення коштів або процесів самовивозу.
Потрібен стабільний шаблон квитанції після затвердження макета.

Що вона не замінює

Потрібна обробка платежів або виконання повернення коштів. gPdf рендерить квитанцію; рух грошей належить вашій платіжній системі.
Потрібне юридичне пакування електронного рахунку. Для виводу Factur-X або ZUGFeRD використовуйте E-Invoice Render.
Потрібне керування POS-обладнанням або логіка касової шухляди.

Який шлях API викликати

ОСНОВНИЙ

/api/v1/pdf/render

JSON Render — типовий шлях для цього сценарію.

ДОДАТКОВИЙ 1

/api/v1/template-render

Використовуйте, коли сценарію потрібен пов’язаний API-шлях, контракт шаблону або перевірка можливостей.

Мінімальний запит

POST /api/v1/pdf/render - компактна квитанція з QR-кодом для пошуку.

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

Що виконує gPdf

Рендеринг сторінки квитанції з тіла запиту JSON Render.
Текст, підсумки, рядки товарів, QR-коди, штрихкоди, метадані та необов’язкові налаштування PDF/A.
Прив’язку Template Render, коли той самий макет квитанції використовується повторно.
Бінарний PDF-вивід зі спільним конвертом помилок gPdf у разі збою.

Що контролює ваша система

Авторизацію платежу, списання, повернення коштів, розрахунок податку й нумерацію квитанцій.
Ідентичність клієнта, стан замовлення, форматування валюти й політику зберігання.
Email-доставку, зберігання в акаунті й обробку дублікатів квитанцій.

Чеклист для робочого запуску

Використовуйте стабільний номер квитанції та передавайте X-Request-Id у кожному render.
Вирішіть, чи квитанції потрібно повторно генерувати з вихідних даних, чи зберігати після першого рендера.
Тестуйте довгі назви товарів, refund, знижки, кілька податкових рядків і замовлення з нульовою сумою.
Перейдіть на Template Render після затвердження макета support і фінансовими командами.
Тримайте платіжні й податкові рішення поза запитом рендерингу.

Межі заявлених можливостей

gPdf не обробляє платежі, не розраховує податок і не виконує refund.
PDF квитанції не стає автоматично юридичним електронним рахунком.
Ваша система володіє бізнес-істиною; gPdf рендерить її PDF-представлення.

PDF квитанцій — це вивід рендерингу

Це не окремий платіжний або POS-маршрут API. Ваш бекенд електронної комерції, білінгу або POS вирішує, що квитанція існує, а потім надсилає її вміст у gPdf як DocumentRequest або як data для опублікованого шаблону.

Шар рендерингу має залишатися детермінованим. Якщо support-агент знову запитує ту саму квитанцію, ваша система може або повторити вихідні дані, або повернути раніше збережений PDF відповідно до політики зберігання.

Шлях Template Render для повторюваних квитанцій

Макети квитанцій зазвичай швидко стабілізуються. Після затвердження дизайну опублікуйте шаблон і викликайте POST /api/v1/template-render з полями квитанції. Це залишає платіжні системи сфокусованими на даних, а відповідальність за макет — в одному місці.

FAQ

Чи може gPdf розрахувати суму квитанції?: Ні. Ваша платіжна система або система електронної комерції відповідає за підсумки, знижки, податок і стан повернення коштів. gPdf рендерить значення, які ви надсилаєте.
Квитанції мають використовувати JSON Render чи Template Render?: Використовуйте JSON Render, доки проєктується макет. Використовуйте Template Render, коли макет квитанції й контракт полів стабільні.
Чи може квитанція містити QR-код?: Так. gPdf підтримує елементи QR-коду в PDF-виводі. Ваша система відповідає за URL або дані, закодовані в QR-коді.
Це те саме, що e-invoice API?: Ні. Звичайні PDF квитанцій використовують JSON Render або Template Render. Пакування Factur-X і ZUGFeRD використовує маршрут E-Invoice Render.