We have a similar requirement for mobile applications that we deploy in the field. Frequently, users are in areas with bad connectivity so we had to think through this very problem. Here's our solution:
When the user submits data remove any option to do anything else until the app receives a response - I know this sounds like a no brainer, but it's one of those things that sometimes can get glossed over. In times when we need high data integrity, sometimes we need to take control away from the user for a bit. This can be in the form of a loading message that covers the screen (this is what we do), disabling buttons, etc.
Immediately present the user with an error that blocks further action - This ensures that they are aware of the error and allows you as a developer to control the flow of the conversation in such an event.
On error, have a high speed process that checks submission - Whenever our app detects an error, there is a follow-up process that gets called immediately that effectively performs a check for the submitted data. The results are communicated to the user. If this fails we write to a local queue for future processing.
Write to a local queue for processing - When all else fails, we write the data to a local queue in an encrypted store on the device to await future processing. The app will do periodic check-ins with the APIs to check for availability and resubmit/perform checks as soon as connectivity is good enough. The queue is available to the user to see and manage and the user receives notifications once records have been confirmed as submitted.
Your process is probably a bit different, but those are some of the steps we've take to mitigate network errors.