I was wondering If I could charge a "security deposit" using PayPal ?
On my site, user can pay for an item (service). But I have no idea, how to charge a security deposit, because it is NOT guaranteed that user will pay using his PayPal account - That way I could simply use MassPay API to refund the deposit back to the user (payer_email).
But, PayPal allows to pay even without creating an account. Although, user has to specify his email address, I'm not sure that sending back money to this email address would put the money on related credit/debit card.
Is there some API for doing this ? Because charging price for the item + security deposit doesn't feel right for me.
I know that, for example, airbnb.com has some similair functionality for that one, but I don't know how it works
I would be very grateful if someone helped me with that one.
Thank you!
It sounds like your primary issue is that users can checkout without a PayPal account. If that's the case, this can easily be solved by disabling the "PayPal Account Optional" feature in your PayPal profile under Website Payment Preferences. This will causes users to either sign in to PayPal or create an account to pay.
If you'd rather leave that option enabled there are plenty of ways to handle security deposits and returning money, each with their own advantages and disadvantages. I won't get into all those details yet, though, if simply disabling that option solves your issue.
Let me know if you want more info on the other options.
Related
So I am building an app with react-native (expo) where a user fixes appointment with some other person and to do so, he has pay the other person.
Now how can I handle payments here. What i want is the user makes the payment and the receiver should be the other person but how much i understood the payment gateways, the payment is received by the app owner or in simple words, receiver is a single person.
I also tried deep linking to directly take the user to some UPI app like google pay or paytm but it seems that those apps require some special type of account (merchant account) to make the transaction if we access them using deep links (which is a problem as it is not necessary that every user will have a merchant account).
As I said, it is always better that you have your own payment gateway account, and all the transaction goes through your gateway, meaning you get the money and you build a system which will forward the payment to the receiver. I have worked on 2 such apps:
1: Where we have our own razorpay account, and we get the payment first, and then we forward it.
2: Where in we were directly having transaction between 2 users, but not through app, instead we display them the account details of the receiver and give them 48hrs time to pay that account. But we had to manually handle this scenario since one cannot know if the user has paid to the said account, since it's not your account.
3: There is one more method where in payment gateway has a webhook which consists of a virtual account number, and every user that lands on your app, you can create a virtual account number for him/her and store the user-virtual account number relationship in your db, whenever there is a payment, you can find out about the user through this virtual account number. Read about this.
The deep link is a good idea, but again, as you mentioned, it will require the end user to be a merchant user(have a merchant account), you can find more details here
Maybe you can ask your users to create a merchant account, which again I am not sure if it's possible, and if it's possible, if it's feasible?
The best way according to me is, you handle this through your payment gateway, and instantly forward it to the user who should have received it. Again there are some rules and clause to it(some commission is taken by those payment gateway,etc), check those things out.
I think the most close answer to my question is to use razorpay routes where we can link multiple accounts with our account and transfer money accordingly.
More details here
I am designing a website that accepts payment through simple PayPal or Stripe buttons, but also has a section that pays out users through PayPal. What is the best way to do this?
Current setup: The user builds up coins through an action (NDA won't allow me to discuss in detail) and when their coins reach a certain amount, they can cash out in real $. I have designed this flow: Pay Me Now Button -> Screen with PayPal email address input. Repeat email for typos, then Confirm Button -> Success screen
However, the client would prefer a direct link out to PayPal instead of manual input of email addresses. The reasoning is that they would prefer it being arranged through PP's service to reduce manual errors and typing out. As far as I am aware the only way to get paid is through writing down an email address/phone number. I have researched PayPal.me buttons but it still isn't making sense. Maybe there's another service altogether that I can suggest to the client for paying out users in a no-friction way?
I'm looking at how user testing sites pay people, but not getting very far.
If the money is in your client's PayPal account and they wish to send it to a user's email address (that may or may not have a PayPal account already), this can be automated with PayPal Payouts.
If the user does not have a PayPal account already they will receive an email notification and have 30 days to create an account or add the email to an existing account. If they don't, the payment will be refunded automatically.
Ok so I got the following problem with my Shopify shop: Because my shipping varies based on weight paypal does not show the shipping rate until after the customer has logged in and paid for it. It then gets send back to Shopify where it receives the message that it will be billed an additional $10 for shipping, which already got me some complaints.
So what I want is that it will already shows the shipping cost before the customer logs in and pays for it. I imagined that more people had this problem and perhaps found a solution to fix this?
Thank you
There are a number of ways to handle this with the PayPal system, but I'm not sure if Shopify is open enough for you to make any changes. You'll probably need to ask them how it's configured and see if you have any option to adjust it.
The standard flow for Express Checkout is that you would show the user their cart and any fees you've gathered at that point so you can generate the subtotal. Then you send them over to PayPal where they login and agree, and are then sent back to your site. Back at your site you would obtain the shipping address from PayPal and you could then display a final review page that breaks down any additional shipping, tax, etc. that might be applied now that you know their shipping address. No money would actually be charged until they approve this final review page.
In order to skip the additional review page on your own site, PayPal introduced the Instant Update API a few years ago. This gives you the ability to generate a web service that PayPal's review page will call and send the shipping address so that the service can calculate shipping and tax and return it back to PayPal. The PayPal review would then update accordingly so the buyer can choose their shipping option and see the grand total on the PayPal review page. That way they can finalize and would still be returned to your site, but you wouldn't need to show another review. You could simply show the thank you / receipt page.
I'm not sure if that first method I outlined is in fact what you're getting..?? It sounds like you're saying that Shopify is skipping the extra review, finalizing the payment, and then simply notifying the user that more money was charged than they agreed to. If that's the case, I would say that's very sloppy checkout design.
Again, though, as Shopify is a hosted solution, you probably won't have the ability to adjust this on your own. It's possible they have the Instant Update API available, though, and maybe you just need to enable it..??
You'll need to check with them for more details about your options.
I can not praise with my contribution here, because I am new user,
but would help if I can.
I have a big problem and I do not know how to solve it, please help.
In the same Paypal account with the default email address: email1#somedomain.com, there is 7 more emails:
email2#somedomain.com
email3#somedomain.com
email4#somedomain.com
email5#somedomain.com
email6#somedomain.com
email7#somedomain.com
that's the maximum allowed number of emails under one PayPal account (8).
So we are using API on several pages, and only one API signature can be done in the paypal
interface, so same API signature is used for each web page.
We would like to define where will money go - to which email address inside the same PayPal account.
We use Premium PayPal account, and we know that for logo change, email remove and so on, we would need Business account,
but for defining money receiver email address inside the same PayPal account
we suppose that it can be defined, otherwise we do not se a point of having several email addresses inside one same PayPal account.
The problem is that always is shown default email when making a purchase :S
We tried to define SUBJECT:
SUBJECT=merchantEmailAddress
N O T E: Typically, a merchant grants third-party permissions to a shopping cart...
And set merchantEmailAddress email2#somedomain.com.
In sandbox it works like a charm as soon as we put it on production, default mail is shown again.
Please if anyone had the same issue help.
Thank you very much, this forum is great and I realise that without nice people and contribution as well there would be no answers.
regards
You would not be using SUBJECT unless dealing with Permissions and making calls on behalf of 3rd party PayPal accounts.
You're working with a single PayPal account, so you won't be using SUBJECT at all. You'll use the credentials like you are already.
That said, I'm not sure I'm following you entirely what trying to send to different emails. I don't understand the end goal with that..?? The API credentials are what are going to tell the system where to drop the money, or pull data from, or whatever.
If you're just trying to get different logos to show up during checkout you can do that with parameters in your standard button code or API requests.
Let me know if that helps or not. Again, I'm not sure I'm understanding what you're after here.
So I'm working on this website where users post their items, other users add some items to their cart and purchase them online.
The flow i was thinking about goes like this:
A merchant posts an item along with their credit cart/ paypal information.
A buyer adds items (from different merchants) to his/her shopping cart and purchases.
The buyer pays by filling a form that includes the payment method fields within the website's layout (no redirection to paypal).
The website will work as a gateway, it will capture the payments from the buyers and pays the merchants accordingly and automatically.
Is this possible using PayPal? if so, what API should I use?
Any input/idea is appreciated...
Thanks,
/t
I have also investigated using PayPal in this way for a site with a similar concept. Unfortunately, PayPal does not allow this. This makes you something known as a Third Party Payment Aggregator which drastically increases the risk associated with providing you a Merchant Account (which is what PayPal is doing). You can read more here.
Though, you could probably do it for a while before PayPal caught on, they could cancel at anytime leaving you high and dry. I recommend investigating Third Party Payment Aggregator solutions (Braintree has something that helps with this).
I guess it is. Use Paypal API
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_reference
https://developer.paypal.com/