In early August I put together a fake order for a fictional customer, left test mode on, and the provider returned a real, signed electronic invoice. Of those three things, only the invoice existed for the National Superintendency of Customs and Tax Administration (SUNAT), Peru's tax authority. It used up a serial number, and the sequential numbering SUNAT requires never gets recycled. It was the first test of the direct invoicing integration in LENZ Service, our camera repair shop. I voided it by hand that same afternoon.
We pulled out the middleman and trusted a flag
Until that day, invoicing went through a middle service we had put in the path ourselves. We pulled it out to call the provider's API directly and have one place to check when an invoice comes out wrong. The issue button kept test mode on by default, and I assumed, like the rest of the team, that this per-order flag decided whether the document was real.
The API ignored the flag and said nothing
The first thing I checked was the field name, convinced we had spelled it wrong. It was spelled fine. The API returned no error and no warning, and the document stayed valid for SUNAT. The documentation said so in plain words; I just hadn't read it. The environment comes from the taxpayer account's configuration, which you change by hand in the provider's panel, and ours was set to production.
It's like writing "VOID, PRACTICE ONLY" in the memo line of a check and trusting that. The bank reads the account and the amount, and pays. If you want to know whether the check is real, you call the bank and ask which account it came from.
The crude lock I put in that night
The mitigation was ugly on purpose: while the local configuration says "test", the code blocks issuing completely. I preferred to leave the repair shop without a button for a few days over risking a second tax document born from a test.
v1 let me rehearse without signing anything
When the provider published their v1 API I swapped the lock for something with judgment. v1 has a dry-run endpoint, a mock issue that runs every validator without issuing or using up a serial number. Another call validates the access token and answers which environment that account is in. Idempotency keys are now mandatory too: a unique identifier per order, so a retry doesn't create a second invoice.
That last part came from another scar. With the previous integration we issued a real duplicate because of an ambiguous timeout, the kind where you don't know whether the document went out or not, and a duplicate only gets fixed with a credit note. Now the key derives from the order, always the same, and the provider returns it in ambiguous errors so the retry reuses it.
79 of 79 and zero invoices created
I verified the full migration to v1 against the real API, with a real payment and without creating a single tax document. The provider calculated the same taxable base and the same Value Added Tax (IGV) as our system, and the suite closed at 79 of 79 tests green.
If the provider doesn't answer, the shop doesn't invoice
The gate depends on the token check answering. With no answer there is no confirmed environment, and the system blocks issuing until the provider comes back. I accept that cost. The environment switch still sits in their panel, outside our code, and all we can do there is look.
Before every issue, the system asks the provider which environment the account is in and compares it with its own configuration. If the two answers don't match, it issues nothing. The fictional customer is still fictional, and since that afternoon so are his invoices.
