Hi Jerry,
I think we might be looking at some confusion with how the form is supposed to work, coupled with a little bit of possibly confusing interface, sprinkled with a dash of possible bugs.
I'm first going to try to explain how the manage form works, and then hopefully you can follow up with feedback about what methods work for you once you know how it's supposed to operate.
If the problem is just that you're confused by the way they're operating, that's good feedback for us so that we can hopefully make it more intuitive. If the problem is that we confused you with incorrect information in the documentation or elsewhere, that's something we can fix as well. And, if the problem is just that it's broken, well, we'll definitely fix that.
Hopefully, together we can get it working for you, or if not, at least figure out why it won't work for your application so that we can suggest future improvements.
Manage Profiles Form
We've got forms for managing profiles, adding payment profiles or shipping profiles, and editing payment profiles or shipping profiles. The first one we'll look at is the manage profiles form. This is what you're seeing, I assume:
No master confirm or cancel buttons on this form itself. However, each payment profile or shipping profile will have edit or delete buttons that interact with that part of the profile.
Once you add a payment profile or shipping profile, or edit an existing profile, then you get a button at the bottom that takes the browser to the "hostedProfileReturnUrl" address sent with the token request:
There shouldn't need to be any sort of master "confirm" or "save" button for the form as a whole, because changes are saved when individual profiles are edited. If a customer gets this form and makes a change, they then just click the button to indicate they're finished with the form and want to return.
Where this falls down, however, is the scenario where the customer is presented this form and decides not to make any changes. At that point, if you brought it up in a lightbox or in an iframe, you can have your own controls to put up a close box or a cancel button. However, the merchant doing a straight redirect is going to have a problem in this scenario. (There's another problem where if the only edit is a change to the expiration date, that doesn't trigger the hostedProfileReturnUrl button to show up.)
I'll definitely look into this further to see if this behavior is by design. If not, we'll fix it. If so, we'll talk about how to improve it.
Other forms
We've also got forms for editing specific profiles or adding new profiles:
- Add Payment Profile https://accept.authorize.net/customer/addPayment
- Add Shipping Profile https://accept.authorize.net/customer/addShipping
- Edit Payment Profile https://accept.authorize.net/customer/editPayment
- Edit Shipping Profile https://accept.authorize.net/customer/editShipping
Those forms do have Save/Cancel buttons, because they're just operating on a particular piece, so you have a simpler flow with those.
Now, having said all this, you're using the form as an iframe, correct? In that case, the documentation indicates that you shouldn't even send the hostedProfileReturnUrl value, so I would expect you would never get the return button to show up. In that case, I guess it's up to you to provide some way to close or break out of the iframe. Is that possible?
hostedProfileManageOptions
As far as not showing the shipping profiles, this works correctly for me in my testing. Make sure you're sending that as part of the token request, not as part of the form submission. Just include something like this in your token request:
<setting>
<settingName>hostedProfileManageOptions</settingName>
<settingValue>showPayment</settingValue>
</setting>Make sure that each settingName and settingValue is in a seperate <setting> element. If that's not working for you, can you copy and paste the whole request?
