Well, but then I do not suggest to use an address field.
That Field is made on purpose like that (with autosuggest) and if you do not use it, the address will be wrong either way later, as Google will guess them, unless you enter them (as existing) precisely.
And this, can be done in a simple text field, and that can be used as a input later, if you need it to be displayed on a map.
The map markers can take data from several things, not only native Address Fields.
But as said, that is the purpose of the field - we cannot change that.
What we eventually can, is split it in 3 sections as said:
- Text
- Lat/Long
- Map (with the drag and drop pin)
That does not mean that the fields will not get populated BTW, as they must be populated to work.
But, it would mean they more controllable, and you can insert where/which you want.
That solves no cost aspect, as that is not an opinion question, it depends on what Google charges, and they do charge by amount of requests - hence, to avoid that, you need to not use an Address Field.
You can save addresses in native Single Line Fields and used them on maps later.
It's the same process as With address fields, you just choose the other input in the Map shortcodes (see screenshot)
Of course, that field must hold a valid address (which is done for you automatically if using the Toolset Address field) and it then will of course produce a call to Google when displayed, on a map.
But at least with this you would avoid the MAP API being used (requested) on the Forms.
Is that a possible solution for you?