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.
Related
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 want to create an app like Google Wallet for my country, Romania. I emailed Visa developer and I received the next email.
"Hello,
Thanks for your interest in visa direct API. There is an
acquirer in Romania who supports visa direct transaction BANCA
TRANSILVANIA S.A.
However, There are many elements and requirements
to offering a comprehensive Visa Direct program of which the APIs are
just one component. First and foremost you must be sponsored by a Visa
acquiring financial institution or work through a payment aggregator
or facilitator to offer a Visa Direct program. You must identify and
work with a sponsoring Visa acquiring financial institution or payment
aggregator or facilitator who will help guide you through the process
of onboarding a Visa Direct program. If you already have an acquiring
sponsor, please let us know. For more information on Visa Direct
programs, refer to www.visa.com/visadirect Thanks Sanobar Visa
Developer Platform "
What do you understand from this email?
So this means I can't use the APIs from https://developer.visa.com?
If I can't use their API from the developer website, this means I must use a payment aggregator? I don't know any payment agregator that can use my local currency (RON - Romania). Can you sugest some payment aggregators please...
These APIs (Mastercard MoneySend and Visa Direct) are good for what I need?
you need a partner with a financial institution like a bank or
I want to develop a market place store front for farmers, but use Square as my payment gateway. I have achieved this using Stripe, but they do not have the in-person payment option and that is crucial for the business model we want.
I would like to know do you allow application fees that go to the marketplace owner on transactions? If not, how do you propose that a user of the payment gateway that is building a marketplace get paid. I need to pay the vendor AND the marketplace owner. I saw that with OAuth, you can connect to up to 10 merchants from your merchant account. How am I supposed to use this information to get paid?
Can I create a separate fee transaction/transfer on a merchant account that goes into the marketplace account? If so, I would incur the 2.9% +30 cent fee for a small transaction of maybe 40 cents. Is there a way to avoid that?
The Square Connect API does not currently support additional application fees on top of API charges (aka "multi-party payments").
While the API can be integrated into your platform as an e-commerce payment gateway, it is not currently recommended for platforms that require multi-party payments.
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.
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!