Hi Support,
We’re testing the full onboarding + invoicing flow against Sandbox and have hit a blocker with Production CSID issuance.
Can we Test Non VAT Customers Invoices on Sandbox. ?
Flow followed:
POST /compliancewith a fresh CSR (unique EGS Serial Number, unique VAT/branch identity) → returns200 OK,ISSUED, valid Compliance CSID.POST /compliance/invoiceswith signed Standard + Simplified sample invoices → returns200 OK, compliance checks pass.POST /production/csidswith the resultingcompliance_request_id→ returns200 OK,dispositionMessage: ISSUED, a newbinarySecurityToken/secret.
Issue: the certificate inside that returned binarySecurityToken does not correspond to our submitted CSR at all. Decoding it shows:
- A different EGS identity embedded in the SAN (
1-TST|2-TST|3-...) than what we submitted. - A different Location/Industry than what we submitted.
- The exact same certificate (same serial, same validity window
2024-01-11to2029-01-09) returned across multiple different branches/CSRs/EGS serials we tested — it never changes regardless of input.
Impact: since this certificate doesn’t match our actual signing key, every real invoice submission using it fails at /invoices/reporting/single with:
publicKey_QRCODE_INVALID, invalid-certificate, certificate-hashing, certificate-signing-time-format.
Notably, /invoices/clearance/single (Standard invoices) succeeds, because Standard invoices don’t include QR Tag 9 (Cryptographic Stamp). Simplified invoices always include Tag 9, so they’re the only ones that expose this mismatch.
Question: is /production/csids in the Sandbox environment expected to issue a certificate matching the submitted CSR, or does it always return a fixed/shared demo certificate for this environment? If the latter, how are we meant to test real Simplified/Reporting invoice submission end-to-end in Sandbox?
We’re testing using the documented dummy VAT number 399999999900003 from your Developer Portal Manual — happy to provide full request/response logs if useful.
Thank you.