Afternoon
I am a bit of a PayPal integration newbie and having been working on a project where customers use a subscription button to purchase goods. Everything works well however I need to retrieve subscription data after approval for further use. Initially I need the email address so we can send a customised automated email thanking the customer for their purchase but going forward would like the majority of the data so it can be placed in an SQL database.
The onApprove: function(data, actions) seems to be the place to enter code but not overly sure where to start. The subscriptionID seems to be pulled and used within the default code, but when I try and pull another piece of data nothing happens.
onApprove: function(data, actions) { //alert('You have successfully created subscription ' + data.subscriptionID); alert('Here is the email address ' + data.subscriber.email_address); }
Is my reference to the email address wrong or does paypal only give you access to the subscriptionID which can then be passed to another PHP page and I can use do a REST API request for the subscription data??
Many thanks chris
console.log(data) in the onApprove will show you the data that is available on the client side.
To log information to a server, you should not depend on approval notifications from the client, since they may fail for any number of reasons. Instead, (using the correct clientid) subscribe to webhooks related to subscriptions, particularly the PAYMENT.SALE.COMPLETED event so you receive an update every time a subscription is successfully renewed.
For reconciliation (so you know what payment is for what), you can pass your own arbitrary custom_id when the subscription is first created. This will be returned in the webhook.
Related
I need integrate paypal subscriptions to my project.
I use new paypal subscriptions api https://developer.paypal.com/docs/api/subscriptions/v1/#subscriptions and need to know how i can identify payer and my own db user.
Here is scenario in my mind:
I create my own db user with signup form.
I set my own user id to paypal api call
After user confirm subscription paypal return me subscriptions id, then i call paypal api to get details of returned subscription and see my own db user id
But looks like paypal cant provide it.
here is my smart checkout button code
paypal.Buttons({
style: {
layout: 'horizontal',
size: 'small',
color: 'blue',
label: 'pay',
height: 55,
tagline: 'false'
},
createSubscription: function(data, actions) {
return actions.subscription.create({
'plan_id': 'P-5GS67390M7258253CLUHXAHQ',
'metadata' : {
'user_id' : 'myuserid'
}
});
},
onApprove: function(data, actions) {
console.log(data);
alert('You have successfully created subscription ' + data.subscriptionID);
}
}).render('#paypal-button-container');
</script>
I found only one way how i can do it
User insert all data to signup form and then click on paypal button
After success paypal payment on
onApprove: function(data, actions) {
$('#myform').append('<input name="subscriptions_id" value="data.subscriptionID"')
$('#myform').submit()
alert('You have successfully created subscription ' + data.subscriptionID);
}
What is the best way to add subscriptions id for mysql db user?
The solution in the question is one possible way. The problem with it is that if the client goes down before sending the data to the server, the association between user_id and subscription_id is lost.
The way around it is to send the user_id to paypal as custom_id. That custom_id is then a part of the subscription data, retained on the payapl server, shown in the paypal billing UI for the subscriptiion details. I do not yet know it for sure, but strongly suspect it is also sent to the webhook.
see PayPal API documentation for creating a subscription
So ideally combine both. Have a webhook to associate the custom_id (your user_id) with the subscription. Have the API call (form post) like you do. If either way fails, you have the fallback.
UPDATE 2021-09-02: I myself use that approach in our web billing solution. One thing I noticed, statistically, it is a very rare event that the web client goes down before getting a response back. I know it because webhook calls come from hours to days after the event. After several hundreds of subscriptions that I analyzed, I have seen not a single case where the webhook came to patch up a missing transaction.
I do not know why it is so. It certainly exceeded my expectations.
My guesses are 1. PayPal server replies fast 2. my PWA is written well enough to warn user to wait a bit not close the browser window until the confirmation screen.
Still I recommend to implement webhook. It would be needed for all the other cases where user cancels subscription directly on the paypal, or such other events.
The solution in the question is correct, the subscription-id should be stored and associated with the internal user-id at creation time, which for subscriptions occurs right after approval (in the onApprove function)
The fetch API can be used instead of a form post to communicate this subscription-id to the server, along with the user-id to associate it with -- similar to the examples in https://developer.paypal.com/demo/checkout/#/pattern/server
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.
I'm currently trying to implement a mechanism whereby i can return a customer to a success page containing an activated PIN allowing access to a piece of software. The process is a straight forward PIN purchase without any kind of user accounts or login system involved.
I have the payment buttons and IPN script in place and working fine, but this only allows me to email the PIN after a successful payment via the IPN script, since of course the two sessions are completely separate to maintain security.
My problem with this is that i can't be sure the customer has access to the same email they used to pay with via Paypal. I had the idea of asking the user to enter which email they would like the PIN sent to prior to the Paypal redirection and then sending it as a custom value.. but then came visions of a mammoth backlog of support emails where users have entered the wrong email. I would really like to be able to redirect to a success page containing the PIN.
Thanks in advance.
I would recommend using the Express Checkout API. The payer experience is very similar to standard payment buttons, however, the user is always guaranteed to return back to your site, so you can display whatever you want on your final page.
That documentation can be a little scary, but it's really just a matter of utilizing 3 API calls.
SetExpressCheckout - This is used to setup a new transaction and will return a token that you'll append to the end of a redirect URL to PayPal. The user is sent to PayPal, they login and agree to pay, and are then sent back the ReturnURL that you specify in this request.
GetExpressCheckoutDetails - Now back on your site/application, you use this API to obtain information about the buyer like their shipping address, address status, payer status, payer ID, etc. You will need the Payer ID for the final API call.
DoExpressCheckoutPayment - This is very similar to the SetExpressCheckout request, but no transaction is completed until this call is completed. Only then does the money move.
Again, those final calls are done on your site so you can use the API response data to update your database and display details on the final page however you want to.
Keep in mind that payments could still be pending for one reason or another, so you'll want to check the status (returned in the DECP response) and display appropriate information on the final page.
IPN's will still be triggered with Express Checkout so you can adjust the IPN script to handle pending payments or anything else you may want to automate outside the checkout flow.
If you happen to be working with PHP my class library for PayPal will make these calls very quick and easy for you.
Current Status
I'm quite new to PayPal and I'm currently integrating chained adaptive payments on our website. Already successfully called the PAY API call via the .NET SDK. Money (sandbox enviroment) will be correctly transferred to each participants of this payment (sender, primary and secondary receiver).
Requirement
My goal is to execute vital tasks after the payment is successful (update DB, send mail, ...) or has been cancelled (clean up stuff, ...).
Possible solutions
1)
First approach was to create the payment with actionType set to CREATE, redirect the user to paypal.com (wait for approval), redirect user back to website and execute the payment and then perform the vital tasks. But it seems not to work, the payment will be paid and is COMPLETED before the second redirect.
2)
Another possible solution would be to get the preapproval from the user, redirect back to the website and execute the payment. Haven't tried this solution yet, don't think that this is best practice.
3)
Call PAY with actionType set to "PAY" and wait for IPN. Haven't tried that either, because it is quite difficult to test it locally (even though I've already found this question: Paypal Sandbox Test Tool IPN Simulator in Localhost).
Question(s)
Which solution is best practice? I guess the recommended solution would be to wait for an IPN?
If I'am using IPN how long is the average response time after a payment has been completed? Seconds, minutes, hours? I know it depends on the load of the PayPal webservers and that there are 15 retries over 4 days, but what are some real world numbers?
Can I store additional information (e.g. UserId) about the sender in a payment (besides the memo field) which I then get back in an IPN?
Here is how I do it.
When I'm going to initiate PayPal payment (before I send a request to obtain TOKEN), I create new transaction in my database and set it's status to PENDING. In transaction table I also have userID column, which is foreign key to user table. This way I connect transaction with user.
When transaction is created in my table, I use transactionId value, and save it to PHP $_SESSION variable.
Please note that if you want to support recurring payments, you can provide transactionId to PayPal. This you can do by setting:
"PAYMENTREQUEST_0_INVNUM"=>$transaction->id.
This value will be sent when PayPal sends you IPN request after recurring payment happens.
Go back now to the story
User is redirected to PayPal, and when user fills PayPal username and password, and when user confirms payment details, user will be redirected back to your website and you have to call DoExpressCheckoutPayment to make payment itself.
If the result of DoExpressCheckoutPayment API call is success, that means that transaction was successful and you have money. At this point, you can send email, notifications, or any other important action.
$transactionResponse=$paypal->request("DoExpressCheckoutPayment",$requestParams);//Execute transaction
if(is_array($transactionResponse) && $transactionResponse["ACK"]=="Success")//Payment was successfull
{
//Send email
//Notify user
//Do other important changes in database, for example mark this transaction as successful
Transactions()::model()->updateByPk($_SESSION['transactionId'],array('status'=>'SUCCESS');
}
IMPORTANT NOTE FOR RECURRING PAYMENTS: PayPal can/will send you several IPN requests for the same recurring transaction which means that you have to add logic which will chekc weather specific IPN request is already processed or not. Usually I do it in a way to check weather status of my transaction with transactionId is 'PENDING' or 'SUCCESSFUL'.
I've got a web application with a form where users can sign up for a seminar. The process is currently as follows:
Register for seminar
Registration success page with Paypal Buy-Now button to make payment
Paypal payment
Registration completion page
At present, emails are sent to the admin and the user at step 2 after registering confirming their registration. This needs to be changed so that the emails are actually sent in step 4, after payment has been made.
The application is built in ASP.NET, and all of the code to send emails, etc is all done. I'm curious as to what is the best way to trigger a process on the main website using the users details after they have completed the Paypal payment process.
From what I can see, there are the following options:
Store the data in the session. When the user returns to the registration completion page, retrieve the information and send the emails. My concern with this is that I've worked on a project in the past implementing this and it never worked very well, with the session getting lost.
Store the data in the database. Have the Paypal redirect include the transaction details in the querystring to the return page, which can retrieve the registration details using the email address and send the emails. However, this may not work if the email address used on Paypal is different from the one used to register (which is quite likely in this scenario).
Post all the details to Paypal, so that they are included in the transaction. Downsides: Won't send confirmation email to the user, only the admin (and assuming that the Paypal email address is the same as the email to which payment notifications should be sent). Also not sure if this can be used with hosted buttons.
I'm sure this is a common problem, and any advice would be appreciated. Thanks.
Use paypal instant payment notification
When the order is placed on your site, put it into a db table, with whatever you need to record. I then have an OrderId (from the db table) that I pass to paypal as an 'invoice' field, this gets passed back via ipn with a payment status etc.