Handling API response errors, how to display error messages AND keep the form page without the confirmation window, as well as not saving the data in Entries

I’ve developed a form specifically tailored for inputting client registration data to be transmitted via API to a third party. Below, I’ve detailed the overarching objective I aim to accomplish:

1. Currently, I’m grappling with displaying API errors directly within the form interface. My goal is to initiate a form submission error, exhibit the error message itself, and highlight the field necessitating correction. I’ll discuss two hooks I’ve employed for this purpose. Despite scouring through all available documentation, I haven’t identified a suitable hook for this task. Any recommendations or guidance to steer me in the right direction would be greatly appreciated.

2. Additionally, I’ve encountered an issue where Entries are generated in both scenarios. I’ve set the Email field to be unique, but when errors arise in other fields, subsequent submissions throw an error related to the Email field, as the address already exists in the database. I would be grateful if you could furnish a functional code example for deleting the record.

3. My experimentation with various hooks has led me to scrutinize the functionality of the ‘gform_confirmation’ hook. Unfortunately, I find its behavior unsatisfactory, as it replaces my form with its own confirmation. Furthermore, if there’s an error in one field, the logic of the confirmation isn’t coherent. A PopUp would offer a more preferable solution.

4. Furthermore, I’ve attempted to integrate validation with ‘gform_after_submission’, but I’ve encountered difficulty in displaying form submission errors through this hook. Even when deliberately triggering an API error, all submissions register as successful, disregarding the code, and storing the data in Entries.

5. The intended task involves a multi-page form structure, yet I’ve hit a snag at the initial step, constructing it as a single form for testing purposes. In essence, the logical flow of the form should entail: the client inputs data → selects a tariff plan → verifies their card → signs the agreement → reviews the receipt and entered data → and, contingent upon the tariff, they may either make an immediate payment or receive a payment invoice within 5 days. The submission of the first step should precede the agreement signing.

All custom validation handling can be done via the gform_validation filter.