The guide says that I need to declare the in app purchases (token, price, availability) in the submission process, but I can't for the life of me find it!
If it's a universal app, do I need to resubmit the Windows Store app (versus the Windows Phone app which is submitted separately) and put the In-App Purchases in there?
Does that mean that both Phone and Non-Phone apps have to have the same list of in-app purchases?
In the Windows Store dashboard, populating your list of in-app purchases is done from the Selling Details section early in the submission process. There's a link there near the top of the page, under "In-app Purchases" that says "Use the Windows Store in-app purchase system." This takes you to the page where you enter the purchase details.
In the Windows Phone Store dashboard, once you've created an app, go back to the dashboard home, click on the app under In-progress Submissions, and you'll see a page with a number of links/tabs: Lifecycle | Quick stats | Reviews | Pricing | Details | Products. Click on "Products" and you'll go to the place where you define in-app purchases.
You do need to create the in-app purchases separately on both dashboards, because you are submitting separate apps in the end. Each submission can therefore have its own list of in-app purchases, because clearly there are scenarios where you might have a purchase available on one platform but not the other.
Now if you have the apps in both stores associated with one another, i.e. you use the same app name and then associate them so they have the same package family name/ID, then you allow your customers to share in-app purchases between the two apps, provided that you use the same product ID for each. This way, the app ID + product ID uniquely identifies the in-app purchase for the user, so if the user has purchased it on one platform it's available on the other. If you use different product IDs, however, then you won't have that shared entitlement.
Note that it's the app ID + product ID that makes these shared entitlements: you can implement each app however you want, meaning that you don't have to use an universal app project. They must both be targeting the 8.1 platforms, however, because that's where this capability is enabled.
Related
Shopify is suitable for selling online services, tools or not? Is it possible to use Shopify in the same way as PayPal or any other payment processor, for example simple purchase flow:
1) user clicks the 'Buy' button,
2) page navigates to the Shopify product page where user has to pay (commit the purchase)
3) redirects back to the website with purchase confirmation and token - which is used to link it to the buyer (user that clicked the Buy button).
this should be common and pretty simple, though I couldn't find any tutorial or sample
Yes, it's possible.
Create a store, set up a payment processor, create a product that is (a service, a tool or whatever you want to sell) and you're ready to go.
Also, read bout selling services.
Yes, it is possible but shopify is mainly used for selling physical products.
You can use 'Digital download' apps on the Shopify AppStore. After the customer purchases your digital goods, it will show the download link to the customer. The official free shopify app is ok enough
If you're selling subscription, you can use subscription apps.
Personally, I prefer to use gumroad since it's solely used for selling digital services
I'm trying to build up an android platform that takes in user credit card info and charge it on use without inserting the credit card details after saving one. But I don't seem to actually see any possible work ways in the "In-App Payment" SDK and I think I see it under Square's java SDK. But as researched in github, their official reply is that I'm unable to use java SDK in android app.
So I'm trying to figure out has anyone done this before or face the same issue?
In-App Payments SDK is solely meant for generating a card nonce on your mobile application. All other API endpoints must be done on a server or service due to security reasons (you don't want to store your personal access token within your application). Once you have that nonce, you need a server or service running that your mobile application will talk to. Ie the most basic is passing the nonce to the Charge endpoint to charge a customer.
On that same note, we have another endpoint called CreateCustomerCard, which you can pass the nonce as well as customer_id to in order to save the card to this particular customer's profile. So, at the very least you'll need to create a customer in order to have their id.
For info around saving cards on file, see this post: Hot to generate card nonce for repeated transactions without making users to enter card details?
Background
My iOS app supports multiple user accounts, but the user can only be logged into one account at a time. The app also offers a subscription service ("credits" in the form of a renewable In-App Purchase).
I'm having trouble keeping the in-app subscriptions separated to the specific user account that bought them. If a user buys credits on Account One and then signs out, and another user signs into Account Two (on the same device), the SKPaymentQueue still proceeds with the renewal process for the purchases from Account One (and, consequently, triggers the logic that unlocks those credits).
Question
What is the correct method of handling renewable in-app purchases for an app that supports multiple accounts? Is there any way to keep purchases from "overflowing" into other accounts on the same device? What else should be kept in mind?
I'm pretty sure what you're trying to do isn't possible. In-app purchases are tied to the Apple ID that purchased them. That means that if the user is logged into an Apple ID that has purchased the subscription, you are always going to be told it is available. A single user can't purchase the same subscription multiple times. The only way would be to force an Apple ID change when they change users in your app, which I'm almost certain you can't do.
I already submit a application on app store which have price $6.99. Now I am submitting new version of this app. Here I want that iPhone user, which already installed this application, should pay $.99 for this update and new user should pay $6.99
Is it possible to charge extra amount for existing user for update ? Please suggest
No. Updates from the App Store are always free. If you wish to charge for additional content, you can use the In-App purchasing system.
Otherwise, your only option is to create an entirely new App for major updates if you wish to get more money from your users.
I am working on one app. In this app to buy some non digital items i have to give access to users to do transactions using credit card / debit card. I have seen some apps in app store which accepts credit card / debit card . Those apps are Pay Anywhere , Rev COIN.
1) Can we know which third party API's they are using. 2)While using these apps do we need any card reader(another device) to swipe the card.
As well how to get those API's. Can any one help me please. This plays majority role in my app. Any suggestions please.
Doing some transactions with ZOOZ are ok . But coming to my app i have one requirement. i.e user can send order for one item and user can say expiry time(i.e in how many days product has to be delivered) at the time of offering an item payment will be done. before delivering the product user can cancel the order. whenever the order is cancelled some amount has to be deducted and remaining has to be refunded.
For example user sending request for pepsi which is worth of 10$ and expiry time is 3days payment will be done immediately. Next day he may want to cancel the order in such a case user 2$ will be deducted and remaining 8$ has to be credited back to user account. Can we do any these type of transactions using some API's.
Zooz is one way that you can do in-app payments. It's supposed to be easy. That kind of model would be for you using an app as a kind of online "store" like amazon.
If you're talking about using an iOS device to record transactions (using a single unit as a cash-register system) then you would need a card swipe add-on unless you want the customer to input all of their credit information when they pay.
Or, as jgervin pointed out you could use card.io to let the users take a picture of their credit card. The company charges you per-scan however.
Important note: Apple will reject your app from the app-store. See the linked questions.
Pay for a physical product with in-app purchase
Has anyone implemented the PayPal API through a native iPhone app?
Which PayPal iPhone SDK should I use?
So hopefully you're planning to deploy with airwatch or something similar.