So I've been using paypal recurring payments for about a year now, and for the most part it works well (with IPN verification after payment goes through, etc...)
One issue I have run into is sometimes my customers will set up multiple payment profiles, which I definitely don't want them to do. Then I have to go in + refund payments and cancel additional profiles.
I was curious if anyone had any suggestions to prevent users from doing this, or WHERE I should prevent this from occurring.
After the IPN notification hits my server, users can't purchase again, but sometimes this can take 30 seconds, or an hour. So then my user goes back in thinking it didn't go through and purchases again.
My process is pretty much this:
Page 1 (user selects options)
Paypal API: SetExpressCheckout
Page 2 (user goes to paypal, logs in, accepts agreement)
Page 3 (I create the agreement)
Paypal API: GetExpressCheckoutDetails
Paypal API: CreateRecurringPaymentsProfile
I would think somewhere on Page 3 I should do a check, but I'm not 100% sure HOW I should go about it. Simply make an association w/PayerID they they tried to purchase something here then prevent it ongoing?
What do people recommend?
Thanks!
After creating the first recurring payment profile, in the response you will get a profile id and a profile status which should be 'ActiveProfile'. I would recommend that you save it, and do a check before he selects any subscription(or product) again on Page 1.
Related
We are working on finding a solution for a custom PayPal cart install. I'll try to explain what actions are taking place then point out where we are having issues.
Here is the issue that we are facing:
1.) Users of our site can purchase a subscription
2.) That subscription once paid for activates several actions on the user’s account.
3.) Subscriptions last for Xx amount of time.
4.) Each hour our cron page runs and checks for payment received or not.
5.) After Xx amount of time (the subscription length duration) if the payment is verified to have been received the users account automatically renews. If payment is not verified to have been received then the account we return to normal.
6.) We have it operating correctly in the scenario if the payment is made from one PayPal account for a single user subscription.
7.) However, if a user uses one PayPal account to purchase multiple subscriptions (for this example 10) and cancels X amount (for this example 9) of subscriptions from within their PayPal account, none of the accounts get cancelled from within our site. Say a office manager submits payment from one single PayPal account (because they are in charge of 10 users accounts). Then immediately cancels 9 of the subscriptions from within that sign PayPal account and leaves one active account in our current setup it still thinks a payment was received for all 10 of the users because it’s checking the account rather than individual PayPal subscription for payment. (Tricky to explain)
** What I am are trying to figure out is how to have this action record the Payment ID # that is given by PayPal for each individual subscription when a purchase is completed and when the cron page runs it would pair the user’s (our site user) account to their Payment ID # and take action accordingly. So this way if 9 of the payment ids did not receive a renewal payment those accounts would become inactive and the one payment ID subscription that did receive payment would active properly.
I hope that makes sense and I would really appreciate anyone's help on this. Thanks a ton!
You should be using Instant Payment Notification (IPN) to handle automated updates based on actions that occur on the PayPal account including new profiles, payments, failed payments, canceled profiles, etc.
Any time a transaction occurs on your account (payments, profiles, refunds, disputes, etc.) PayPal's server will POST all of the transaction data to a listener script you have sitting on your server. Within your script you can process that data however you need to, and it happens in real-time.
I'm building an app that let people subscribe to my service and I use the Paypal Classic API. I'm stuck in one last thing, which is how do I know if a user CANCELs his recurring payment not from my app, but from his Paypal interface?
I checked the documentation here (last subject in the page):
https://developer.paypal.com/webapps/developer/docs/classic/express-checkout/integration-guide/ECRecurringPayments/
But all it says is that I can call GetTransactionDetails to check if a user is still paying. But it doesn't make sense: if you have 100 000 users, you can't run GetTransactionDetails 100 000 times every night to check if users are still subscribed?
What am I missing?
Is there a simple URL I can give Paypal so that if a user cancel from Paypal interface, Paypal call a page on my site that alert me of that on a per-user basis?
What I want to do is have a buy it now button somewhere on my site. When users log on they can click it and pay X amount, then after the transaction has completed I need a script to update 1 field in the database with a value.
Someone recommended using paypal ipn for this.
Is that the best solution for what I am trying to achieve?
Will I need some additional script to work with it or is it "ready-made" with just specific database variables requiring changes?
Paypal has a much nicer workflow for this that does not make the user wait an undetermined time for his payment to arrive: Paypal Express Checkout. With this you actually do know that he paid with paypal the very minute he comes back from the paypal page, and you can do all the things needed to make the transaction happen on your side as well.
I am working on a project which will be able to accept paypal payments. The sequence I am using is as follows:
My current development sites' payment steps:
The user goes to my site,
Chooses to pay for something,
Is redirected to paypal,
The payment is completed on paypal,
Then the user gets redirected back to my sites success url.
This works fine, as I use an IPN listener to update my database in the background when paypal decides to confirm the committed payment and let the user know accordingly.
However, a few days ago, I was doing some online shopping of my own, and paid using paypal. I noticed that when I paid, I was redirected to paypal, where I logged in and saw the paypal invoice. I clicked confirm, and I was redirected back to the sellers website, where I so a summary and was told to commit the purchase!!!
So basically, the sequence was something like this:
My shopping experience from a different sellers site:
I wanted to pay for the items,
I was redirected to paypal,
I was the invoice and confirmed the payment,
I was redirected to the sellers site,
I was was shown a confirmation of the order and was asked to commit the payment,
I committed the payment and was told that the order has been completed.
The difference, my site commits the purchase on the paypal website and I listen for a reponse from paypal using their IPN system, but this second site seems to commit the payment on the sellers actual website.
I thought, wow, that felt so much more reassuring from a user experience point of view.
How is that done?
Sounds like you're currently using Payments Standard and you want Express Checkout.
Express Checkout is very similar to Standard except that it's API based and the user gets returned to your site prior to finalizing the payment.
It consists of 3 API calls...
1) SetExpressCheckout - gets a token back from PayPal that you append to the end of a redirect URL that sends the person over to PayPal to login and review the payment.
2) GetExpressCheckoutDetails - This allows you to pull the payer details (name, phone, shipping address, etc.) back into your app from PayPal. This is an optional step.
3) DoExpressCheckoutPayament - this finalizes the payment. No money is moved until this API call happens, and it doesn't happen, of course, until the user is already back at your site and within your own app flow again.
You can still use IPN the way you are, but you could also things directly within the flow as well since you get instant responses back from the API, and you can setup your own review however you want to.
I have a recurring payment solution set up via PayPal's IPN service, basically the user fills in a form, pays the money and via IPN my system gets a ping to grand the user access to the system.
Everything technically works fine, but occasionally on the last day of a user's cycle they forget that it is a recurring payment and complete the form again. PayPal doesn't seem to mind this and creates a second recurring payment profile.
Currently I go in, refund the money and cancel this new payment profile, but obviously this isn't ideal - is there any way I can configure PayPal to not accept new profiles from people with currently active profiles? Or will I need to catch this at my website's end and do some form of lookup before allowing the payment?
Paypal did not recognize the a transaction is a duplicate one, It tackles the transaction as a new transaction. You will have to tackle it from your system.
When implementing payment gateways, It is good approach to save the billing with a status pending or something in your system before sending to payment gateway.
Also in the form user is filling you can implement a field to uniquely identify the user like his email address and you can also save the expiry or second recurring date against the user unique field in your system. Now when the user enter the same unique field and want to submit a form again you can validate that the same user is paying again but its expiry of second billing date is not yet reached, so prompt and restrict him for paying again.
Hope it will help you.