When I install the plugin by passing the MERCHANT_ID variable I don't see why it makes sense to add MERCHANT_ID, INDUSTRY_TYPE_ID and WEBSITE to the txnRequest. This plugin could auto-add those fields internally.
If the goal of keeping these fields present was to allow a user to be able to copy-paste the code easily into their editor to generate checksum easily, a helper function could be introduces instead which returns the formatted txnRequest to pass into the server checksum handler (after stripping the ENVIRONMENT key or even checksum in case someone adds that unknowingly if present).
This also reduces chances of error. I found for example that when I switched from staging to production I didn't properly uninstall the plugin and iOS was making a staging copy of the www folder which had the older key present that was originally in the config.xml. So, my request was having the new key and the plugin used the old key leading to checksum failures.
When I install the plugin by passing the MERCHANT_ID variable I don't see why it makes sense to add MERCHANT_ID, INDUSTRY_TYPE_ID and WEBSITE to the txnRequest. This plugin could auto-add those fields internally.
If the goal of keeping these fields present was to allow a user to be able to copy-paste the code easily into their editor to generate checksum easily, a helper function could be introduces instead which returns the formatted txnRequest to pass into the server checksum handler (after stripping the ENVIRONMENT key or even checksum in case someone adds that unknowingly if present).
This also reduces chances of error. I found for example that when I switched from staging to production I didn't properly uninstall the plugin and iOS was making a staging copy of the www folder which had the older key present that was originally in the config.xml. So, my request was having the new key and the plugin used the old key leading to checksum failures.