Sending fees via API: integration and testing in sandbox

Sending daily receipts via API is one of the central nodes for software houses, POS providers, and developers who need to design systems compliant with the new Italian and European digital fiscalisation rules. The point is not just about "sending data", but doing so stably, verifiably, and without interrupting existing flows. Before go-live in production, a reliable testing phase is recommended. In this scenario, a sandbox is the context where the integration is actually built: it is there that authentication, data transmission, and receipt management are verified before impacting actual production systems. 

In this guide, we will look at how API integration for electronic daily receipts works, what the fundamental steps are, and why the electronic invoicing test environment we offer at A-Cube is crucial for reducing errors and accelerating processes.

Why use a sandbox environment before go-live

When sending daily receipts via API, even a minor discrepancy can generate cascading errors in the operational workflow. It is a matter of data reliability, synchronisation, and managing edge cases. A simple inaccuracy in transmission or a misaligned configuration between modules is enough to block an entire operational workflow. And this is precisely where the test environment for electronic invoicing becomes a necessary tool. Inside a sandbox, you can work realistically but without risks to: 

• simulate real transactions and verify end-to-end flows; 

• check the communication between PEM and PEL; 

• validate daily receipts webhooks and notifications; 

• test cancellations and returns; 

• verify data consistency before production. 

In practice, this is the time when the actual friction of integration is discovered before it becomes a problem in production. This approach significantly reduces risks during the go-live of the fiscal integration and allows the technical team to reach the release stage with greater control over system behaviour.

Sending daily receipts via API: how the architecture works

The model for sending daily receipts via API is based on a two-tier architecture, introduced by the legislation on software-based electronic daily receipts: PEM and PEL. Two distinct components working together to manage the issuance, validation, and transmission of fiscal documents.

PEM: Point of Emission (Punto di Emissione)

The PEM is where the data is "born". It collects transaction information from the cash point or payment system and generates the commercial document, applying the electronic signature. In practice, it integrates directly with digital POS, tablets, retail systems, or e-commerce platforms where the sale takes place.

PEL: Point of Processing (Punto di Elaborazione)

The PEL takes charge of what the PEM produces. It verifies the integrity of the document, checks data consistency, and manages transmission to the Revenue Agency (Agenzia delle Entrate). It is also the point where the flow is tracked and rendered compliant from a regulatory perspective. A-Cube's electronic daily receipts APIs connect these two tiers into a single infrastructure. This allows software houses and POS providers to focus on integration, reducing the complexity of the underlying fiscal management. To learn more about the operational models, you can also read this guide.

How to start integrating the electronic daily receipts API

The first step to working with the ecosystem is to create an account in the A-Cube sandbox environment. From here, you can access the dashboard and obtain the credentials needed to start calling the APIs.

Authentication and JWT tokens

Access to the api-based daily receipts transmission services takes place via a dedicated endpoint. After logging in, the system returns a JWT token that becomes the key for all subsequent calls. This model allows for the secure management of all operations related to software-based electronic daily receipts, maintaining control over accesses and sessions.

Merchant creation and PEM activation

Once authenticated, the typical flow involves:

• merchant creation; 

• PEM generation; 

• module activation; 

• digital cash register association. 

Each step is exposed via documented REST endpoints. Furthermore, the platform returns unique identifiers that allow tracking the status of operations clearly. The daily receipts API documentation includes complete examples for different languages, which are useful during the real integration phase.

Daily receipts webhooks and flow monitoring

When working on a fiscal integration, the value is not just in sending data, but in being able to understand what happens next. In the daily receipts API transmission flow, webhooks serve precisely this purpose: they notify transaction statuses, transmission outcomes, and potential errors in real time. For developers, this translates into a concrete advantage: less polling, fewer manual checks, and less repetitive debugging.

In parallel, the dashboard allows filtering documents and flows by status, date, or type, making the verification phase easier during testing.

Testing returns and cancellations in a sandbox environment

A complete integration does not just concern the moment of sale, but also everything that can happen at a later stage. For this reason, it is essential to also test cancellations, returns, transmission errors, PDF document retrieval, and temporary flow misalignments. The sandbox allows simulating these scenarios without impacting real data or production systems. This enables the development team to observe the integration's behaviour for sending daily receipts via API under controlled conditions. The result is a concrete reduction in risks during go-live for fiscal integration and greater stability in the early stages of production.

Invoicing recorder and POS system integration

The model introduced by the new technical specifications for sending daily receipts via API is progressively reducing dependence on traditional physical cash recorders (registratori telematici). Today, the electronic recorder integration can take place directly via software, using APIs and certified components compatible with advanced POS, softPOS, and cloud architectures. 

For software houses and payment providers, this brings benefits such as less dependence on hardware and lower maintenance complexity. Not to mention faster product evolution and easier scalability across different markets. The API-first approach also makes integration with pre-existing systems more natural.

Sending daily receipts via API: why test before production

Sending daily receipts via API is not just a matter of technical implementation, but of system reliability over time. The A-Cube platform supports both aspects, with technical documentation, operational sandboxes, and modules compliant with the specifications of each country in which it operates. 

Want to verify the flow before go-live? You can test authentication, webhooks, and document transmission directly in our sandbox.