TL;DR- How do I know if I really did get paid, via the PayPal NVP API?
Longer version
I'm writing code to automagically process and classify transactions from our PP business account. I have code that calls NVP methods TransactionSearch and GetTransactionDetails and fills a few database tables with the results that are returned. This happens every day for the previous 24 hours' worth of transactions. So far, so good.
I began from the assumption that the same information available via manual CSV export via the PayPal web interface would be available via the API, but I'm now discovering that either this is not the case, or there is another API call I should be making to get the rest of the information I need.
In particular, GetTransactionDetails doesn't seem to return the equivalent of CSV field "Reference Txn ID" and, in a few cases, I can't see how to connect related transactions.
So, my question is how can I obtain the reference transaction ID, or how do I otherwise connect these associated transactions?
Example 1
This is (probably) the most common sort of situation where the reference transaction ID is needed.
Depending on the buyer's funding source, you may either see a purchase complete instantly or, if the transaction must be cleared, complete across three separate transactions:
The original payment, detail of which gives buyer's name, email, address, invoice number, item ID, gross, fee and net amounts etc.
followed immediately by a debit of the net amount
followed, in a few days, by a credit of the net amount.
It is crucial to match the three transactions because you don't know whether the payment will succeed or be declined (and therefore whether you've actually got the money) unless you do.
In the data I have available to me at the moment, there is only one such example of this situation, and calls to GetTransactionDetails for the settlement transactions fail completely ("The transaction could not be loaded") — possibly because, in that one instance, I know that the payment was made with a credit card by somebody who doesn't have a PayPal account.
This might be an anomaly, or it might be the common case. I have seen this triplet of transactions quite frequently in other PayPal accounts, but not this one, so I can't be sure.
Example 2
A payment in a foreign currency will typically generate three transactions, rather like in Example 1:
The original payment (eg in €), the detail of which gives the sender's name and email address etc;
this is then followed by an immediate debit of the (probably net) amount in €
and then an immediate credit in USD.
From the point of view of the NVP API, GetTransactionDetails usually returns values labelled SETTLEAMT and SETTLEAMTCURRENCYCODE for the original payment. No further processing is required.
However, a recent such transaction (for reasons that even PayPal could not adequately explain) did not auto-convert, and the GetTransactionDetails call lacks the settlement values even after the conversion was performed manually.
The transactions are all there — but I cannot see any programmatic way to associate them because an attempt to call GetTransactionDetails on currency conversion transactions returns the error "You can not get the details for this type of transaction".
—
Any advice or experience relating to automatic processing of PayPal transactions? Is there any way to duplicate, programmatically, the same data included in the CSV export?
If necessary, I'd be happy to process the CSV export if there were some way to generate it programmatically, but I don't even know of a way to do that (short of a Selenium-driven solution full of pitfalls).
GetTransactionDetails will include a PARENTTRANSACTIONID if there is a related transaction. For example, a refund transaction would have a parent transaction ID.
Related
On the Paypal Basic Integration tutorial it is possible to capture an order client-side which essentially submits the payment to paypal. Once the order is captured, the tutorials shows you how to verify the transaction which would ensure you do not provide a service or product unless the paypal order is verified. However, someone could maliciously capture a payment using the client id and while verification would fail paypal would withdraw the funds from the customer. How can you prevent this? Is this secure?
[UPDATE]
This questions comes mostly out of curiosity and lack of experience with paypal. To put more context into this and hopefully help others; the Paypal basic integration is simply an HTML form and so it doesn't stop anyone from modifying the HTML form and send a different amount for authorization/capture; lets say that the original amount for an order is 100, it is possible that someone changes that amount and submit the authorization with the different amount; at the minimum it would initiate an authorization/capture of this different amount that perhaps is higher. Good practice dictates that the amount and orders should be verified before finalizing the transaction on the backend, but even if the transaction is found to be invalid the funds would have already been put on a "hold" by paypal and possibly on the customers credit card.
This is probably not an issue since, like mentioned, transactions should be verified on the backend; it is also not too obvious( maybe with some social engineering) how someone would benefit from this and most likely would just be an inconvenience.
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 am testing the PayPal REST API for subscriptions in the sandbox environment, and have noticed that, when going to the approval URL returned after creating an agreement, no price is shown under the order summary pane on the left of the page. A description is shown but no price/tax etc.
The plan id is passed to the call to create an agreement, which contains the information that I would expect to see as a user when approving the payment. Is this a bug or is there something that I am supposed to enable in the merchant account, or perhaps something additional that needs to be sent when creating the agreement? I've read other posts regarding this on stack overflow (although they predate the creation of the subscriptions REST API) talking about passing a transaction field, but this isn't valid in the subscriptions create agreement schema.
Your observations are (currently) correct. As REST API based Billing Plans are based on Express Checkout Recurring Payments, you're going to see a similar behavior.
Right now, there are two options:
You populate the description with more agreement details.
You pass a regular description and make sure the customer is aware of the billing terms before your execute the agreement.
Going forward, we're likely going to include this info in some later updates. I'm following up with that to make sure a user story is filed for this.
Is there any way to retrieve the transaction fee charged by Paypal using the REST API?
I've got a mobile application that makes a charge using the Paypal SDK, and then posts the transaction ID to the server. I'm trying to use this to get the transaction fee from Paypal.
Looking at the documentation, it looks like the fee should be returned as part of the details object, though it's not clear how to get this from the payment.
For example, if I get the payment using the following endpoint:
/v1/payments/payment/PAY-XXXXXXX
The response returns information about the transaction, including the amount and currency, but nothing about the Paypal fee.
I've also tried looking up the sale (/v1/payments/sale/XXXXXXX) but that doesn't return anything about the Paypal fees either.
Interestingly enough, I don't seem to be able to view this information either from the transactions grid in the web interface, but I'm sure this information was definitely available in the old version of the web interface (before the redesign).
Not sure if I'm missing something obvious here.
Unfortunately, despite being documented, it seems this hasn't been implemented. According to PayPal Merchant Technical Support, on 02/16/2015:
"Kindly take note that transaction fees will not be returned in REST APIs response and I am not being able to ensure whether this will be implemented in future."
I learned that fee tracking was a requirement for my company's PayPal implementation, and I ended up switching to SDKs as a result.
The details object of the amount object has a fee field, which when you look up the sale using the URL you mentioned above should be in each transaction in the transactions array.
This should return the value you are looking for.
This is more of a question regarding flow than code.
I'm currently working on a booking website for a holiday home. I've implemented a booking system which currently takes full payment at the time of booking. This uses PayPal REST API. It works fine no problems code-wise.
However my client would like the system to take a deposit when booking (20%) of the total. Then take the remaining amount later on (through the site). This seems strange to me and I've never used a website which does this so I'm not sure what the flow should be.
The only way I can think of achieving this is that the user has to come to the website at some point in the future to pay the remaining amount. I could send them email reminders but it seems a bit awkward to do that.
Has anyone done anything like this in the past?
In order to take the money later, you need to store the credit card data in your system, which is not quite legal unless you are authorized payment service provider (and I'm almost sure you're not).
We have the same case in our reservation system. Generally, you'd allow credit card payment only for deposit, and later final amount is paid via bank transfer or cash, for example, and has to be settled manually by an operator.
Your idea is not bad, however. You could inform the user about the final amount and due date in the booking confirmation email and later on send them reminders.
You can utilize reference transactions to handle this without storing/saving any billing information on your server.
Reference transactions can be used in Express Checkout as well as with Payments Pro.
Basically, the way it'll work is that you can process the original 20% and then you'll save that transaction ID in your database. Once you're ready to process the remaining amount you just make a call to DoReferenceTransaction and supply the original transaction ID along with the new amount to charge. PayPal will then charge this new amount using the billing information that they have saved on their server.