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!
Related
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.
Similar to the post: Does PayPal Standard automatically retry to charge the client if a payment fails?
But about how the client can make it retry manually lets say after they have put more funds into their paypal account but before paypal automatically retries in a few days time.
When you use subscription - the automatic billing is handled by PayPal, and the retrying interval is fixed in this design, the client will not be able to trigger a manual recurring transaction / payment retry.
If the use case behind the question is about how the merchant(you) handles the flexible subscription billing period calculation upon payment failure/retries, it would be recommended that either you make fixed billing period start dates (continue the subscription) regardless of the payment delay, or suspend the client's subscription when payments failed, and resume it (calculate the new start date) when payment retry worked.
Both of the status/events above will trigger IPN messages to your listener, so that you may proceed either logic based on that.
We are building a new website for a take-away service and are integrating with PayPal Express (Using the NVP API). As orders are dispatched the same evening eCheck payments have been disabled.
The process we're going to follow is as below:
User places order with PayPal and when using DoExpressCheckoutPayment the action used is Authorization
The takeaway confirms the order and a DoCapture request is made setting the complete type to COMPLETE
It is my understanding that at this point, so long as the response status indicates it has COMPLETED that the funds are guaranteed. In fact, apart from very rare scenarios, it should usually be guaranteed at the point of Authorization.
Therefore I do not see the requirement for the IPN? There are no further notifications to be received with a given transaction. I could see the benefit it we were taking eChecks but when that's disabled does it offer anything?
IPN is an optional "messaging service". Your checkout/purchase flow doesn't have any "dependency" (shouldn't as PayPal puts it).
IPN is an asynchronous message service, meaning that IPNs are not synchronized with actions on your website...
...
The IPN message service is not a real-time service. As a result, your listener may not receive an IPN message for many seconds after an event occurs. As a result, your checkout flow should not depend upon receiving an IPN message to complete. If it does, your checkout flow will be slow during periods of heavy system load and complicated, since it must handle retries.
It's been some time for me, but you are correct about IPN being very helpful if/when you support eCheck - re: notified when Paypal has cleared the check/funds (if memory serves, 1 - 3 business/banking days).
Hth...
I'm having trouble getting to the bottom of a bug that seems to stem from our system not having received an IPN callback for a held transaction.
Here is the transaction history as shown on the Paypal website:
And here are the callbacks that registered on our system:
On Jul 25 we received only one callback, for the payment, but none for the temporary hold that's showing on the Paypal site. This is leading to incorrect balances, as it should balance out to zero in this example, but in our database it ends up giving the customer $200 credit.
From the site and docs I don't find any mention of callbacks for held transactions, and it's not on the list of callbacks I can test as far as I can see:
Canceled_Reversal
Completed
Denied
Expired
Failed
In-Progress
Partially_Refunded
Pending
Processed
Refunded
Reversed
Voided
I'm unsure whether our system just missed a callback, or whether there is none to be expected and we should be doing something else. What is the expected sequence of events in the case where a transaction is put on "Temporary Hold"? Any help would be appreciated!
You must have missed a Reversed callback which took the funds out.
If the case was decided in your favour you will then get a Canceled_Reversal transaction which gives you the funds back again.
I'm trying to test a few failure conditions using the test version of our pay-pal api. Specifically a recuring payment with an initial payment. Therefor I'm using the recurring payment adding an additional transaction. When testing for success (amounts less than $1000 for both recuring and initial transaction) everything works as expexted. According to the paypal documentation using amounts over $1000 should result in a response code that is the amount over $1000. regarless ov the amount I use the response code is 36.
I've also tried amounts over $2000 which should result in a response code of 12. However I still get 36.
The only details changing between the call that works as expected and those that don't is the amount.
Update
Upon further investigation, the recurring transaction response is 12, as expected. However the transaction response, which I'm assuming is what I need for the additional transaction is still 36. This is what I need to be testing against.
I've also tried different test card numbers as supplied by pay-apl.
On a side note... I realise this is not a programing question per-se, but I've been bounced here by pay-pal as their "Forum"!!!
Further Information
I am using the .net api(SDK) as provided by paypal