Just wanted to ensure that I have to use ClientID from app that I'm creating on dashboard and if I want to have pay later widget to use multiple languages I have to create multiple apps for each account and switch their id. Am I right?
Related
I am working on a Flutter app where users are grouped in organizations. I want every user to be able to pay a sum for their choice to their organization. I have read, that there are two types of apps (projects) one can create in a PayPal Developer account: "Merchant" and "Platform".
Platform type allows multiple sellers or beneficiaries within one app. This seems to be a reasonable solution for my problem. Now, I'm wondering if I can achieve the same (or similar) results but with Google Pay and Apple Pay instead of PayPal. Can I specify different beneficiaries for different transactions within one Flutter app?
I am planning to integrate payment within my property buying selling app created with flutter.
The user will see list of property, but he wont able to see who has posted the property and cannot contact him .He need to pay an amount to know the user who has posted that post and after paying the amount he can see who is owner of that post and contact him.
I am confused that, can i use other payment method for this purpose or i need to use google in app payment method only for it.
The app is providing service to let buyer connect with consumers by paying an amount and after they pay amount they can see the user who has posted the post, and connect with them for actual buying/selling of that property.
Can I use other payment provider like revenuecat or gpay or any other.
pls tell ?
I am planning to launch a new advertising website where people can create an account, buy advertisements (banners, text, links, etc), see details on their account dashboard, etc. There will also be a section where the ads will be displayed and people who created accounts can consume and use the ads there.
It's a simple model that I have used before with paypal services for more than 8 months.
Now, the new thing that I want to introduce is something called "shares". What I mean by this is, that people can load money to buy that "shares" and get a pack of ads according to the amount they paid. (I could give more details if necessary).
Can I implement this model securely with PayPal?
I am making a restaurant application in which the user can select any food item and our application needs to charge as per the food item selected. But I am confused as we cannot use INApp for this so what should be the best option for my application keeping in mind with apple document.And finally i dont want to use paypal also.
Apple will not allow you to use their In App Purchase API to pay for real-world goods.
Your only option is to use a web view to display a web-based payment system of your choosing, or use another payment API such as Paypal (which you have already expressed you don't want to use).
I'm a product manager who works for a small internet company that is developing an iPhone application for a social network. We monetize by offering limited and premium memberships to users (premium members get additional features not available to limited members). For billing on the web, we use a 3rd-party payment gateway that is nearing retirement, and will be replaced by an in-house solution.
The business wants a global launch for our iPhone app using iTunes + in-app purchasing as a payment gateway. The problem with going global using this payment method is that for our web service membership level, available features, and subscription costs are defined by country. For example, in the US premium/limited memberships are available at 5 pricing tiers; in France premium/limited memberships are available at 5 different pricing tiers from the US; and in Chile the service is available for free and all features are available to users.
Is it possible then to have the server-side, based on the user's country of registration, control the level of access, features, and payment options for users on the iPhone? I'd also note that since iTunes Connect does not allow variable pricing by currency and country, each "region" would need 5 in app purchase options.
I argued for a US-only launch for iPhone using iTunes in app purchase until an in-house payment gateway is available. But you know...
"Is it possible then to have the server-side, based on the user's country of registration, control the level of access, features, and payment options for users on the iPhone?"
Yes, assuming you can get a reliably country of registration.
Once the server/application has the data, it can do pretty much whatever it wants with it, no? If the purchase happens in-app, then it is under your control. Only show/accept the payment options you want. If the features are only exposed from within/by the app, then it is under your control. Only show/allow the features you want. Well, if the above assumption holds anyway.
Of course, such conditionals do make the entire package more complex.