I'm trying to sign up for Openshift Online, and it wants my phone number. However, it identifies my Republic Wireless number as a VOIP number for whatever reason, and gives me an error that I need a different number. After 3 attempts, it says.
We're sorry for any difficulties you've encountered, but we're unable to further verify your account.
If you are having problems, please contact support.
I've contacted support, but I'm hoping there's an easier way. It's the same if I try to sign up for a $50 a month account.
FYI, the openshift support person was able to manually confirm my account and keep me moving. Just needed to open a ticket.
Related
For about a week now, it says:
Queued for provisioning
Due to an increase in OpenShift Online Starter popularity, please
expect a longer delay in account provisioning. You will receive an
email when there is enough capacity to add your account. Thank you for
your patience!
Two weeks!
It took two weeks for Red Hat to finally provision the account. Yesterday I finally received an email:
Your OpenShift Online account is ready!
Obviously I had already moved to another provider in the meantime.
(Note that the status page had not displayed any technical reasoning for the delays. It was "all green". It's pretty obvious that this is just tactics to avoid getting users on the free tier.)
I'm making a desktop app for a company, and they would like to get it featured in the windows app store for Windows 10 users.
The app will likely only work on desktop computers, it's not designed for mobile. What it does is perform lookups on lists of cell phone numbers, and outputs a spreadsheet with carrier info, and it requires a credit for each cell phone number looked up. The credits are bought in bulk through the company's sales team, there is no automated method to purchase them.
Because there is no automated system, it would be difficult to set up in-app purchases, also if Microsoft takes a cut of in-app payments then it wouldn't be feasible due to the tiny profit margin of the credits. But according to this (section 10.8.1), if the app consumes anything that has to be purchased then it needs to use the in-app purchasing api.
Does anyone know if there's some way around this? Or if it only applies to regular apps and not desktop only ones, which I understand are a different type of listing?
I realise I can get a developer account and go through this with them but I don't really want to spend this company's money on the dev account if Microsoft are just going to say no.
Thanks :)
That section of the policy refers to payments taken within the application.
It doesn't sound like what your application will do though. Your application is allowing the allocation (spending) of credits bought separately.
It's a small distinction but an important one. You may have seen other applications work around such limitations by requiring the user to go to a website to buy something and then return to the app to use it.
When submitting the app there is a declaration for "This app allows users to make purchases, but does not use the Windows Store commerce system." You can read more about this declaration at https://msdn.microsoft.com/en-us/library/windows/apps/mt148523.aspx but this shouldn't apply to your scenario.
There are potential legal implications here and if the company has any concerns about entering a legal agreement with Microsoft regarding financial matters then they should seek appropriate legal council. Having a developer ask other developers about legal matters is likely only suggest asking a lawyer.
I am creating an app with a Pro-feature which can be unlocked via in-app purchasing.
Is it possible to use the Windows Phone 8.1 Wallet API for creating a Voucher?
(As example for Reviewers or tester)
How can I ensure that the voucher can be used only by one person?
(maybe: can only be used for a particular LiveID)
Some recent changes here it seems. Microsoft now have a promo code system for Windows Phone, check this page : https://msdn.microsoft.com/library/windows/apps/mt297660.aspx
And it works for IAPs as well !
There isn't currently any voucher or promo-code system available for Windows Phone apps.
You could implement this yourself along with using the existing in-app purchase system. Check the code yourself and then enable the feature if either the code is present or if the in-app purchase was made.
Tying it to a login such as the LiveID would be a good way to lock it down to one person, especially if your app already has a login requirement. Another option would be to make the code one-use and then roam the unlocked status once it was set. That would let the first user to use the code use it on multiple devices so long as the app wasn't fully uninstalled or was used often enough to keep the roamed data alive.
Prepaid codes are frequent request on the Windows Platform Dev Feedback site. You can add your vote at http://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/2118985-prepaid-codes-for-wp-apps-promo-codes-for-review
I am testing my in-app purchases, I uploaded my app to the windows store as beta and made an in-app product.
I tried it out and noticed a bug, I want to reset the in app purchase(it is hide ads) but I am not sure how to do this.
I want it so it is like the user account that bought the in-app never actually bought it.
I am going to assume that you are talking about a durable in app purchase, since consumable purchases can be bought as many times as one wants.
Once a durable purchase is made, it is permanent to the account. A user could call customer service to have this reversed, but it is not common (I have done this).
However it is unlikely that a rep would reverse a free in app purchase for a beta app to assist in testing.
If you would like to test your app without having to deal with those issues, Microsoft has provided guidance in how to test in app purchases.
So far as i know, if someone bought something through store, he cannot actually get the money back. If you're releasing app, you should pre-test it to be 100% sure it's working. If you're not sure how is the in-app purchase working, there is a plenty of forum threads about how to do this efficiently. Long story short, if someone already bought this in-app feature, either you cannot block it to him or refund his money.
I'd recommend testing In App Purchases through the emulator. Every time you restart the emulator it's like booting up a fresh device, so you'll be able to purchase IAPs again.
I’m developing an app for Google Chrome and I would like to know how I can charge for it.
The problem is that I live on Brazil and on this link it tells that it doesn’t support the Chrome Web Store Payments. There is other way I can charge for that without the Chrome web store payment?
https://developers.google.com/chrome/web-store/docs/pricing#seller
My initial idea is to create a hosted app that is free (but limited) and the customer pays and can use it fully. Or the other idea is to give 30 days to try and the costumer need to pay only onetime if he likes it and can use it fully.
Do you guys know how to do that living in a country not supported by Chrome Web Store Payments?
Did you notice the text on https://developers.google.com/chrome/web-store/docs/pricing#seller which says "In the future, we expect to support sales to the following additional regions: Argentina, Brazil, India, Mexico, and Poland. Buyers in unsupported regions might be able to purchase apps, but they can't pay in their local currency and might have to pay international transaction fees."? Not sure if that means it would work for you or not.
Otherwise I'm pretty sure you're allowed to use other payment processors other than Chrome Web Store Payments (see https://ssl.gstatic.com/chrome/webstore/intl/en/dev_tos_text.html and https://ssl.gstatic.com/chrome/webstore/intl/en/program_policies.html), so you might see if other services like PayPal, Amazon payments, etc. are a better option for you.