I'm planning to create a web application that allows a user to track donation amounts to their PayPal account that are posting in real time towards a goal.
I need to know...
A. If it's possible
B. If the path I'm using is the best path
c. What is the best path is b isn't.
The flow would work like this.
1) User visits site and enters their PayPal Email address / password / goal donation amount. I'd then be able to make api calls on behalf of this user.
2) I'd use the API call and make a webhook on this users account for when donations come in (The webhooks only say it can fire when sales come in, but maybe donations count as a sale?)
3) I'd have a function on my website ready to accept the post data and update the tracker.
So if the tracker starts out saying 0/300 (user entered 300 for goal amount at the start), then a 15 dollar donation comes in it will update to 15/300, and if another donation for 5 dollars comes in it will say 20/300 etc...
Thanks for any suggestions / help!
Instead of using the user's PayPal email address and password, PayPal has something called a client id and client secret. These work like passwords to make API calls and allot safer than asking for the real email address and password from your user. If you revise your #1, then it is certainly possible to make API calls and receive webhooks just like you described.
Link to PayPal Authentication & Headers: https://developer.paypal.com/docs/api/#authentication--headers
Link to PayPal Notifications for managing webhooks: https://developer.paypal.com/docs/api/#notifications
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.
I am implementing subscriptions to a premium service on a website using Paypal as the payment service. I have successfully created a Catalog Product and Billing Plan through the API, and I am able to get to the payment page on Paypal, but it's not clear how I'm supposed to persist a user identifier through the purchase process.
I assumed it would be something along the lines of passing a user id somewhere, but there's nothing in the Paypal documentation about this. I need to be able to let the user make a purchase and have the Paypal webhook send the confirmation to an endpoint on my site, and that's where I'd expect to get their user id to toggle the subscription on their account on my end.
Is there something I'm missing? There has to be a way to do this cause I'd imagine it's a pretty common use case. If anyone has information or has done this before, I'd love to hear. Thanks.
The only truly secure way I've found when using javascript SDK, is to securely generate a unique custom_id on your server side associated with the user.
Then when you create the buttons, the 'createSubscription' function takes custom_id as a parameter.
Then use a webhook to receive events from your subscription and the custom_id will be present in the body of all BILLING.SUBSCRIPTION events under resource.custom_id.
I am able to get to the payment page on PayPal,
You are vague about what you are doing here. There are multiple ways (and some ways have multiple versions) of accepting subscriptions via PayPal, so it is important that you provide full details about the method you are using.
The time to associate a created subscription ID with a user ID is when it is approved, in the onApprove function if you are using a Smart Payment Button: https://developer.paypal.com/docs/subscriptions/integrate/#4-create-a-subscription
I'm using Paypal rest api to make payment
the workflow is:
Create payment
Redirect to approval Url
User approved (return back to my site)
Execute payment
But there's one thing that I don't want users re-filling shipping address again because it was filled in my website.
So I change the workflow to:
Create web profile (set no shipping field)
Get web profile ID
Create payment with experienceProfileId given
Redirect to approval Url
User approved (return back to my site)
Execute payment
But I found this will create a lots WebProfile every time user request payment.
I think it is crazy to do:
create and delete it later again and again
attempt listing WebProfiles and check which is the one I want to use every time while creating payment
store experienceProfileId as a constant
What is the best practice for handling WebProfile or does there any solution just hiding shipping address while user approving payments?
Maybe this is not the answer regarding this "WebProfile". As a fact, I dont know what exactly "WebProfile" does or is.
I worked on the same Workflow these days. As you wrote I needed to predefine some address. For me it was obvious, that I have to do the database-stuff on my Website. Then I exactly define the order, shipping_address, etc. and send the users to Paypal.
If you predefine the new ShippingAddress() to your ´new ItemList()´ by
$itemlist->setShippingAddress($shippingaddress) the user cannot change it within the Process.
http://i.imgur.com/nAg8jxU.png
Maybe this helps you a little.
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.