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.
Related
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 am using PayPal Payments Standard to upload contents from a custom shopping cart. i.e. The upload happens with a page redirect which posts the hidden vars to PayPal where the customer completes the transaction. When the transaction finishes, PayPal uses the "IPN" process to notify my the payment has been made.
In this case a reservation is made at the same time. The same as selling a limited stock item. As it wouldn't be good to have multiple PayPal transactions out there contending for the same slot, the reservation is made before the customer gets redirected to PayPal.
Once the Customer is at PayPal they might realize they don't have any money and close the window leading to an unpaid reservation that needs timed out and dropped.
Is there a guaranteed expiration time for the PayPal checkout page after which the reservation can be discarded without a risk of receiving a surprise payment for a deleted transaction? I realize IPN has it's own non-deterministic timing stuff, but without knowing there even is an expiration period, someone might sit on the website for a day and then pay.
Possibly too late to help you, but for the record: I asked PayPal tech support this question, as I couldn't find it in the docs either. They wrote:
Each transaction is associated with a token that expires after 3 hours
if the buyer didn't complete the checkout. This isn't usually
modifiable but can be extended by contacting a Business service
representative ( we don't recommend to extend it for security reasons
however. the token can't be less than 3H in any case)
So it's a MINIMUM of three hours.
I have looked around SO for this but I can't seem to find anything like it.
On my service, I wish to charge on a per-month basis depending on how many users my clients have.
So this question is split up into two parts.
What I want to know is it possible for a client to use their own paypal account (without entering any CC details) with conjunction with CreateRecurringPaymentsProfile via the NVP, I have looked through the documentation and can not discern anything. So clearly it is not possible to do it via NPV - From what I've seen so far.
i. If I do an Express-Checkout Subscription, I can do 20% change on total amount every 180 days (I DO NOT want to do this) - I want to be able to get the Profile via the IPN and then modify the monthly amount on as-need basis
ii. There was some mention of Referenced Transactions, but the Documentation is very confusing.
So say there is a way to create a recurring payment subscription via a PayPal Account on the PayPal website, next step is to be able to update the Subscription via UpdateRecurringPaymentsProfile NVP command.
While I am happy to pass on CC details (which already works great), I am just wondering if it is indeed possible create a button, which would create a Subscription - once on success an IPN request is sent back with the ProfileID which I can modify the Billing Amount by NVP.
So TL;DR;
The current flow I have
Register on our website
Enter CC Details
Backend submits the data to PayPal and if passed - continues on.
On any Account modifications, update Profile Monthly Amount Automatically.
The flow I want
Register on website
Click on an Authorize Button Redirected to PayPal
Login to their PayPal Account Create Recurring Profile.
On any Account modifications, update that Profile Monthly Amount Automatically.
edit to add - this is all working now, had to contact and harass PayPal directly for a lonngg time.
I'm a little confused because it sounds like you answered your own question, but then said that's not what you want..??
Express Checkout does exactly what you outlined at the end of your post, and it triggers an IPN just like any other PayPal transaction. You are indeed limited on how much you can adjust the amounts of profiles created with EC, though, just like you mentioned with the 20% every 180 days. If you create profiles with Payments Pro (DoDirectPayment or PayFlow) then you're not limited and you can adjust the amounts however much you need to whenever you need to.
Reference Transactions and Preapprovals may be something to look into as well. I actually wrote an article about what they are and how they differ from each other awhile back that you might be interested in.
Gidday
I'm setting up several subscribe buttons on my site, each without a free trial period, so the initial two IPNs, subscr_signup and subscr_payment are sent about the same time. I'm using the custom field in the IPN to hold the user's membership ID from my site (subscription is separate from signing up for an account).
I've read that Paypal doesn't always send those two IPNs them in that order.
Initially I was going to use the subscr_signup IPN to populate the member's subscription details, but I'm wondering, am I better off using the subscr_payment IPN to do that ie check if a sub has been set up, and if not set one up, otherwise just check the subscr_payment details against the database?
The payment IPN doesn't have the recurring field, but I don't need it, as all subscriptions are recurring on my site, and I can determine the type of subscription from the amount paid.
Or, would it be better if I set it up as a 1 day free trial, so the IPNs definitely come separately?
Thanks for your time and help.
Either way should work. Another option that some merchants have done, is written all of the information to their database and set up the account before sending the buyer over to PayPal to sign up and make the payment. Then the merchants would rely on the IPN to actually activate the IPN or activate it beyond it's free trial period. You could also set up a script to check your system periodically to see if there are any profiles that are deactivated and should be removed from your system, or that never paid.
Hey guys was hoping you could help me out.
I am integrating paypal (for the first time) in a website using PHP. From what I have read, there are two methods for confirming a successful transaction, PDT and IPN.
Now the thing is, the item's being sold can have a limited stock. So if suppose a person reserves an item and is taken to the PAYPAL site for final payment, I have to stop all other people from making a purchase since the last piece of the item will be "reserved".
But suppose the person (who has reserved the final piece of the item) goes to the paypal page, and then simply closes it. Will this result in a "fail" ipn coming to me (so I should un-reserve the item so others can buy)?
If so, how long will it take for the failed IPN to come?
If not, how exactly should I handle this.
And is there any scenario where an IPN does not come?
You could use the Express Checkout API.
With EC, the payment is a two step process. In the first step, you make an API call (SetExpressCheckout) where you set up the transaction, and redirect the buyer to PayPal. Once there, the buyer authorizes the payment, and returns to your site.
At this point no money has changed hands. You need to make a second API call in order to capture the funds (DoExpressCheckout).
You can hold the item for a specific period, and if the buyer abandons the transaction, or is very slow to approve the payment, you can release the item back to the public. If he eventually approves it, and does come back to your site, you would simply skip the second step, and inform the user that his transaction timed out. No money changes hands, no items are double sold.