My app is dependent on Camera. We are showing alerts and live view of camera in app. User can purchase plans to enable AI feature on camera firmware and we are also providing cloud storage for history. So can we use other payment sdk other then Apple pay as our app is dependent on Camera(Hardware). We are not restricting any feature inside the app. All features are turn on on Camera firmware.
We want to use Third party payment gateway not Apple pay as our app is dependent on hardware.
Based on the description, your use case sounds like in-app purchase, which is different from Apple Pay. You can read this doc to learn the difference between Apple Pay and in-app purchase.
For in-app purchases, you have to use Apple's in-app purchase SDK.
Related
I have an app with Free, Premium and Gold subscription plan. Based on the plan user can access features like filters, messages, likes.
Now, I'm planning to have an web app only for payments using stripe. So, users will directed to web app to pay payments.
Will apple allow this approach or will they insist to use in-app purchase?
I'm little confused here. Need your suggestion here?
This is a question for Apple Review team, you should reach out to them directly and clarify. Stripe doesn't replace in-app purchases and you need to use Apple's API to perform in-app purchases. See here for details
We built an ecommerce platform (like a Shopify) that allows our customers - the merchants to accept payments for products.
As of now, all payments are accepted online. When they sign up to use our service, they also sign up for stripe and we process payments through their hosted form for ease of PCI Compliance.
In a live setting, many of our customers want to use a swiper to accept payments for their products rather than typing in a credit card number on a tablet.
Do you have any suggestions for a third party swiper provider with an API that we can integrate?
Stripe now offers its own set of supported EMV devices:
https://stripe.com/terminal
You can also use PayWorks or CardFlight (as of today) and can find those integrations here:
https://stripe.com/works-with/type/extension/category/card-readers
Lastly, if your'e just looking to use a magstripe reader, you should email into Support https://support.stripe.com/email for more guidance.
If you go out and look for how to process credit cards online, you will continuously get sent towards Paypal or Stripe (which are great options!). These have great features, including nice client UIs, but they don't always fit the problem domain.
I need to accept credit card payments to replace in-person payments for a business, which means no extra fees outside of what credit cards already charge. This is for both Canada and the USA.
Is there an established "best pick" for open source frameworks for handling credit card payments in Node and React?
To be clear, I am showing you one merchant that you can use. Whichever merchant your client is using now to take credit card payments will most likely have a REST API to use.
Most merchant service will have some sort of an API you can use. Since we do not know which merchant you are planning on using I will show you a popular one.
I have used authorize.net a lot in my career. They have a REST API you can consume to handle payments for your clients. The API has a SDK you can download for whichever language you want to use.
The developer portal is here.
You can see popular language examples here.
When you go to that last link click on code examples and pick the
language you want to see.
Here is the SDK repo for Node.js.
Find more SDKs on git and use them in your app!
Let me know if you have anymore questions.
I plan to use a 3rd party payment gateway for in-app purchases for an app distributed through the Google PlayStore. I'm aware of Google's policies regarding payments for in-app purchases (https://play.google.com/about/monetization-ads/payments/)
My content / service delivery model is as follows:
When a user pays for a plan he gets—
Certain features in the app
Certain features in our web portal, completely outside the app
Our deployment staff going and visiting the user's location and
providing training and setup services.
For some plans, we will be delivering a physical device to user's
locations (a POS machine to accept card payments)
Since my offerings are a combination of physical and digital goods and services provided within and outside the app, it does not clearly fall under the categories Google mentions in the link above.
My question is: Can I use a 3rd party payment gateway to accept payments within the app given my content / service delivery model?
Do I risk being blacklisted? Does Google give a time window to react by sending an email first before pulling apps down.
I know my question is similar to this one: Android In-app purchases and I'd like to get similar opinions on my planned content / service delivery model.
Kindle PlayStore app, distributed via Play Store also seems to be an example of an app using different payment method from Google's billing APIs
I'm building an application for a new small business. They run events at race tracks, and the application is a registration system for said events. As a small business the owner doesn't want to worry about handling people's credit card info. They are just starting up and we are building from the ground up. So we are looking at using third party services like Google Wallet and PayPal.
So looking at the documentation, we have the Instant Buy API. Seeing as we aren't planning on taking direct credit card payments, it seems like a pain to setup payment processing through another service to use the Instant Buy. But we aren't selling a "Digital Good", as far as I can tell (I haven't seen a documented definition for this), so does that mean we can't use the API for Digital Goods? I haven't found any documentation that lays this out as a policy. It seems like it would be a lot simpler to implement, even with the cut Google takes.
There is a page at the google wallet documentation site called Which API Should I Use?, the first item there is:
The quick answer: it depends on your goals, your platform and what
kind of goods or services you're selling. The Instant Buy APIs are for
selling physical goods, while digital goods sellers should use the
Google Wallet for Digital Goods API for web apps or Google Play In-app
Billing for Android for native Android apps. To engage your customers
with offers and loyalty programs, use the Wallet Objects API.
Now, the Instant Buy APIs are for those business that have an existing payment gateway setup, but need to offer Google Wallet as a payment option.
In your situation, as you don't have a payment processor setup:
To sell physical goods on web apps and mobile apps that run on
browsers, use Instant Buy for web. You'll keep your existing payment
processor and optimize your payment flow with Google Wallet, just like
with Android. You can use Instant Buy for web to sell digital goods,
but if you lack a payment processor or resources to maintain and
develop a PCI-compliant online store, you should use the Google Wallet
for Digital Goods API.