See here: https://www.paypal.com/ca/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside
There are 6 different notifications and I've never fully understood when I should use each one.
For example, when there is a sign up notification, does that mean I have the money?
Also, which notification do I remove their account on? If they pay for a month, then cancel their membership halfway through, but I still keep the money, what notification will be sent on day 30?
Basically, I need to know when to create their account and when to delete their account. There must be an easy way to this mess.
Thanks so much.
A signup is not a payment. It's just a new profile that gets created. You'd get a separate IPN for any payment that actually occurs related to a signup (subscription profile), so if your profile is configured to charge the first payment right away you'll get 2 IPN's right away: subscr_signup, and subscr_payment.
If they cancel their account you would get the subscr_cancel notification right away when that happens so you can update your database accordingly.
Same thing for the end of term. That's when you'll get a subscr_eot notification, so you'd kill their account in your system when that happens, too, or display a way for them to renew or whatever you wanna do in those cases.
Related
I have an ipn listener that update my transactions (from pending to completed) and my contracts payments from finished to paid. This is perfect! I has also a return page... From PayPal to my site... This page show "thanks" and "button to allow download their last paid online contract" (paid with PayPal). My problem is that.... Ipn listener sometimes comes 3 seconds after my return page is shown to the the user....
In my return page in this case. Has the transaction and contract unpaid... And when ipn listener catch the results... Then this transaction and contract change to paid status. But ipn listener is executed at back-end. In my server. And my return page was shown 3 o 2 seconds before to my user. What can I do?
Should I add a timer (a delay) in my return page waiting until ipn updates my transaction and contract status? And then, show to the user a button "you can download your last paid contract!". Or better I should forget this step. And in my return page always without wait show to user "thanks for your payment". "you can download your last paid contract!"
You should not regard or show the transaction as complete, or allow any further business action to occur, until you have actually received the money, and only the IPN tells you that.
You need to adjust what you show on your return page accordingly.
All you should really do here is thank the customer for his business and tell him that the download or the delivery or whatever it is will become available immediately PayPal has notified you of the actual transfer.
And note that it can take a lot longer than three seconds. If they chose to fund the payment from their bank account, it can take 3-5 days: and there is always the possibility of that process failing altogether due to insufficient funds.
So don't be too optimistic in designing your return page. The deal isn't done until the money is in the bank.
This page show "thanks"
Good.
and "button to allow download their last paid online contract"
Bad. That should be somewhere in 'My Account'.
I also have my return page wait for the IPN notification to come into my server, and you can definitely make that work if you do it right.
Initially, the return page polls on a field in my back-end database that the IPN handler updates. Then, when the return page sees that field update, the customer gets his 'here are the items you paid for' button.
I also have a one minute timeout on this process. When that expires (although I can't remember the last time that actually happened), I display a catch-all error message ('There was a problem processing your transaction') and invite the customer to contact me for help.
I also tell them that their license key (which is what they are buying, in my case) might be on its way by email, since, usually, it is. IPN notifications can sometimes take a little while to arrive for some reason but my IPN handler sends out a confirmation email as a backup so they will get that in due course. That usually sorts things out, I rarely need to get directly involved.
If PayPal puts the transaction on hold, it doesn't seem to ever forward the customer to the return page (I have certainly never seen that happen). Instead, I assume it lets the customer know that he must wait for the funds to clear and leaves it at that.
An IPN notification does get sent however when the transaction eventually clears, and then you can have your handler send that email.
Lest this sounds like a lot of work, you should be sending an email from your IPN handler anyway since customers like to have a record of their purchases. Once you put that mechanism in place, the rest is easy.
Note: Watch out for IPN transactions flagged as 'echeque'. The funds haven't cleared yet, you will get another notification when they do. Then you can send them their contract by email. If memory serves,this does forward them to your return page so you have to handle that by letting them know that they must wait. In practise, this doesn't seem to happen very often.
Suggestion: have your scripts send you an email when something unexpected happens. This has saved my bacon more than once when PayPal have changed the names of the fields passed to the IPN handler for no obvious reason.
Summary: This is a practical, experience-based write-up of the way my website works, and it works well. I hope readers of this post find it helpful, despite the mysterious downvotes.
I'm using PayPal to take subscription payments for access to a website service.
I'm using PayPal's IPN to manage the payments and user accounts.
I'm sending a custom random key to PayPal, unique to each user, when the subscription is first instantiated so the same key is sent back with every IPN. This means I can bind together my users table with my PayPal notifications very positively.
Accordingly I can now generate from my database a list of user_ids and notification details.
So now I need to figure out the best logic to use to calculate each users current payment status and, as a consequence, what to do with their account - whether to continue allowing access, suspend or even delete their user account. This decision will all come down to whether their payments are still coming through or not.
A bunch of interesting an varied data comes through on PayPal's IPN - most looks irrelevant in terms of user account management but a couple of columns look quite useful. Specifically...
Field outstanding_balance appears to contain exactly that - a value to 2dp of money still owing. So far during my testing this figure has only ever been 0.00
Field txn_type shows me any from a selection of different codes: subscr_signup (when the user initially sets up the subscription), subscr_payment (when a payment appears to be successful), subscr_cancel (this seems to appear whether the customer or vendor cancels the subscription), and subscr_eot (end of term - this one crops up shortly after the subscription is cancelled).
My impulse is to search the table for the most recent txn_type="subscr_payment" entry for each user account, and check the date this last notification arrived. If it is date stamped over, say, 28 days ago the account can be suspended... if it's over 56 days the account can be deleted.
Is this a good idea? Or is there better logic I can employ?
I've done this. Quite simple:
Don't grant access until you receive the first payment. You can get the intial signup and payment in either order.
PayPal will notify you if they cancel their subscription or it expires. When you get either of those, deny access as from the effective date.
If the most recent payment status on an account is 'reverse', suspend access until you either get 'cancel reverse' or the situation is sorted out in some other way.
Don't count the days. PayPal counts the days. All you can get from repeating that yourself is a disagreement, and guess who's right? PayPal. And guess who isn't wrong? The customer. You don't want to penalise the customer because PayPal got behind or had a different idea of 28 days from yours. You've handed responsibility for collections and renewals to PayPal: let them do it.
Beware of building policy into this. It should just be a mechanism, and it should be manually overridable. For example, the actual evaluation of whether this user has access to this product now mustn't be a computation over their payment history. Just a simple lookup of another table, which your IPN code can modify, but so can humans. For example: there is a dispute. You lost. You might well as a matter of business want to keep the customer alive for a grace period anyway. Alternatively you might in extremis want to fire the customer immediately, e.g. for usage violations.
You can ignore the balance field. The only important thing is the txn_type.
In testing my Chained-Payments application in the paypal sandbox account, I encountered an error
The login information you entered belongs to the recipient of this transaction. Please change your login information and try again.
Now, to me, this restriction on multi-recipient payments is silly. The account I tried to test with receives a commission fee on the transaction. So yes, that accounts $.50 commission would effectively be a discount on the purchase because it would leave the account and return.
Is there any way around this? I was wondering if a user was to use two different email addresses attached to the same account, would this be possible?
User#gmail can pay to bob#company & refer#company.
refer#company cannot pay to bob#company & refer#company
Can refer-alias#company pay to bob#company & refer#company if refer-alias and refer are both attached to the same account.
I'm several days from going live so can't test this myself yet, otherwise I would, and will, if I don't get a response, but it would be extraordinarily useful to know in advance.
Update: I did move to the Live environment last week and found out that no, there's no way to send money from an account that is also one of the receivers. Different email addresses don't enable this either.
While there's no reason I can think of that a user would want to do this when they're the sole receiver, there are reasons that you'd want to make a purchase through a system even if you are of the recipients.
Obviously, there's usually code work-arounds, but it's still a nuisance. What I did was put all my email-addresses in an array, and I run a search on the array
if (ArrayFind(RecipsArray,senderEmail)) {
disperse special way, excluding the conflicting address.
} else {
disperse normal way
}
https://www.paypal.com/ca/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside
Paypal has 6 different txn_types. I assume on "subscr_signup", I have the first payment in my hand and I can send their license. Then lets say halfway through the subscription they cancel, I will get the "subscr_cancel" notification? Then at the end of their paid period, I get the "subscr_eot" notification. Is this correct?
Therefor, in a recurring billing system, I just need to create a license on "subscr_signup" and delete a license on "subscr_eot"? Is there anything I'm missing? I just don't want to rip the buyer off.
Thanks!
I assume on "subscr_signup", I have the first payment in my hand and I can send their license.
No. You can get subscr_signup and subscr_payment in either order. You shouldn't send anything until you have the money. If doing that requires what's in the signup transaction, that means you need both transactions before you can do anything. In my system I create the user on signup, but I only give him his permissions and send him an email only if both transactions have occurred.
Then lets say halfway through the subscription they cancel, I will get the "subscr_cancel" notification?
Correct.
Then at the end of their paid period, I get the "subscr_eot" notification. Is this correct?
Yes. You don't need to do anything particular about subscr_cancel. All I do is send him an email asking if there is anything we can do to retrieve the situation.
Therefore, in a recurring billing system, I just need to create a license on "subscr_signup" and delete a license on "subscr_eot"?
Not quite, see above.
Is there anything I'm missing? I just don't want to rip the buyer off.
You need to handle subscr_modify. I handle it by terminating the current subscription as for subscr_eot using the effective date supplied as the end date, and starting a new one as for subscr_signup` using the effective date as the new start date.
When you check for payments, e.g. on subcr_signup, you also need to look out for payment failures, reversals, etc, to make sure you've really received the money. You have to to check the payment_status. I also have some logic somewhere to make sure the last transaction on the account isn't a reversal.
I have googled this for a while and I don't think I was able to get a clear cut answer.
We have an application that displays a Subscribe button. Once clicked, It takes the user to the Paypal website where s/he can complete the txn.
Later on, Paypal sends an IPN to our site indicating whether payment was successful. This integration is done by setting hidden html variables.
Now, there is a need to allow the user to cancel their subscription. So far, most of my readings indicate that the user must login to paypal and manage his/her subscription there.
In addition to that, I was able to find some other people mentioning that It would work with using CreateRecurringPaymentsProfile.
The problem is that the later requires ProfileId which is returned thru CreateRecurringPaymentsProfile. it looks like there is a gap. I would appreciate if somebody can pinpoint to the right direction.
Thanks,