I've got paypal recurring payment buttons on my website.
I'm passing subscription type and user id through custom data.
It's reversed and base64 coded. But still someone can edit it and change subscription type or/and user id. Am I right?
Should i check payment amount and then verify type or what...
Is custom data field in paypal button safe to work with?
You should encrypt your payment buttons - see Securing Your PayPal Payments Standard Buttons.
Related
Does Paypal "Buy Now" button triggers webhooks?
What's the disadvantage of using the Buy Now button versus a fully integrated payment system in a website selling digital goods?
PayPal buttons trigger webhooks called IPN (instant payment notification). You can define a controller to handle this request and update your database.
The button you put on your web site can include custom fields that will be sent back by the IPN (along with all information sent by default, such a price, etc) , making it easier to identify the payment (such as the identifier of the customer in your application).
I can elaborate and add some code later. Unfortunately I’m on my cellphone right now.
I cannot compare to other methods, as I have only worked with PayPal buttons and IPN, but it’s quite easy to make it work.
https://developer.paypal.com/api/nvp-soap/ipn/IPNIntro/
My dear fellow IT developers...
I am currently working for a client of mine on Laravel 5.5 and we are using omnipay library for PHP and it's PayPal part omnipay-paypal. Now since this a specific request from client I am using PayPal-Express method to redirect the users to PayPal then there they login and pay with their account PayPal or CreditCard and come back to my clients page on Thank you page.
Now since the client wants to create an upSell page which stands between checkout page and Thank you page, and it offers 1 additional unit of the product on 50% discount.
The story is that after the first charge I would need to recharge them again somehow, ideally with what I already have and that is PayPal Express.
On our checkout page we have two options PayPal or Checkout.com, the latter one offers storing of card_id property and after that you can do the recharging, this is already implemented and working like charm with Checkout.com. Now back to PayPal.
I've spent fair amount of time trying to find the same solution for PayPal but with no luck. If there is some good soul out there to help me out with this I would appreciate it very much, so Omnipay PayPal library + recharge the customer if they click Yes on upSell page after initial successful charge/payment via PayPal Express.
Thank you in advance.
There isn't an easy solution to this problem, however I can point you in the direction of a couple of things you need to do:
What you need is a card token. That's where (in Omnipay) you call a method like createCard() with the customer's credit card details and you get back a token. You can't do that with a PayPal account, you have to capture the customer's credit card details and then charge the card.
Creation of card tokens can't be done by the PayPal Express gateway. It can be done using the PayPal REST gateway (an alternative and newer gateway in the same Omnipay package as PayPal express) which means you need to switch from PayPal Express to REST. That's as simple as generating a new set of API keys. That will allow you to call createCard() with the card data and get back a card token (called a cardReference in Omnipay) just like you do with checkout.com
Just to reiterate, what you're trying to do can't be done with a PayPal account. You need to have the customer's credit card details.
I new to paypal integration in asp.net . I found very difficult to understand the paypal api .
I under stood two types -
inline html form ( i.e is also called buy button )
payflow api
my questions are :
which one must be used for recurring payment ( subcription packages for end user)?
in first type , few sites suggested to use IPN for confirmation of payment. I want to know is it neccessary since without using IPN, also using notify_url we can confirm the payment success (as per my knowledge notify_url returns to your site when payment is completed at paypal site)?
for recurring payment , do i need to store user account details (i.e credt card or paypal account ) in my databas?
please do reply with you suggestion .
Thanks
1) You can do it with both, actually. If you want to stick with basic HTML forms then you'd be using Payments Standard, and they call it "Subscriptions". You can easily create a Subscription button from within your PayPal account.
If you're using the API then they call it Recurring Payments (or Recurring Billing). You would use Express Checkout for the PayPal signups, and Payments Pro if you want to handle credit cards directly on your site without any redirect to PayPal.
IPN is useful regardless of what integration method you're using, however, don't get it confused with PDT. PDT sends data back to your site's thank you page, or whatever final page you setup for it, and it only works with Payments Standard. When PDT is configured on Payments Standard, even with Auto-Return enabled, there is no guarantee the user will make it back to your return URL. IPN is very similar, but data will always be POSTed to your IPN listener regardless of whether or not the user makes it back to your site.
You'll also want to use IPN to handle updates for future payments on a subscription / recurring profile. For example, the actual payments, cancelations, suspensions, reactivations, etc.
The notify_url parameter you mentioned is used for IPN. Again, though, this is separate from PDT. A common mistake I've seen many times is when people have their PDT and IPN both set to the same URL. Then when people do make it back to your thank you page, the code actually runs twice. Once from the user actually hitting it, and once again from PayPal's IPN server hitting it. So make sure to avoid that sort of thing.
3) No, you will never save credit card details to your server. The subscription / recurring system handles that using the data that PayPal saves on their servers.
Paypal makes it really easy to create a donate URL. A donor can enter a custom $ amount or use a fixed one. We'll use the custom amount, since it's more flexible. Is there anyway to allow the donor to enter a custom amount, and have PayPal display a checkbox for example to allow this amount to be a recurring monthly donation via a URL?
We checked out the "subscribe" button, but it only returns a form, not a URL, and didn't see anywhere to let the donor choose the amount.
Basically, this should be an optional field in the donate URL. Any ideas on how to accomplish this?
You'll need to use standard subscription buttons or the Recurring Payments API. Either way you could setup your page so the user chooses those options on your site prior to being sent over to PayPal.
use cmd=_donations. Paypal will prompt for an amount and whether it is recurring.
PayPal now has recurring donations, for mobile checkout, by default. See this blog post.
Im using Website Payments Standard so users can pay for a rating to be shown on their profile. Im also using IPN to check if the payment went through. How do I relate the two? When I get an IPN request to my listener, how do I know which user and rating it relates to?
If users are initiating payment through a buy it now or shopping cart button embedded in your site, you can set some sort of text box where the user enters their user name. this info will be sent with the Ipn. This is set up on the pay pal sure where you create the buttons.
Another method would be get their actual name from the ipn. Check the documentation for a list of variables that are sent with the ipn, there are a lot of possibilities.