I am trying to setup a website with a backend to capture papal orders and payments using their orders API.
Everything is expected to be controlled using code so is there any way paypal will send a callback when there is a dispute or customer asks for a refund ? i.e. if there are many orders it would be hard to keep track of disputes by reading emails.
Yes, check out the PayPal API documentation. The Disputes API is what you are looking for.
Set up a webhook listener on the REST app for the events you want to listen to (specify * for all). There are events for disputes and refunds; see the list in the PayPal documentation
Related
I have REST API created Payment Plans and agreements and would like to be able to detect when a user cancel an agreement. My original take on this was that the cancel_url on the merchant_preferences object for billing_plan would be used if a users canceled the agreement through the PayPal API, but I am not seeing any callbacks coming in so perhaps this is incorrect?
I have seen plenty on information on IPN processing cancellations and I would love to know if that is the only way to receive a cancellation notification or should I be using another field in the REST API to set this up?
I'm not against using IPN (hey whatever gets the job done!), but it seems to me that the REST API should have its own capabilities for achieving this as well.
Hey this is Avi from PayPal. Refer to this github issue for information about getting IPN notifications for subscription events.
The REST API does have webhooks, and work is in progress to support subscription events for webhooks as well.
Does the Paypal provides any api to retry the IPN message using message id? I need to integrate functionality similar to the "resend ipn" button available on IPN history page of paypal.
There is no API to trigger the resend of an IPN, but there are API's to obtain the details that would be included in an IPN for a given transaction, so depending on what you're doing that make work for you.
For example, the combination of TransactionSearch and GetTransactionDetails can be very useful.
I have been working paypal integration to an existing system of ours and successfully done tests on sandbox by using rest api and express checkouts.
Although documentation is detailed, I couldnt see anything about chargeback (i.e reverse transactions) and cancellations on rest api documentation page http://developer.paypal.com/docs/api/
So in case a user buys something successfully and the payment status becomes "completed", then there is a reverse transaction like chargeback, paypal will send a request to the return and cancel urls which are predefined while creating the related payment, or the client application has to check the payment statuses manually by rest calls? Or are there any other configs that I need to send while triggering the very first payment request?
You'll need to setup Instant Payment Notification (IPN) to handle that sort of thing.
IPN will automatically POST data about all transactions that hit your PayPal account to a URL you specify. This URL (a script) can receive the data and update your database, generate email notifications, or anything else you might want to automate based on the transactions.
You can handle all sorts of things with IPN. For chargebacks specifically, you would receive an IPN with the following params...
txn_type=new_case
case_type=chargeback
Of course, you'll get a bunch more parameters, too, but those would be how you can pick out the chargebacks and processing them accordingly.
Let's assume the PayPal REST API is used to fulfill a standard PayPal payment process. When executing the payment it is returned as 'pending', so the payment is not through, yet. The REST APi provides a payment id:
https://developer.paypal.com/docs/api/#execute-an-approved-paypal-payment
When payment is completed the URL of my IPN listener is called, however as said on this site included only a txn_id which seems to be not the same as the payment id of the REST API:
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/#id08CKFJ00JYK
So how to match these two ids?
IPN was designed for supporting the classic APIs on PayPal and the txn_id would have matched the txn_id of a payment made with the classic API.
For payments made via the REST API, you may still be notified via IPN but unfortunately cannot match payments using ids currently. Your best option right now would be to check the attributes of the payment (amount, currency etc) and check that it matches attributes of a payment you were expecting.
Currently this is the existing option for push based notifications. The other option may be to poll at regular intervals and check the status of the payment.
There are certainly limitations to both approaches, and there is webhook support upcoming which would have push based notification support for REST payments to alleviate these issues.
The txn_id of IPN messages are also included with the REST API message but called 'sale id' there.
As recommended by PayPal I am using a combination of the PayPal API and the IPN to create a 'Adaptive Payments' flow.
When my IPN listener receives a new notification from PayPal I have two options (after security checks):
1) Use the received data to make direct actions in my website (for example set a preapproval as approved)
or instead a more secure and clean way (I think):
2) Detect the transaction type variable (or other identifier) and request more details from PayPal accordingly.
For example if the 'transaction_type' is 'Adaptive Payment Preapproval' then I will use the received 'preapproval_key' to request the preapproval details using the PreapprovalDetails API call and then use the received data of that call to set the preapproval as approved.
Is this (option 2) the better way to go?
Thanks.
In general there is probably enough information in the IPN for you to act on, but IPNs are pretty confusing what with all the optional fields and the way that there is no payment_status or txn_id on subscribe events, and no subscription information on payment events, so marrying them up can be interesting. You may well find it easier to understand if you go ahead and get the relevant information from them for each IPN via their API as you suggest.