PTPAYContact

Payment + fiscal orchestration infrastructure

One integration.
Every payment flow.

Connect POS systems, payment providers and fiscalization through one API.

  1. Odoo

    Odoo sends one sale request to PTPAY with an idempotency key.

  2. PTPAY

    PTPAY validates the sale, attaches a correlation ID and routes it to the configured provider.

  3. Viva.com

    Viva.com runs the card payment on the merchant's terminal.

  4. APPROVED

    The provider's final result is confirmed and stored as the payment status.

  5. Fiscalization

    Only after payment is settled, the receipt is registered through eKasa — a separate fiscal status.

  6. Receipt

    Fiscal receipt data returns through PTPAY to Odoo for printing.

01 — One API

Integrate once. Not once per provider.

Every payment provider and every fiscal system has its own protocol, certification path and failure modes. PTPAY absorbs them behind one stable contract, so a POS or ERP team builds a single integration and keeps it.

Without PTPAY

Every system × every provider.

With PTPAY

Every system × one API.

POST /v1/salesrequest
Authorization: Bearer ptpay_live_••••
Idempotency-Key: ord-2026-000184
X-Correlation-ID: 7c1e…

{
  "paymentMethod": "CARD",
  "terminalId": "trm_…",
  "amount": 1250,
  "currency": "EUR",
  "fiscalize": true
}

→ paymentStatus · fiscalStatus · overallStatus

02 — Payment orchestration

Provider-neutral by architecture.

Each terminal is bound to a provider in configuration, not in the merchant's code. PTPAY routes the transaction, normalizes the result and never turns an uncertain outcome into a guessed one — an unconfirmed payment stays UNKNOWN until the provider confirms it.

PTPAYViva.comIn developmentGlobal PaymentsAvailableTapayaPlannedFuture providersPlanned

03 — Payment + fiscalization

Two statuses. One transaction.

Getting paid and issuing a legal receipt are different events that can fail independently. PTPAY tracks them separately and orchestrates them as one sale — a fiscal error never makes a paid sale look unpaid.

CARD

  1. POS
  2. PTPAY
  3. Payment provider
  4. APPROVED
  5. Fiscalization
  6. Receipt

Fiscalization starts only after the provider confirms the payment.

CASH

  1. POS
  2. PTPAY
  3. Fiscalization
  4. Receipt

No payment provider is called. The cash payment is recorded, then fiscalized.

paymentStatusAPPROVED
fiscalStatusFISCALIZED
overallStatusCOMPLETED

04 — Integrations

An ecosystem around one layer.

AvailableIn developmentPlanned

Business systems · POS

  • OdooAvailable
  • BookioPlanned
  • PTPAY POSPlanned
  • Custom POSAvailable
  • API integrationsAvailable

Payment providers

  • Viva.comIn development
  • Global PaymentsAvailable
  • TapayaPlanned
  • Future providersPlanned

Fiscal systems

  • eKasaAvailable
  • Future fiscal systemsPlanned

Statuses reflect the current state of development. "In development" means implementation or controlled testing is under way — not production availability.

05 — For developers

Built API-first.

Unified sales API

One request for card or cash sales, with optional fiscalization and line-item VAT.

Payments

Create, read, cancel and refund payments through one provider-neutral resource.

Fiscalization

Fiscal receipts as a first-class resource with their own lifecycle and status.

Idempotency

Idempotency-Key on every write. Retries return the original result, never a duplicate.

Correlation IDs

X-Correlation-ID follows each request across PTPAY and provider calls.

Secure authentication

Hashed, scoped, revocable keys isolated per merchant and environment, with rate limits.

Base URL https://api.ptpay.io/v1 · API documentation is shared with integration partners. Request access

Talk to us about an integration.

partners@ptpay.io