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!
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.
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.
I am new to e-commerce development. In my marketplace application, I have three parties involved: Me, customer(end user) and vendor. The customer pays to me for a service to be done by vendor and when the vendor completes the service, I have to transfer the payment to them. So essentially the business logic is:
Customer pays to me through paypal/credit card/apple pay etc.
I ask the vendor to serve the customer.
When customer confirms the service, I pay the vendor's share.
Customer may also ask for a cancellation.
So, I thought to use braintree to collect the payment from customer, but I am not sure how to transfer the vendor's share automatically on a certain day of week? So for example, suppose on every Monday, I want my system to go through the completed services and transfer the vendor's share. Assuming each vendor has got a paypal account, can I do it through paypal? Is there a way to transfer the vendor's share from backend without asking me for the credentials or any conformation?
Thanks in advance.
Yes you can do this programmatically through REST APIs. You can do this by using PayPal's Mass Payment system. It's called Payouts when you are using REST APIs. I'm not sure if there is a Magento extension for it. You do have to be approved for it. Just go to your REST Applications and enable Payouts.
The next big topic in my new start-up company is recurring billing inside Magento. We will have a few recurring products we'd like to offer alongside some standard one-time products. I've researched the best gateways and so far we think either ARB or CIM from Authorize.net is the way to go.
Some questions come up though such as:
If Authorize.net is going to handle the recurring aspect, what is the point of Magento's built-in recurring profiles system? As far as I can tell it's to integrate with the 3rd party by actually taking the user to the 3rd party site? Using Authorize.net would eliminate the need for recurring profiles right?
Are we limited to purchasing one of two or three $300 modules out there to get started with ARB or CIM? So far Magento only supports SIM or DPM. Or do I have to sit down and extend the built-in Authorize.net payment method? Basically I am trying to say we are on a start-up budget and $300 is a killer at this moment.
If we went with ARB over CIM that means if a customer came back to purchase a second item later on that they would have to re-enter their information (CC #, exp. date, etc.) whereas CIM would have this ready to go...is that the correct explanation?
We need the flexibility to create unique payment schedules during checkout. For example: We will sell a custom website and hosting package. We want to charge the user 50% of the website cost upfront and 50% upon completion and setup a recurring payment for the hosting package all at time of checkout.
Along with question #4, currently Magento's recurring profiles limit nominal items to be purchased separately than regular products. This is not acceptable for us and a customer must be able to purchase all wanted items together in one checkout page.
Sorry for this lengthy post but I'm very curious to see what our options might be given all we want/need to do. Any advise is good advice!
The Magento recurring billing code allows customers to view and edit their subscription inside the Magento webstore, so there's no redirection to third party.
Short answer: yes, or roll your own.
I believe that is the case, but you need to check with Authorize.Net on that.
Not sure what the question is here?
Then refer to your earlier question on this topic that I answered. You can choose to override the core functionality, but you need to familiarize yourself with the reasons why Magento chose to enforce that restriction. I believe that is likely due to a restriction in the Paypal interface, and other recurring billing gateways such as Authorize.Net may be able to cope with one-off and recurring items in the same transaction.
HTH,
JD