Hamza Enterprise: FBR invoices at sale time

01 /The problem

Staff already run a POS under pressure. Adding FBR after closing means missed invoices, mismatched totals, and a tax trail that does not match the till. The integration had to sit on the sale itself, not in a back-office batch that nobody remembers to run.

FBR’s authorization API is unforgiving: payloads, item codes, and timing have to be right or the invoice is not fiscal. Failures needed to be visible at the counter, not buried in a log.

02 /Integration & implementation

The Laravel POS posts to FBR as part of completing a sale. On success, the system stores the fiscal identifiers and prints / PDFs an invoice the customer can take — sales report in real time instead of a night-end dump.

Error paths are first-class: if authorization fails, the cashier sees it immediately so the shop does not silently accumulate non-compliant tickets. Line items, discounts, and payments stay aligned with what FBR received.

03 /My responsibility

I worked on the Laravel POS backend and FBR integration, connecting the sale workflow to invoice authorization and storing the returned fiscal identifiers. The integration needed to make failures visible to the cashier and keep invoice data aligned with the transaction.

04 /Operational considerations

A sale-time integration puts an external API on the operational path. Visible authorization failures matter because staff need to know whether an invoice was accepted. The engineering lesson is to treat the response and invoice record as part of the sale workflow, rather than treating an HTTP request alone as a completed integration.

05 /Result

Invoice authorization and fiscal identifiers are connected to the POS sale record, reducing separate invoice handling and keeping the transaction and its invoice together.