I'm using the Express Checkout flow with the advanced server integration.
So I reserve items in real time once user has clicked the "Checkout" button and wait for the success\fail response. User can just close the browser tab and it will look like a long payment process (there is no way for the JS code to call the onCancel handler).
So it looks like I don't know if user has closed the browser or just fell asleep. Problem that I can't wait too long (more than ~5 mins) and I want to cancel the payment after this time. And it seems that I can't cancel the Payment myself. So user can come back and pay after N minutes (N > 5) for the item which has been un-reserved and is already out of stock.
This answer says:
user has three hours to approve of the PayPal payment
Answer about 3 hours is a bit old so do we have any fresh DOCS about the immediate payment lifetime? Is it still 3 hours for the REST Express Checkout flow?
3 hours is too long period for me. Is there a way to setup the expiration time or timeout for the payment during creation?
Is there a way to cancel the Payment? Payments API has no reference about it.
You can do a GET on the PAY-XXXX id.
https://developer.paypal.com/docs/api/payments/#payment_get
The response comes with a create_time field. You should be able to check the delta from create_time -> now, and if it's > 5 minutes, don't accept the PAY-XXXX id / cancel the transaction in your database.
Does that work for your use case?
Also note: No money is moved until you call execute, so long as you prevent execute calls for old transactions, you should be ok.
I think it is still 3 hours and there is no way to set it up during the payment creation. But i would assume that buyer cannot pay until he returns back to your site either by approving or without approving. So is it not possible to put a check in between the step where buyer comes back and then call to complete the payment is made?
Related
I'm using paypal adaptive payments to make transaction via paypal. Although few of transactions are taking more than 6 hours too receive IPN.
I've gone through forum posts and their documentation, I came through - https://developer.paypal.com/webapps/developer/docs/classic/products/instant-payment-notification/
"Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."
The callback is taking more than 6 hours is way too much. any suggestions ?
I've built several custom carts. On average, I see the PayPal IPN come back within 2 minutes at the longest, and usually recurring payments take longer than single payments because they send two IPN messages, not just one, on the initial setup. I usually take the 'custom' property and put a unique identifier that I have permanently cookied. So, even though I may see an initial IPN come in on a recurring payment, I wait for the one that says that txn_type is subscr_payment and also that payment_status is Completed. You can't really trust a subscription payment as being paid unless you see that second message. And if it's a single payment, then I look for txn_type to be web_accept and payment_status to Completed.
The way I handle things is to redirect the customer to PayPal to purchase using the form button technique. The customer pays and then gets redirected (thanks to the form hidden vars I created initially) back to my own custom cart URL that I specify. I call that URL the payment-confirmation script. I display a message with a progress bar to please wait while their payment is being confirmed with PayPal. I hold them there 10 seconds and then redirect to the receipt. It is on the receipt where I check the database to see if my IPN script has already processed this order. If not, then I redirect them back to the payment-confirmation script again for another 10 second progress bar delay. My receipt uses a session cookie to ensure I never send them into a loop more than one time to the payment-confirmation script. So, the customer waits another 10 seconds and then comes back to the receipt page, where I test again, reading my permanent cookie on the 'custom' property that I saved, versus the 'custom' property that comes in from the IPN that I use as the order key in the database. Usually within the first or second 10 second delay, the IPN has come in and I can proceed. However, if the IPN has still not come in, then I redirect to a friendly error message saying that their payment cannot be confirmed and to call our call center to remedy the issue. Our call center techs then see the delay problem in PayPal, back the other transaction out, and sell to the customer over the phone manually, instead.
I have read a lot of stuff and spent hours on studying the PPs API.
There is one thing I don't understand and would like to know how can I do this.
When sender sends money form the bank account (not cc) it's called echeck and it takes up to 5 days.
In some places I can see that people say
you can't cancel echeck once it's approved. you can only ask seller to cancel your request/ payment.
but on some other sites I can read
buyer can cancel transfer any time, so do not ship the items untill you get final confirmation.
So what's the final answer here, can the buyer cancell the echeck/ transfer or not?
What if they approve it, but after one minute get rid of all the money form the account, and there is nothing they can be charged for?
And the second question: I can see that in the account setting you can disable acceptance od echecks. but how can this be done via API? I mean on my website I will have different sellers and I can't check if they have echeck enabled or not, so I would like to block echecks automatically via api. So, how can I block echecks using API
Buyers can't cancel an eCheck once they've initiated it. They would have to request a refund from you after the eCheck completes. (P.S. -- it's always a good idea to wait for the eCheck to complete before giving the buyer their goods. Just because an eCheck was initiated doesn't automatically mean that it will clear -- the withdraw from their bank account could still fail.)
If you're using Express Checkout, you can set PAYMENTREQUEST_0_ALLOWEDPAYMENTMETHOD=InstantPaymentOnly to disable eChecks.
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.
We are using the "Website Payments Standard" method and now we would like to set a timeout (30 minutes) on our customer payments. In other words the customer must complete the payment registration within 30 minutes, otherwise he must do the process all over again.
My issue is that I can´t find and variables in the API that fit my needs.
Does anyone have a solution for this issue?
see: https://www.x.com/developers/paypal/forums/adaptive-payments-api/cancel-or-timeout-payment
At this time, there is not a way to cancel a paykey and a timeout value cannot be specified. The default timeout value for PayPal is 5 minutes (after being inactive) however a paykey is good for 3 hours. So if the user were to copy the redirect url (before logging in), that url (with paykey) would be good for 3 hours.
So...there is no solution :(
If you switch to Website Payments Pro, you could have more control over this (where final payment is taken on your site, not Paypal's), but there isn't a way with Standard because they leave your site and if they return, it's only after they have paid..
Just to be simple, you cannot have a timeout in Standard mode but you can have it in Pro mode.
I'm currently using the Paypal's PDN method of data transfer to keep all my transactions made through the Paypal shopping cart in a MySQL database of my own.
However, when Paypal redirects a customer to my handlePayment.php page, it takes about 10 seconds to do so. If the customer closed the window, the payment would still be made but the order wouldn't get posted to my database.
Is there a way where I can either:
a) speed up the redirect so it's instantaneous?
or
b) add a description under the store title in the paypal shopping cart, that says "please wait to be redirected after you complete payment?
Do both. Whichever arrives first wins, and the other gets ignored. The payloads are similar, so there's not much code to add.
If you rely solely on IPN, it might not have arrived by the time the visitor gets back to your site (especially if they click to it rather than waiting for the redirect). But if you rely solely on PDN, you get the problem you describe. So do both.