Currently we end up with two links in the left navigation, one goes to the old style in-app payments, one goes to the new style. Both are still valid: https://www.dropbox.com/s/p18h9cbuakwrxya/Screenshot%202014-08-28%2011.03.31.png?dl=0 Its not clear what the difference is or which one I can use. I'm thinking we should merge two, call the link "In-App Payments". It then points to page that links onwards to the two sub pages. We can help developers out here by describing that: * they have a hosted app (so can only use the old style in some situations) * they have a packaged app (so can only use the old style in some situations) * they have a packaged app with the SystemXHR permission (so can use the new style in some situations) And then provide links on to those management screens. Let's also include links to the MDN docs so that users can get detailed and localised information. The more I've started to think about the harder the explaining that SystemXHR requirement does become and I worry about that. cc'ing Bram to see if he has any good wordsmithing or great ideas for this page.
I haven’t touched in-app payments in a while, so I didn’t know about the old vs. new-style divergence, and unaware of the situations. What are the differences between the old and the new? Is the new interface more capable, or are they two approaches to solving the same problem? Since the page is split between old and new, can’t we show the appropriate page – and hide the irrelevant one – to where appropriate? The logic goes like this. If my permissions field contains SystemXHR, I will be shown the new page. Otherwise, I’m shown the old one. Coming from somebody uneducated in the subtleties of the system, I do think that it’s a little much to expect developers to find SystemXHR, a little field in a remote place, in order to trigger a change in the interface. But maybe discoverability is not the issue here.
I think merging the two into one page would be ok. Here are some notes: - the old system is lower level which means it is more flexible but requires more customization. It is still useful for anyone who is trying to port an existing system to Firefox OS or for someone who wants complete control over their catalog of products. - the new system is only available to packaged apps because our target is a developer who doesn't want to host their own server or have to write a lot of custom code. - the systemXHR permission is just a minor detail; no packaged app can communicate with any remote API without it. - we should probably open up the new system to hosted apps; there's no hard requirement here.
Sounds good. Rather than showing old and new page when the situation calls for it, we’re going to merge the two interfaces into one page. Is there one-to-one correspondence between old and new UIs? What happens if I’m on the new interface but wants to be more flexible? Can I do a “Show more options…” or “Show advanced settings” to access them? Is that even a possible scenario to begin with? It would help me greatly if I could get a few screenshots – or better yet, an allizom-style access to the UIs. Either way, if opening up a new system doesn’t introduce added complexity for hosted apps, we should do it.
Hey Bram. If you make an account here you can upload an app and configure it for payments https://payments-alt.allizom.org/developers/ Alternatively, you could make an account and needinfo me with the email address and I'll make you an admin account. That way you can view payment setup for existing test apps.
Thanks, Kumar. Could you make me an admin account? I already have one set up under ‘email@example.com’ on payments-alt.allizom.
Done. As an admin you should be able to view this paid app that I created recently: https://payments-alt.allizom.org/developers/app/boku-bango-test-boar4485/payments/ (I think). I'm not sure if that helps you do research. Let me know if you have questions.
I saw the same thing when submitting a sample app to the test site yesterday. I wonder how the two pages will look when I’ve created in-app products? If they’re not that different, and we can merge the two together.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.