Skip to content

OpenCart · through the API

OpenCart fiscalization in Serbia: fiscal receipts through the BokaPOS API

OpenCart extensions bind to events, so fiscalization is one extension that calls the BokaPOS API on the order status change. BokaPOS does not ship an OpenCart extension; a developer builds one around the API, usually in a day.

OpenCart stores in Serbia follow the same fiscalization rules as any web shop. An approved ESIR issues the receipt through the V-PFR and the customer receives it electronically.

The example below is the same call for every platform: a token, then one POST /v1/fiscal-documents with the order's idempotency key. The complete documentation with examples in five languages is on the API page.

Where the integration hooks in

The extension registers the event OpenCart emits when a status history entry is added to an order. At the chosen status the extension builds the request from items, discounts, shipping and payment, calls BokaPOS and stores the PFR number, link and status in its own table. For a refund the admin enters the buyer identification and the extension sends a fiscal refund.

Integration steps

Effort
Typically one developer day for someone who knows OpenCart extensions, plus refund testing.

  1. Account and sandbox

    Request BokaPOS access: sandbox credentials and a test security element are free.

  2. Extension settings

    Client id and secret, taxpayer and premise, the triggering status, the mapping of tax classes to labels from GET /v1/tax-rates and of payment methods to the seven official payment types.

  3. Event on the status

    At the status send POST /v1/fiscal-documents with an idempotency key from the order id. Show the result in the admin order view.

  4. Receipt to the customer

    Attach the PDF from /representations/ to the OpenCart e-mail or switch on the BokaPOS E-mail module.

  5. Refunds and production

    A refund sends a fiscal refund with the reference and buyer identification. After the tests you switch to production credentials.

The same call for every platform

curl -X POST "https://auth.bokapos.rs/realms/boka/protocol/openid-connect/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=$BOKAPOS_CLIENT_ID" \
  -d "client_secret=$BOKAPOS_CLIENT_SECRET"

curl -X POST "https://api.bokapos.rs/v1/fiscal-documents" \
  -H "Authorization: Bearer $BOKAPOS_TOKEN" \
  -H "Idempotency-Key: order-4127-sale-1" \
  -H "Content-Type: application/json" \
  -d '{
  "taxpayerId": "3f9c2a8e-6b1d-4e5a-9c47-1d2b8e6f0a11",
  "businessPremiseId": "b7d4e2c1-9a3f-4c8e-8f21-6e5a0c9d3b22",
  "clientReference": "ORDER-4127",
  "invoiceType": "NORMAL",
  "transactionType": "SALE",
  "cashier": {
    "id": "web-shop",
    "displayName": "Web shop"
  },
  "items": [
    {
      "name": "Bluetooth slušalice",
      "unitOfMeasure": "kom",
      "quantity": 1,
      "unitPrice": 8990,
      "gtin": "8606012345678",
      "taxLabels": [
        "F"
      ]
    }
  ],
  "payments": [
    {
      "type": "CARD",
      "amount": 8990
    }
  ],
  "metadata": {
    "orderId": "4127",
    "channel": "web"
  }
}'

API documentation

Frequently asked questions

Does BokaPOS have a ready-made OpenCart extension?

Not today. The API is documented with PHP examples and the sandbox is free, so a developer builds the extension in a day.

Does it work the same for OpenCart 3 and 4?

The principle is the same: status change event, one API call, storing the response. Only the way the extension is registered differs between versions.

How is the receipt sent to the customer?

As a PDF attachment or a link in the e-mail. In an electronic document the QR code is replaced by the Tax Administration verification link.

What about cash on delivery?

Cash on delivery is cash; the receipt is issued at delivery, so the extension fiscalizes at the delivered status, not when the order is placed.

Ready to fiscalizefrom your own system?

The sandbox is free, and you issue your first receipt the same day.