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.
Related
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.
I integrated PayPal in my web shop in order to allow instant payments with automatic product delivery (already had this before but only with instant wire transfers via sofort.com). I integrated it with the help of the example provided by PayPal (I'm using ReviewOrder.php, GetExpressCheckoutDetails and DoExpressCheckoutPayment).
It's working great if they pay with PayPal balance or a linked credit card. However, some customers from Germany don't have balance in their accounts but only a bank account linked to their account. The payments go through and they receive their product, however I noticed the payment status would remain "Pending" for 1 month and change to "Expired" afterwards, so effectively no money arrives.
Why is this happening? Or is there any way to deny such payments? (Payments from backup funds)
Any help would be appreciated.
Its hare to day with out looking at the transaction specifically. But there are several things that can cause your payment to be pending, such as your preferences that you may have set in the account. Check to make sure you dont have your preferences set to ask me before accepting a payment in a currency that you do not hold. Did the buyer pay with an eCheck? If so, it could be waiting for the payment to clear. If this is in the sandbox, you have to manually clear the payment. If you are still not able to determine the cause of the pending payment, if you provide the transaction id, I will check it on my end.
Hey guys I managed to find a solution to this odd problem after all.
It turned out I had the following code in my implementation where I actually initialized the payment process:
$_REQUEST['paymentType'] = "Order";
This was a mistake though, since this payment type won't place a hold on the funds and if the DoCapture call is never called this payment will remain pending for about one month and then expire entirely (as described in my question, so this is what actually happened to me). The bad thing is that it's impossible for such payments to even accept them manually from within PayPal (not even the local PayPal phone support was able/wanted to accept these payments for unknown reasons because they told me they'd come up with a solution and contact me via Email within 24 hours but they never did).
So in order to fix this issue I changed the payment type to Sale which instantly captures the payment rather than waiting for sort of approval or a capture call. It worked fine for two weeks now and I think I'll leave it like this now.
$_REQUEST['paymentType'] = "Sale";
I lost about 110€ because this stupidly trivial detail but at least it's working fine now and I was able to re-enable PayPal as a payment form. I hope they'll at least add an option to manually accept these payments if the DoCapture call was not implemented because it worked fine without it for most of the payments as well and after all this is still about real money, so this absolutely would be an essential thing to have....
This can happen also if you are trying to accept a payment in a different currency of your account. To avoid that you must create a "PayPal balance" in the currency of the payment.
IPN is also giving hints on the pending reason in this case:
[pending_reason] => multi_currency
I have gone through nearly all the question related to Recurring Payment using Paypal and have not found a solution to my problem.
We are implementing a system that is subscription based on a monthly basis (fixed amount). We do not want to store CC details for security reasons, hence we are trying to use Website Payments Pro from Paypal.
Once a user agrees to recurring payments, we are creating a RecurringPaymentProfile for that user and are storing the returned Profile_Id for the user.
Now we need to get information about all the transactions related to this Recurring Profile_Id. This information is available when we login to the Paypal account but this needs to be automated so that the application is aware of all the payments and also of the current subscription of the user.
We have found two methods (possibly) to implement this.
1. IPN (Instant Payment Notification, for this we will have to create a service to listen to notifications, which seems to be cumbersome and is more informational than we require)
2. TransactionSearch (but this returns transactions for the Paypal account and not Profile_Id)
Since we just want to know the transaction history associated with the Recurring Profile and whether this months payment was successful (implying the user is active member), what is the best method to implement this ?
Thanks,
You're looking for the GetRecurringPaymentsProfileDetails API Operation. This operation will allow you to view a majority of the details associated with a recurring payment profile using a valid PROFILEID.
Relevant detail fields you may be interested in:
LASTPAYMENTDATE
The date of the last successful payment received for
this profile, in YYYY-MM-DD format.
LASTPAYMENTAMT
The amount of the last successful payment received for this profile.
FAILEDPAYMENTCOUNT
The total number of failed billing cycles for this profile.
NEXTBILLINGDATE
The next scheduled billing date, in YYYY-MM-DD format.
NUMCYCYLESCOMPLETED
The number of billing cycles completed in the
current active subscription period. A billing cycle is considered
completed when payment is collected or after retry attempts to collect
payment for the current billing cycle have failed.
I'm having some trouble choosing between PayPal's Instant Payment Notification (IPN) and Payment Data Transfer (PDT).
Basically, users buy a one-off product on my site, pay on PayPal, and return to my site. I understand how IPN works but I'm now seeing that I might be able to trigger the various actions that take place after a successful purchase more easily with PDT, as the data gets returned there and then (as opposed to needing a separate listener).
However, PayPal's PDT documentation contains this cryptic line: "PDT is not meant to be used with credit card or Express Checkout transactions." ... but I can't find anything further whatsoever on the topic.
Are credit cards REALLY not meant to be used with PDT? I would like more than a sentence.
Does that mean that a user must have/create a PayPal account to pay?
Does it mean that if I want to allow users to pay with their PayPal accounts AND/OR with credit cards directly, I must implement IPN?
Could anyone who's gone through this kindly shed some light?
The APIs for PDT and IPN are similar. The main difference is when you receive the notification. For that reason I would recommend implementing both.
With PDT you get the notification instantly and can do any additional processing required and show the user a confirmation page.
With IPN you are guaranteed to be notified that the payment was received even if the user's computer explodes before it can send you the PDT.
Implement both and get the best of both worlds. But if you're only doing one, IPN is the reliable one.
One catch: if you implement both then there's a chance your payments could be processed twice. Take care to ensure that doesn't happen. The application I wrote handles the PDT and IPN almost identically (the backend part is the same) and that code acquires a per-web-user lock in the database, so that if the same user tries to submit the exact same payment multiple times it can only be processed once. Once processed the result of that process is re-used for any subsequent attempts to process it.
Edit
One more thing: IPN carries more information than PDT. There are lots of different messages that you can receive from IPN, such as chargeback notification, etc, and thus you really should implement it.
PayPal's PDT system sends order confirmations to merchant sites that use PayPal Payments Standard and lets them authenticate this information. Such sites can then display this data locally in an "order confirmation" page.
When to Use PDT?
IPN provides the same capabilities described above. So, when should you choose PDT instead of IPN?
With PDT, your site is notified immediately when a customer completes payment. With IPN, however, there is a material lag between the time a customer completes payment and the time your site receives notification of this event.
So, use PDT if your site includes a feature that requires immediate payment notification.
For example, consider a digital music store. With PDT, this store can let customers download their purchases right away since PDT sends order confirmations immediately. With IPN, such immediate order fulfillment is not possible.
Advantages of IPN
PDT has a a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually guaranteed since IPN resends a confirmation until your site acknowledges receipt. For this reason, PayPal recommends that you implement IPN rather than PDT.
Another advantage of IPN is that it sends many types of notifications, while PDT sends just order confirmations. So, using IPN, your site can receive, for example, chargeback notifications as well as order confirmations.
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT. However, if you do, your site will receive two order confirmations for each sale. As a result, you must be careful to take action (say, ship a product) on just one copy of a given confirmation message.
Documentation Here
Re 1. PDT is meant to use with Auto Return for Website Payments feature. Auto Return redirects to PDT site after paying money to seller. Unfortunately it's not possible to use that feature along with PayPal Account Optional - used to enable Credit Card payment. Here is note from PayPal: 'If you have turned on Auto Return and have chosen to turn on PayPal Account Optional for new users, a new user will not be automatically directed back to your website, but will be given the option to return.'. User will have an option to go back to your site(PDT step) or stay on PayPal site. To sum it up when paying by Credit Card user can skip PDT step if user will not click 'return to store link'.
Re 2. It is up to you what paying options do you want to allow. If you want to allow paying without a PayPal Account you can enable Account Optional. If you want to allow only users with PayPal accounts disable that feature. There might be more options.
Re 3. In your case you need to trigger action after successful purchase. Recommended way would be to implement IPN. PDT doesn't work for all cases and doesn't guarantee message delivery. Here is link to doc covering that topic PDT vs IPN.
This is an old question, but my simple answer would be - Why not use both PDT and IPN? They will work fine for card transactions.
PDT can provide the immediate transaction status to your website, where you can quickly check the payment success or failure status and provide the user with appropriate message.
Meanwhile, you can await the full verification from IPN in the background. Once received, you can use this to further update your DB and process the order.
You can follow this step-by-step guide which I found to be very clear and helpful - and it's still valid in 2018.
https://www.codexworld.com/paypal-standard-payment-gateway-integration-php/
I wanted to use Paypal's IPN service to verify payments for a recurring subscription charge for my website. How do you tie the IPN confirmations to a user in your site?
The IPN confirmation message has a name, email, paypal ID, recurring payment ID, but it seems to not give a unique identifier since I don't know where the paypal ID or recurring payment id comes from and it may not be trivial to uniquely match up the name/email that a user has on their paypal account (or entered there) with the name/email I have for them on my site (there may be many John Smith's and the person may choose to use a different email.)
1) When I send the initial payment request to Paypal, I can attach a unique UUID in the URL I ask them to send back to me, so if I save that unique ID for that user I can match that payment confirmation to the user who initiated it. Am I making that harder than it is? Is there an easier way?
2) Also, for a recurring/subscription charge, does paypal always use the URL I specified with the initial payment initiation? Does anyone have practical experience using the recurring Paypal payments with IPN's, does it reuse that unique URL? Or do I have to associate the Paypal ID's with the user after the first recurring payment is received?
Attaching unique data to the payment request is pretty much the accepted way to do it.
I don't have any experience with recurring charges.
I recently also set up some reoccurring payments with Paypal.
I actually wanted people to register as members after paying for the subscription, if they wanted to. As having to sign up as a member could add some friction to the sale process. So I don't send any user info along with the Subscribe button.
What my IPN script does is generate a unique activation code tied to the Paypal subscriptionID in the Activations table, then it sends this code to whoever paid for the subscription, with instructions on how to activate.
At the point of activation, you need to register or login. At this point the userID is added to the relevant row in the Activations table.
When the EndOfTerm IPN notification comes in the IPN script looks up the userID from the Activations table based on the SubscriberID given in the IPN. Then I can do whatever I need to do to that user to disable their subscription.
At all time the URL of the IPN script remains the same.
1) You can send an 'item_number' parameter with the initial subscription setup, which will get passed back to you. I'd suggest embedding an identification token in it.
2) If you mean the 'return' parameter, no, that's for sending the user to at the conclusion of the subscription setup. The renewal is automatic and doesn't 'ping' that page.
1) You want to be using the item_number parameter. Set this in your HTML form shown to the customer, and it will be returned to you by the paypal IPN, so you can put a database row ID in here, and use it to match up to the right person later.