I have a server side code that captures orders that are approved by the user. Before capturing the payment I want to double check that the amount payed by the user is the right amount, and if it isn't I want to cancel the order instead of capturing it.
What is the right way to do this? If I just don't capture the order and delete the order-id on my end, is this enough? Or do I have to manually cancel the order and if so how?
The PayPal API had a Cancel Order call in the earlier version but they don't anymore. I also saw mixed answers in another similar thread. Some say the payment approval made by the customer will expire if not captured, but some others say approved orders HAVE TO be captured, so I'm confused. There doesn't seem to be a clear answer on their API documentation either.
If I have to capture every approved order then how do I make sure the payment amount is correct?
For Orders V2, do nothing. Forget about the id
Related
I'm using Paypal Orders API (v2) on a website and multiple times there has been an approved order that are missing captures complete.
I get this event for all orders:
CHECKOUT.ORDER.APPROVED
But for some orders, this event does not occur:
PAYMENT.CAPTURE.COMPLETED
How does this happen, is it because a customers credit card got declined?
Make sure the actions.order.capture() function is being called properly.
I had the issue where I wanted my server to validate the payment was successful. So, I replaced the onApprove function, with a call to my server. When my server requested the order, it always said it was APPROVED, but no money was ever transferred.
The issue was that you don't replace the onApprove function, rather, the onApprove function still needs to call actions.order.capture(). This method will then transfer the money, and mark the order as COMPLETED.
A decline is one possible scenario.
Reaching an order review page and not clicking on the final action that triggers the capture, is another.
Those are both normal events and not indicative of any problem.
Theoretically some type of technical error could also interrupt the process and contribute to this type of drop off, but that is not likely unless you receive specific reports of an issue.
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 have looked around SO for this but I can't seem to find anything like it.
On my service, I wish to charge on a per-month basis depending on how many users my clients have.
So this question is split up into two parts.
What I want to know is it possible for a client to use their own paypal account (without entering any CC details) with conjunction with CreateRecurringPaymentsProfile via the NVP, I have looked through the documentation and can not discern anything. So clearly it is not possible to do it via NPV - From what I've seen so far.
i. If I do an Express-Checkout Subscription, I can do 20% change on total amount every 180 days (I DO NOT want to do this) - I want to be able to get the Profile via the IPN and then modify the monthly amount on as-need basis
ii. There was some mention of Referenced Transactions, but the Documentation is very confusing.
So say there is a way to create a recurring payment subscription via a PayPal Account on the PayPal website, next step is to be able to update the Subscription via UpdateRecurringPaymentsProfile NVP command.
While I am happy to pass on CC details (which already works great), I am just wondering if it is indeed possible create a button, which would create a Subscription - once on success an IPN request is sent back with the ProfileID which I can modify the Billing Amount by NVP.
So TL;DR;
The current flow I have
Register on our website
Enter CC Details
Backend submits the data to PayPal and if passed - continues on.
On any Account modifications, update Profile Monthly Amount Automatically.
The flow I want
Register on website
Click on an Authorize Button Redirected to PayPal
Login to their PayPal Account Create Recurring Profile.
On any Account modifications, update that Profile Monthly Amount Automatically.
edit to add - this is all working now, had to contact and harass PayPal directly for a lonngg time.
I'm a little confused because it sounds like you answered your own question, but then said that's not what you want..??
Express Checkout does exactly what you outlined at the end of your post, and it triggers an IPN just like any other PayPal transaction. You are indeed limited on how much you can adjust the amounts of profiles created with EC, though, just like you mentioned with the 20% every 180 days. If you create profiles with Payments Pro (DoDirectPayment or PayFlow) then you're not limited and you can adjust the amounts however much you need to whenever you need to.
Reference Transactions and Preapprovals may be something to look into as well. I actually wrote an article about what they are and how they differ from each other awhile back that you might be interested in.
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.
I am trying to setup Google Analytics Ecommerce Tracking. I appreciate this can relatively easily be done using PDT but I can't find any reference to using the IPN page to track the sales (which makes sense because a user never actually visits these). We use IPN to track the successful orders and it makes sense to tie the tracking in with this as this is the point that a successful order is flagged. We could in theory use PDT as well to track the sales but this will not contain all of the information for the transactions and (more importantly) the sale may not have actually completed when the PDT variables are passed back. To me this makes it much less desirable as it won't always be completely correct. Does anyone know of any way to use the ecommerce tracking via the IPN page instead, or is this not possible (or not sensible for another reason)?
Thanks so much as ever guys,
Dave
I'm facing the same issue. There could be a part of a solution, that could lose some transactions, by doing this:
set a cookie on the user's browser just before he's redirected to Paypal (or on the final basket), when you set your Order ID.
the user is sent to Paypal
Paypal IPN is triggered
user goes back to your website (one day, he will!)
read the cookie you've set, on your «my account» pages for example, and if it matches an order:
Paypal status «Completed»: add the Google tracking code, using order ID, then delete the cookie
Paypal status not «Completed»: don't do anything
It's not 100% perfect, as some transactions may never be tracked, but at least it's the same user who executes the tracking code.