As others mentioned here,Â with the current behavior the apps haveÂ an opportunity to communicate with the user about their decision and maybe get them to accept the charge. That is what we currently have in place and get results.Â The least is that we could record the activation status as "Declined" and start internal processes to react to the event. The new behavior will break this process and the subscription request will be hanging in the air without aÂ status update!
How about adding an optional "decline_url" parameter to the subscription authorization to allow the apps optionally handle the decline? AndÂ if the decline_url parameters is not provided, Shopify would execute the new behavior that's announced here.Â This way you can make sure that if the URL is provided, there is proper communcation and handling of the decline in place.Â
Thank you for all your feedback, we will evaluate appropriately in regards to providing more information around free trials and why an app charge was declined. As per the updated post we feel this is an important change in order to keep this flow controlled and consistent for all merchants within Shopify.
Hi I want to ask for clarification about the meaning of confirmation_url.
Currently when a merchant is prompted to confirm an app charge and declines, the merchant is redirected to the confirmation_url provided by the developer.
This is what I see from documentation and I want to ask two questions.
confirmation_url: The URL where the merchant accepts or declines the recurring application charge.
return_url: The URL where the merchant is redirected after accepting or declining the charge.
1. Is confirmation_url in this post means the return_url in the doc?
2. If merchant accept the charge, will merchant be redirected to the url (return_url) provided by app developer?
We can see in our analytics at the moment that it's pretty common for merchants to see the confirm app charge screen, push decline, search for more info about the app and then push accept all in a short space of time.
This change dumps the merchant back at the app index page - very jarring UX and a step back in clarity for the user.
A parallel in my mind is the checkout process of a shop. It's also very common here for the user to go back a step before eventually completing payment when they're comfortable.
The equivalent UX for a checkout process would be if the user pushes back from the payment screen they're dumped at the homepage of the shop with an empty cart.
"We’ve made this update to [...] save app developers time in having to create a redirect page."
This change may be progress for app developers who do not handle the declined charges redirect (a missed conversion saving opportunity!) but it is a big step back for those of us who do.
"We’ve made this update to keep this workflow uniform and consistent for merchants ..."
It does make it uniform and consistent. However it is a confusing dead end workflow with the merchant being dumped in a place they may never even have started from (the app index page).
The UX of the most common use case we see with our app: confirm app screen > decline > search for information > accept, is a lot worse with this change.
The documentation is going to be updated to communicate this in time of this feature release. Once the feature is released this will be the update:
Here the confirmation_url is the url that will be returned by Shopify where the merchant will either accept or decline the charge.
The return_url is the url provided by the app developer where the merchant will be redirected to upon accepting a charge.
Whenever the charge is declined Shopify will always redirect the merchant back to the App Index page within the merchants Admin.
How is this going to work for an app that is free to use but allows the merchant to make various in-App purchases using the ApplicationCharge resource?
In this case it is inappropriate for the user to be knocked out of the app. They may simply be looking to update their cart with a different or additional in-App purchase. Much different scenario than approving/declining a revolving fee or one-time only fee.
Fully agree with Daniel Sim. Every self-respecting developer has already handled this situation with cancellation of charge. This is no simplification for developers, this is a limitation.
We used a dialog for users who declined charge and suggest a discount. Now it is impossible to do. Our work is lost and our users no longer have the opportunity to get a discount.
Do not do it this way anymore. We are very disappointed by this update.