Our customers want to apply the following scenario for the app:
The user taps "Pay" in the app.
The app (or backend) gets the card info from the user's ApplePay account.
Card info is being used to perform a payment in another payment system.
I'm 90% sure Apple doesn't let to do this, but I can't find any docs.
This isn't possible: it goes against the whole point of having a payment system that obscures payment information from the merchant. Plus there's a million business reasons for the payment provider not to do this (and especially Apple, given that your client's requirement is likely to circumvent the huge commission they take on in-app purchases.)
There don't seem to be any docs on this (probably because it is so obvious that it's not an option) but there is this on the official Apple Pay website:
Your card number is never stored on your device, and when you pay your debit or credit card numbers are never sent to merchants. Apple Pay assigns a unique number for each purchase, so your payments stay private and secure.
Related
We would like to implement a payment solution where end users can send money to other users, merchants (e.g Walmart, shop vendors).
(Payment service to send money to shop vendors (e.g Wallmart), Person, POS)
e.g Nowadays we send money via NFC, by scanning QR Code, etc.
Is there any possibility to implement such solutions?
General Application flow:
Customer registers on the app.
Connect their bank account, add their Debit Card.
Can pay to anyone via NFC, scanning QR code.
I didn't find anything yet but exploring: https://developer.mastercard.com/
Your thoughts?
We found a 3rd party service (Card issuing) Marqeta to solve our problem. Using the API we can do the following:
We can issue cards to Users (Virtual, Tokenized, Physical)
Users can push cards to Google Pay, Apply Pay to use NFC payments.
We can keep track of transactions made by the issued cards.
I want to allow my users to pay food to my business users using Stripe Connect. I never used Stripe, but by reading the Stripe documentation, this seems feasible and relatively easy to implement.
According to this Google documentation page, the purchase or rental of physical goods via a given app is not subject to their fees.
Does this imply that I will not pay any fee to Google, even if I distribute my app via Google Play?
Given your use case, you should be able to use Stripe instead of Google Play's billing system and not be subject to Google extra fees. That being said, it would depend on how you implement your app. For example, if you were to sell tokens (that were only available in-app) that could be redeemed for food, that would probably still need to use Google's billing system. You should probably write in to Stripe Support (https://support.stripe.com/contact) to talk through what you want and be completely sure.
I have payoneer account and i'd like to receive payments from app into this account.
Payments are not for physical goods. They are more like app content-unblockers.
Let's focus on Android and Google Play distribution case.
I suppose, payoneer is not designed for processing quick small payments, right?
I need these:
App should be able to set price according to misc factors.
Payments should be instant without credit card entering - i guess it called "Payments from Google Wallet". E.g. if i (app user) have google account and i have payment method in Google Play, then i do not need to enter my credit card number again.
Payments should be possible independently of user location (country)
So, can I use, say, Braintree to process payments with those requirements?
Will it violate any kind of Google Play policies (the fact, that i'm processing payments not through Google)?
The same questions about iOS
For Android : You can use third party payment seamless/non-seamless as long as their sdk supports Android platform. Google doesn't stop you from choosing any payment service.
For iOS : : It's million dollar question. Always refer to latest app store review guidelines https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
You can use third party payment gateway in iOS if you are selling physical goods/services outside of the app. For any in-app purchases you must use IAP.
For any in-app purchases if you use other purhasing mechanisms your app will be rejected.
Refer to section 3.1.1
If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
I have three different subscription purchases with different duration. I've configured test accounts and I can do test purchases. For those purchases Google doesn't charge me, but they look pretty much like real ones. When purchase is successfull, In-App Billing sends me some data about my purchase like packageName, productId, orderId, purchaseToken and so on.
In my handling code I need to know somehow if this purchase is real or not. In plain text: did I really earn money for it or was this purchase made by some test account and I earned for it nothing? I need this kind of info for purchases accounting.
So the question is: How do I distinguish between real and test subscription purchases in code?
Thanks.
P.S. I'm using Xamarin and C# for development.
You can make real purchase on a alpha/ beta version if your account is not added to licensed accounts list in your Google Play developer account.
Check this:
With alpha/beta test groups, real users (chosen by you) can install
your app from Google Play and test your in-app products. They can make
real purchases that result in actual charges to their accounts, using
any of their normal payment methods in Google Play to make purchases.
Note that if you include test license accounts in your alpha and beta
distribution groups, those users will only be able to make test
purchases.
UPDATE
To know which purchase is real and which is test one, check for orderId in response. No orderId will be assigned for test purchases.
Issue with Android IAP, no OrderID in Purchase Object
On the latest v3 Android Publisher API, you can obtain a SubscriptionPurchase object provided you have the Package name, SubscriptionId and the Token.
The SubscriptionPurchase object contains an optional (null-able) integer field named purchaseType. According to Google, when it is set and the value is 0, this is a Test subscription. I can confirm this works and matches the data I am getting back.
Here is the quote from Google's documentation:
// The type of purchase of the subscription. This field is only set if this purchase
// was not made using the standard in-app billing flow. Possible values are: 0.
// Test (i.e. purchased from a license testing account) 1. Promo (i.e. purchased
// using a promo code)
This will be my first time to handle credit card transactions and merchant ids. I have a site that offers services to both event organizers and its users. If a user would want to buy tickets for an event, I want the money to go to the organizers directly. I was thinking I have to handle this with an organizer having their own merchant ids and just store them. My question is though, do I have to ask for their merchant key as well?
As a follow up question, is this a better way to handle transactions instead of having just one merchant id (the website) and funnel the money through it and distribute to the organizers from the users, at the same time charging them for some extra fee?
I want the money to go to the organizers directly
Then you should think of your implementation as a "service provdier only" that has Google Checkout "integrated" into your service. Your relationship is defined as such - while your customers - event organizers and their customers have their own relationship(s) with Google Checkout
This way you are not party to the transaction that occurs between them and Google Checkout.
Additionally, Google Checkout only pays out directly to the merchant (they don't have any other type of "disbursement" that I know of).
is this a better way to handle transactions instead of having just one merchant id (the website) and funnel the money through it and distribute to the organizers from the users, at the same time charging them for some extra fee
I think you already realize the pitfalls just by asking it - you realize that its not just a technical matter - you have your own liability to think about when you are party to the transaction(s).
What would you do on a chargeback? It's your account that is "hit" by that...
What would you do on a refund?
What would you do when there is a dispute between event organizer and their customer?
In these sample cases, you will have to deal with all of them - your "users" are "irrelevant" to Google Checkout (they don't "exist" in Google's eyes).
Also, I'm no lawyer btw, but Google doesn't allow any "fee" that is somehow added to the transaction for use of Google Checkout, per their TOS.
If your merchant account is used for sales then you're reselling the event tickets.
As a reseller, you can provide a very clean experience to your customers. But you'd be paying the event organizers later on (not in the same transaction). A good reason to pay the event organizers later is that you can hold all or part of their money in escrow to cover yourself in the case of a chargeback.
If you want the customer's money to go directly to the event organizers, I think there are some methods:
The customers sell via paypal, google checkout, authorize.net, etc. You direct the customer to the (event organizers) payment page and then back to your site. I think this is what EventBrite is doing. You'd need to collect your fee from the event organizer separately. (You could simultaneously charge a credit card owned by the event organizer.)
You use Amazon Payments which explicitly includes a 3rd party feature. -- It enables you (the 3rd party) to control a transaction that occurs between two other parties (the event organizer and the end customer)
Good luck!