I integrated apple pay as a payment method in a taxi service such as Uber.
The ride cost calculated before trip start was 50$ so I pre-authorized apple pay for 50 and user approved the charge.
After the ride ended, the actual cost for 55$.
How do I charge the user the extra 5$? Do I need to ask them to authorize the charge or can I use the previous consent to do the charge for remaining 5$.
Also, how will the same scenario work for google pay?
I am not sure how to go about this problem
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.
Is it possible to freeze money on the card, before buying.
And after delivery of the goods, write off the money from the user's card.
Is it possible to implement such functionality through API?
Thanks for any information :)
In the payment processing world, "Freezing" money on a card is called Authorization and "Write off" is called Capture.
The timeframe, from the time of authorization, in which capturing the funds is allowed usually depends on the card brand and your payment provider API limitations.
Many payment providers offer the ability to authorize funds prior to capture, and generally speaking, the time period for capturing the funds after authorization is 3-10 days.
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!