I am building a paypal subscription system but i have some difficulties to understand some points. When using sandbox i can't simulate a payment denial process so when the payment is made, paypal redirect me to my "approval url callback" and a billing agreement is created.
So i want to know , in a real situation, will paypal redirect me to the approval url and create this billing agreement even if the payment didn't occur yet ? or this one can be created if and only if the payment is accepted ? (So if paypal denied the payment the billing agreement will never be created)
In my case, my customers will need to access to some paid features of my website so, should i wait for the "ipn webhook notification (PAYMENT.SALE.COMPLETED)" which can take several minutes to be fired to my endpoint, or can i grant access immediately after the billing agreement is created ?
Which is the most secure thing to do ?
thanks.
If the user cancels the checkout, Paypal will redirect to your cancel URL.
But the failed payment cases are not clear to me either. I believe that the agreement will be created even if the payment fails, since it needs to exist for the payment attempt to be done, but I don't work at Paypal :).
My approach is to activate the subscription on a successful redirect no matter what, [edit: the execute response returns an agreement_details.next_billing_date in the past, so you can't use that] with a short initial subscription expiration (4h). When our webhook receives a PAYMENT.SALE.COMPLETED message, we fetch the agreement billing agreement details, and update the subscription expiration to the new agreement_details.next_billing_date. But if the webhook receives a PAYMENT.SALE.DENIED, we just let the subscription expire.
HTH.
Related
I have integrated paypal php rest api to create plan and then I have create billing agreement for this plan but the issue is payment is not deducting instantly and I want to know that how will came to know that payment is deducted from payee account.
after executing billing agreement I get object of billing agreement as response and in that object it show that billing agreement is activated but in payee's account transaction status of agreement is pending in response object outstanding amount is also zero
I want to know way to identify that amount is deducted form payee's account or not. so that I can take action accordingly.
I have solved this issue but for this I have to use callback or we can say webhooks
One more thing was there is
Webhook never works on subdomain and ssl is also requiered .
I'am having troubles about how to handle the paypal recurrent payment system.
I followed every instruction in the website, but once i create the profile, paypal puts it in pending, making me doubt about the reliability of the service itself.
I tried to look over the internet but i didn't really get how this should work...
i made the first call with SetExpressCheckout in order to create the request, when the token is returned, i send the token to the paypal page, the user confirms the payment, then i call the CreateRecurringPaymentsProfile method to confirm the operation (passing PAYERID and TOKEN and setting the AMT value for the first payment and the PROFILESTARTDATE as now +1 month for the future payments)
Now when i try to read the response from the last call (or if i go to the buyer/seller paypal account) i see that the payment is in pending and i have to wait an undefined amount of time before this payment is activated.
Now the real question is: can i trust the fact that even if the payment is in pending, i'll receive the payment and so i can set set the user as member or i have to check and wait until the status is 'active' with the GetRecurringPaymentsProfileDetails method?
PS: i'm doing this in the sandbox version, maybe the official version is a bit faster and more reliable?
Thank you!
In Sandbox as in Live when you call CreateRecurringPaymentsProfile you will also get the response in which it will give you the status of the profile (ActiveProfile or PendingProfile). When the status is in Penidng it means that the system is in process of creating the recurring payment profile. You can then check your IPN messages for an update. It is normal but obviously if you notice that all the profiles you create get into Pending and never activate then there could be a bug but should not be the case. In here is the PayPal technical guide for this API: https://developer.paypal.com/docs/classic/api/merchant/CreateRecurringPaymentsProfile_API_Operation_NVP/
I'm not a developer, but a project manager. So please excuse my lack of proper language.
We are trying to figure out how to handle subscription refunds and then limit account access on the site.
Here's a scenario. Member signs up for an annual subscription to gain certain capabilities in the account. 3 months into it member decides to cancel and requests a refund. Normally, if no refund is issued, subscription is good until the end of the billing period, at which point account is deactivated.
In our case, if a refund is issued, account should be deactivated immediately. Question: is it possible to set this up as part of PayPal Subscriptions? Some type of call from PayPal to our system that will trigger account deactivation.
Thank you.
We recommend using IPN (Instant Payment Notifications) to be asynchronously notified of any events, in this case of those related to existing subscription/recurring payments.
https://developer.paypal.com/webapps/developer/docs/classic/ipn/gs_IPN/
If you enable IPN notifications you will receive a POST of PayPal in the following events (among others):
When a recurring profile is cancelled.
When a refund has been made to a previous completed transaction.
This way, you can set up your IPN script to keep the subscription “open” in your side for the remainder of the month even if the profile has been cancelled, or to deactivate it if the last month has been refunded.
For more information about IPN variables:
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNandPDTVariables/
Here is the scenario:
on 25/3 user purchases a basic monthly subscription (recurring payment profile)
on 7/4 user cancels basic monthly subscription and start a premium monthly subscription (a different recurring payment profile)
Now my question is whether I am going to receive a "subscr_eot" on the 25/4 (referring to the first basic monthly subscription) or is PayPal smart enough not to send subscr_eot since the user has started a new recurring payment profile with me?
I would like to set the user profile to "no subscription" as soon as I get a "subscr_eot", but I am not sure whether I can trust PayPal to notice that a new subscription was started between cancellation and end_of_term.
If it's canceled then the end of term was never reached. In such a case you'd get an IPN with txn_type=subscr_cancel. You would then get another IPN with txn_type=subscr_signup when the new profile is created.
That is assuming you're using standard subscriptions. You specifically mentioned subscr_eot, so that's why I made that assumption. However, you also mentioned "recurring payment profile". The Recurring Payments API is separate from standard subscriptions and would have different txn_type values for IPN, so if that's what you're actually using you'll need to adjust accordingly.
We are using Paypal recurring billing service (using Express Checkout) at our website for monthly subscription.
Since we have an Australian account so we are not able use the DPRP (Direct Payment Recurring Payment) service offered by Paypal because it seems, DPRP service is limited
to only few countries (US, UK and Canada).
In Express checkout payment details are received at Paypal Website. So we do not have any information, whether the payment failed, user pressed the Back button in browser or He/She intentionally clicked the cancel payment.
After speaking to Paypal support team we get know that there could be multiple possible reason for Payment failure, and seller has to contact Paypal by themself. So we can
not provide any troubleshooting for that at our website.
So we want to know, Is there any possible solution to avoid this or atleast can we diffrentiate between the user for whom payment failed and who intentionally moved to
our website back without doing payment because this way we are not only unable to followup with them but also loosing a part of the customer base, interested in our service.
Any help in this is Appreciated.
Thanks
You should implement the Pay Pal IPN (Instant Payment Notification).
You configure the IPN url address on your PayPal merchant account settings. This page is simple HTML page with server-side programming that is listening for requests coming from PayPal.
There's no need to do something extra in the checkout process for making IPN work. Once you set this up, it will automatically work.
Every time something happens with a transaction in your merchant account, e.g. transaction completed/failed/canceled, PayPal will send an HTTP Post to your IPN listener URL.
Here you can get all the relevant information about the transaction, like the payer ID, the payment status. With this information you can decide what to do with your customer's order.