I dont get the idea. If Classic api have DoExpressCheckout methods... what Rest API have for it?
On that image we have the way how it should work for classic way
So for my case Express Checkout steps are:
1) Customer put items in cart and click on PayPal checkout button
I run
var payment = new PayPal.Api.Payment();
var createdPayment = payment.Create(apiContext);
so make the payment and redirect customer to paypal site
2) Customer go thu the paypal process and return back to my site. From his pay pal transaction I should get Shipment address and his email (without submit that payment!) and based on his shipment address calculate shipment cost
3) After customer select shipment method I need update his transaction (add shipment cost) and only then sumbit it.
So the questions here
1) how to get payment (transaction) info with C# lib based on paymentId (like PAY-21A17783AU475540MKYGAM5Q) because PayPal.Api.Payment() have methods only Creare, Execute and Update?
2) How to Update current transaction (add some new data like shipment cost) and then submit it?
PS. In the documents a lot of mess and a lot of people dont understand how they should use that api properly.
Duke
Based on your post, you'd create an Order - strongly suggest you use their library in this link (it includes samples, should get you going quickly, is very well maintained, and the maintainers are great/responsive)
Create it - this would map to classic SetExpressCheckout
Redirect to Paypal to obtain user approval. The redirect URL is part of the response (no longer just a token)
if the user "approves", Paypal redirects back just like in classic
you'll see this handled in the sample in the else block
just like in classic PayerID is in the querystring
Execute the payment
the response will contain the data you need as you will see in the lines below the execute statement, so this maps to GetExpressCheckoutDetails
you will also see your options on what to do next (Auth, Capture, etc.) in the commented lines. These would map to "finalizing" the payment
you can "adjust" for shipping/tax in the above after obtaining the details and will have same rules as classic IINM as far as the maximum additional amount you can add - 115% not to exceed $75)
If you have a sandbox account, I have a debug page here that shows the data io that maybe helpful.
Note that I'm only partially capturing ("is_final_capture": false) so if you check your sandbox (buyer) account, the total charged wouldn't be the full amount
Hth..
Related
I'm trying to implement the new PayPal Orders API, here is what I did:
Create a developer account, add an app name and then I have Client Id and Secret.
Use OrderCreateRequest to create an Order
Get approvel_url from the resposne->result->links
Redirect to this approvel_url and finish the payment
Paypal will redirect back to my website.
But I never got any thing from the PayPal testing account,Please, what did I miss?
Edit:
On No.4, when redirects to the PayPal page, somehow it only shows 'Continue' button on the page, not the 'make payment' button.
You are missing:
Display an order review page to the payer.
Capture the order with an API call, which (if successful) will return the transaction ID in the purchase_units[0].payments.captures[0] object.
On success, display a thank you/confirmation page.
Without the final capture API call, there is no PayPal transaction.
You are also still using an old integration method based on redirects, which is for old websites. Current PayPal Checkout integrations use no redirects. At all.
Instead of redirecting, make two routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. These routes should return only JSON data (no HTML or text). When a capture response is successful, store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, the PayPal transaction ID) and perform any necessary business logic (such as sending confirmation emails or reserving product) right before sending your return JSON.
Pair those two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
I am working on a software service and am offering a monthly subscription for my software service.
I am currently working on the subscription part - and am wanting to implement a paypal monthly recurring payment solution.
I have spent quite a bit of time looking over PayPal documentation, and trying different buttons, webhooks, IPN methods etc.
The problem is that I am not sure what solution to use - because I am confused by the multiple options.
What is most important to me is - that when the customers fill out the form on my website - and are then directed PayPal to pay - I then want to know that specific Customer ID from my website has successfully paid.
I would like to know:
Which SPECIFIC option(s) PayPal has that I can pass Customer ID from my website of that customer - let's say a subscription ID from my site - and that PayPal will then send the customer back with my subscription ID, that I passed them on to PayPal with.
Which is the easiest option to do that with?
I simply want the customer to:
sign up at my site. (my part)
be issued a unique Customer ID from my website (my part)
click a PayPal payment/subscribe button (my part)
be sent to PayPal to pay for the subscription (paypal's part)
be returned to my site with the unique Customer ID from my website from my site - as well as a confirmation of payment from PayPal (paypal's part)
Please do not simply pass me to the general area of the development sections -
As I said - I have already been through all of that and find there is too much information.
Please direct me to a specific solution, or example, or tutorial that covers a solution that will fit what I need.
I would recommend using the Express Checkout API with Recurring Payments.
The best thing to do would be to create a local invoice record in your system, and then have a related customer ID associated with that invoice.
In the CreateRecurringPaymentsProfile request to PayPal you can include a PROFILEREFERENCE parameter, which would be the invoice ID you generated for that order in your system. Then all future payments related to that profile would include this same reference ID as part of its data, so if you're using IPN, for example, it would be included there.
When working with Express Checkout the user is always guaranteed to end up back on your site to finish the checkout flow, so you can simply save data in sessions during checkout and update things like your database, email receipts, etc. directly in your payment flow. Then you could use IPN to process the recurring payments after that, and again, it would include that same reference ID. In IPN this would come back as rp_invoice_id.
I get it that Paypal SDK (backed by REST API) has three steps:
Create a payment
payment = Payment({...})
payment.create()
return redirect( redirect_url( payment))
The customer pays and authorizes payment from within Paypal
Redirect to our site where we execute payment, thus transferring money
Should I store the created payments at step 1? I would thus capture all payment attempts, whether successful or not. Or can I create a payment, and not remember it until step 3? That is, record only the successful payments (within their respective Invoices). Is there any reliability or security issue or other harm if I do not store it at step 1?
I suspect not being able to roll back failures.
In Paypal terms, they are of sale intent and are meant for payment of invoices for services rendered. Card data do not touch our servers, I am deferring to Paypal on handling it.
I use paypalrestsdk, Paypal's Python SDK.
Previously, it was tricky to get the PaymentId back when PayPal redirects the page back to your server to authorize you, as there was no way to get PaymentId on 3rd step
However, now, the PaymentId is returned back as a part of the URL as shown here in 3rd step :
http://localhost/Server-SDK/PayPal-PHP-SDK/sample/payments/ExecutePayment.php?success=true&paymentId=PAY-62998961VU1587338KR3AXWQ&token=EC-4YC2489096181311L&PayerID=REABK2UGK7PLW
As you can see it has paymentId which is the Id that you need to store.
So, to answer you dont need to store anything till 3rd step.
Additional Note:
However, if you have some complicated logic/service you want to provide. E.g. send them an email reminder(if you have their emailId), to remind them if they abandoned your card, etc. However, there are many ways to do that besides using these steps.
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.
This is probably a stupid question, I think I'm having a mental block.
I want to use Paypal's express checkout for buyers to make purchases with as few steps as possible (also using Paypal's optional account feature). The problem is: for me to direct the user to paypal, I will need to have calculated shipping costs, which depends on the country they're in. Obviously I cannot know this unless I have been told one way or another. What are common solutions to this problem?
Ideas:
Use their IP address. Not reliable - various types of proxies, VPNs, anonymizers etc.
Have the user select their country from a drop-down box before I redirect them to paypal
Force them to log in using Paypal's Identity service before calculating postage
Use 1. or 2. and once payment is received, if country is different to expected,
Refund buyer the difference in postage cost or request an additional payment. (Hardly ideal)
Similar to 4., instead of "Sale Payment Action for Express Checkout" Use 1. or 2. in conjunction with one of Paypal's delayed express checkout payment methods and if necessary reduce or increase the amount charged:
Authorization Payment Action for Express Checkout
Order Payment Action for Express Checkout
I'd like to know what solutions other developers have chosen - maybe I've missed an idea. As a consumer, I cannot remember seeing solutions to this.
The general way people do this is simply to use GetExpressCheckoutDetails to obtain the buyer's shipping address, apply any shipping/tax as necessary, and display a final review page on your site that the user would confirm before calling DoExpressCheckoutPayment.
If you want to eliminate the additional review page (PayPal's and then your own) you can use the Instant Update API.
In this case you would include an additional parameter on the URL when you redirect to PayPal (useraction=commit) and this will change the button on the PayPal review page to say Pay instead of Continue.
Also in your SEC request you'll include the CALLBACK parameter and include a URL to your callback listener. PayPal's review page will POST the buyer's shipping address to this callback URL so that you can receive the data, calculate shipping and tax accordingly, and send a response of those options back to the PayPal review page. This will populate the PayPal review page's drop down menu for the shipping option and the user can choose accordingly.
This method allows you to utilize the PayPal review page entirely and finalize the payment there so that the only thing the user sees once they're returned to your site (after you call DECP) is a final thank you / receipt page.