We need to get in touch with our payment provider to find out whether we can provide a target URL for the cancel button. This should be testable using the wikimedia theme in our test account.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | gabriel-wmde | T143108 Payment provider cancel buttons lead to prefilled donation form | |||
| Resolved | kai.nissen | T167296 Research micropayment back button configurability |
Event Timeline
Comment Actions
The cancel URL in the production account is set to https://spenden.wikimedia.de/spenden, yet just the button's type attribute is set to reset (which just resets the form to its initial values). The (short) documentation in the payment method configuration states, this this can only be used when using their themes ("This option can only be used for the X-series standard optimised web solution. "). I asked them to clarify this.
Comment Actions
Good that we split that out into a dedicated task - can take a fine time waiting for the change...
What would be our desired target state? A mini form with just the button, action pointing to us, POST type, and some hidden fields containing the (encrypted) donation id?
Comment Actions
Why not GET? I was thinking about a URL containing both the donation ID and the access token.
Comment Actions
Not opposing GET - just that people are normally scared of "unprotected" information in query strings, while POST conveniently hides it... If the payload is small (as in our case) it may be more convenient, and in line with the successful return URLs, right?
Comment Actions
Our payment provider offers to change the URL of the cancel button to the value that is defined in the account settings (including the parameters that were passed when calling the payment iframe).