MANSOQ NPHIES
Retry a transport failure without creating a duplicate
Replay the persisted NPHIES transaction only under the correct response and channel policy.
Current source · source reviewed · 6 min read
Before you begin
- Original persisted exchange and attempt history.
- Classified transport failure and the authorized integration replay path.
1. Confirm the failure category
Review whether the remote server failed, the response could not be stored, or the transaction received a business/adjudication decision. Do not apply transport replay to every unsuccessful business result.
2. Use persisted identity and bytes
The NPHIES retry service reads the original Bundle.id, MessageHeader.id and request payload. It refuses identity regeneration and changed payload under the same replay.
3. Replay through the endpoint workflow
Use the environment-checked integration replay operation. Record attempts and inspect the returned result before initiating another retry.
4. Review duplicate-related responses
Known duplicate-identifier contradictions are retained as idempotent-replay evidence for onboarding review rather than automatically treated as a provider defect.
Channel-specific behavior
The identical-payload retry mandate is specific to NPHIES. The source explicitly rejects applying it as a generic rule to ZATCA document recovery.
Cancellation instead of deletion
A persisted transaction is not deleted to withdraw it. Use the supported cancellation mechanism and its linked reversal/confirmation evidence.
Troubleshooting
Replay refuses payload drift
Do not force changed bytes under the old identity. Reclassify whether a correction or new business request is required and follow that supported transaction chain.
Source evidence
References are pinned to the private MANSOQ source repository. Repository access is required to open these links.