If I have the max number of failed attempts set at 3 on a recurring billing profile will the status automatically change to CancelledProfile or SuspendedProfile when the payment fails 3 times?
Actually, PayPal's system seems to ignore that parameter altogether and follows the same practice no matter what.
If a recurring payment fails it will re-try in 5 days. It will do this 3 times, and if it fails that last time it will indeed suspend the profile at that time.
It always does 3 attempts regardless of what you set the max number of failed attempts to in my experience. If you have IPN configured you'll receive IPNs at each attempt and for the suspended profile.
Related
I'm trying to know what is the effect of setting initial_fail_amount_action and max_fail_attempts when you create a recurring payment plan.
First of all I'd like to know how often a retry is executed because in the PayPal documentation does not say nothing about that. For example, if you define a max_fail_attempts to 3, what does it mean? Paypal tries every hour, every day the payment? What is the interval? What is the final status if the whole payments fail? Cancelled or Suspended?
Then, I'd like to know what happen if I set the initial_fail_amount_action to CONTINUE. In the documentation I've found that PayPal add the failed payment amount to the outstanding balance due. What does it mean? Does the subscription remain pending or what is the final status?
Finally, what is the IPN notification do I receive after max_fail_attempts reached?
Thank you so much!
PD: I've added this question on github as well.
When using the Paypal Express Checkout API, I've created a recurring payments profile, and set up an endpoint to listen for IPN messages.
I've received messages at this endpoint with a txn_type of recurring_payment_skipped.
The documentation is a little sparse on the details of when these messages may occur:
Recurring payment skipped; it will be retried up to 3 times, 5 days apart
What would cause a recurring payment to be skipped? What happens after the 3rd retry?
Skipped basically means failed. This could be due to the funding source(s) available (or not available) on the payer's account, it could be something like a daily limit reached on the payer's credit card, or anything else that would keep the payment from completing.
After the 3rd retry if it hasn't completed successfully it will automatically suspend the profile. At that point you would have to collect the outstanding balance and then you could reactivate the profile.
We use PayPal for a subscription service and are seeing failed transactions in the recurring payments due to:
Result Code: 101
Response Message: Timeout value too small
This is not during the initial transaction when setting up the profile but later on once a payment is due (i.e. it's out of our hands.)
I wouldn't imagine the timeout value provided to PayflowConnectionData in the .NET API wrapper would be remembered for subsequent transactions would it? Stranger things have happened!
We are using paypal recurring payments programmatically using the Express Checkout APIs.
Based on the docs, it seems that the profile can take up to 24 hours to activate. I'm trying to figure out how to setup the billing start date such that it charges on the day that the profile activates, rather than forcing it to wait up to 24 hours.
Based on the API docs, it seems that I need to pass in the start date at the time of profile creation, which has forced me to do (today + 1 day) to force the 24 hour delay. But then if the profile activates right away and I get an IPN message, i still have to force the customer to wait for that 24 hour period...which doesn't seem very nice.
Although i can do an initamt for an upfront payment, I'm trying to avoid doing it b/c i think that would make me reduce the renewal period (e.g. if it's a 6 month subscription, i would charge 1 month upfront and do a 5 month recurring.), which would be confusing for the consumer.
I'm hoping someone can help me with this.
Docs.
Just wanted to follow-up on this. I spoke with PayPal today to clarify the issue.
They recommended using an initial payment to charge right away and then reducing the subscription term by 1 interval. So if you have a six month payment, then do a 1 month charge immediately, then do a 5 month recurring. Seems sort or ridiculous and partially confusing for the consumer.
They also confirmed that the initial recurring profile step may be delayed up to a day b/c it is run as batches.
Put that together with the fact that the system skips February for end of month payments (they adjust to the first of the month), and you've got yourself a lot of fun times ahead.
Ya it's best to do an initial payment and then subtract one from your interval or put your start interval 1 unit into the future.
Also note that if the initial payment if unable to be charged the API call will fail where as without the initial payment the API call can go through (success response) but when the payment gets charged (up to 24hrs later), it has the chanced to not be successful.
ie. credit card is good so it approves the recurring billing but when it attempts to charge, for some reason it gets rejected.
Make sure you have IPN listeners for recurring_payment_skipped to take account for that.
Simply charge for 6 month instantly and set the recurring payments to start after 6 months from the moment of initial payment.
I am adding subscriptions to a site using Paypal IPN which works very well, I can successfully create a new subscription and verify it. The subscription has a two week free trial. The guide was unfortunately a little vague on subscription statuses.
At the moment, the users account gets subscribed status once subscr_signup or subscr_payment is received and gets removed when either subscr_cancel or subscr_failed is received. I believe this is correct but it's best to make sure.
Also what is subscr_eot? the IPN guide describes it as "subscription’s end-of-term." Does this get triggered after the trial period is over?
subscr_eot is sent when a user's last paid interval has expired. subscr_cancel is sent as soon as the use cancels the subscription - for example:
User signs up on day 1 for a subscription which is billed once a month.
subscr_signup is sent immediately, subscr_payment is sent as soon as payment goes through (usually immediately as well).
On day 13, the user cancels. subscr_cancel is immediately sent, although the user has technically paid through to day 30. Cancelling at this point is up to you.
On day 30, subscr_eot is sent - the user has cancelled, and this is the day which his last payment paid until.
Not much changes with trial subscriptions - if a user cancels before a trial subscription is up, subscr_cancel is sent immediately, and subscr_eot is sent at the end of the trial.
Also, one interesting detail is how subscr_eot works with subscr_failed.
It looks like subscr_eot comes after the FINAL subscr_failed. So if in your account you set it to automatically retry failed payments 3 times, then it should go like this:
first failed payment => subscr_failed
second failed payment => subscr_failed
third failed payment => subscr_failed and subscr_eot
so basically in your code you can set subscr_failed to trigger an email like
hi user,
please take moment to check
your payment info, you may need to
update the credit card expiration
date, etc. You still have access,
we'll try again in a few days.
And setup subscr_eot to actually turn their subscription off and trigger an email like
Sorry, we still havent' gotten payment
and have taken your profile down. You
can still reactivate it by logging in and updating your payment info
Basically this is the "nice" way of doing it so customers have a grace period, and their account isn't shut off unexpectedly just because of an expired credit card or something like that.
The thread posted by Chris has been updated recently.
Sometime in 2010, PayPal stopped using subscr_eot when a user cancelled their account. After a number of complaints, they reinstated this, but took 6 months to do so. All this means is that you can once again handle your subscription notifications as described by Peter in the accepted answer.
From a PayPal representative:
subscr_cancel means the profile is
canceled and there will not be future
payments. However, if the buyer has
already paid for the current billing
cycle as they are charged up-front,
then you can use the subscr_eot to
terminate the profile.
Still unsure what happens in the event of multiple failed payment attempts, however. PayPal documentation at the moment is terrible.
It depends on the account if it is new or not whether subscr_eot gets sent, which is kinda beyond me?
I haven't found the proper way to manage subscriptions yet. Calculating the dates on the server could go wrong very fast if there is a delay in payment.