POS ZATCA Integration

Give each POS sale a traceable invoice lifecycle

Connect branch, device, transaction, retry, artifact, and final known state for online and interrupted flows.

Built for

The team that must operate the integration.

Engineering, product, finance-systems, and operations teams building Saudi invoice workflows into software they already operate.

Start from published paths, request identity, explicit lifecycle state, and artifacts rather than an opaque integration project.

Separate invalid input, definite failure, retryable transport errors, unknown outcomes, and reconciliation work.

Keep the request ID, idempotency key, invoice artifacts, webhook events, usage, and support context attached to one operation.

Implementation path

Define invoice type, legal-entity context, source identifier, and the stable operation identity.

Exercise the documented TechnoMinds contract without implying external ZATCA acceptance or production access.

Persist request IDs, verify webhooks, reuse idempotency keys, and reconcile uncertainty before another external effect.

Move beyond synthetic behavior only after customer credentials, external prerequisites, and technical evidence are verified.

Questions

Availability and external prerequisites stay explicit throughout evaluation.

Does the public sandbox submit invoices to ZATCA?+

No. It is TechnoMinds-operated and synthetic. Responses identify production_access as false.

Can we keep our current ERP, POS, or application UI?+

Yes. These API patterns are intended to sit behind existing product and finance workflows.

Is production activated automatically after signup?+

No. Production eligibility and external credentials are separate from sandbox activation.

Continue with a real next step