On my site, I have multiple billing plans, for example:
1$ = 5 points
2$ = 15 points
3$ = 30 points
When user chooses paypal option, I want him to be redirected to the paypal checkout page,
and on completion of transaction, I want to receive notification so I can grand the account
with points. I understand that can't be done with Pay Now button. Also, I can't understand what is the most right way to do so. Suggestion?
when i talk about paypal checkout page I mean this one
I would just create a drop down menu option to allow the buyer to select which one they are wanting to purchase. Then that will popluate the PayPal checkout page with the correct options selected, and amount. As for getting the information back to your site. I would use IPN.
Instant Payment Notification (IPN) is a message service that notifies you of events related to PayPal transactions. You can use it to automate back-office and administrative functions, such as fulfilling orders, tracking customers, and providing status and other information related to a transaction.
Checkout this page here for more on IPN. There are also some samples of IPN scripts, and additional links relating to IPN on the left hand side of that page.
Related
I'm looking for direction on documentation or others who have sites with the same scenario:
step a: Select Payment - The user can selecting Paypal in checkout
step b: Review Order details - The user has selected paypal in step 2
and can review the order detail before placing the order with PayPal.
Questions:
Can step a just be a selection of the paypal payment method not leading to paypal sign in?
Or does step a have to be a sign into paypal
Once Signed into paypal, does the paypal api allow the user back to the site to allow to review (step b)?
Does initiating Paypal have to end with the placement of the order? i.e. it can not return to the step b to review , then complete the order?
"Selecting" PayPal without signing in doesn't do anything, and accomplishes nothing. You should have a PayPal checkout/sign-in shortcut button as early as possible in your flow (ideally on a "view cart" page), in addition to the normal payment selection location. This allows payers to sign in quickly without having to type in any address information, which speeds the process. PayPal payers almost always already have their address saved at PayPal. The less friction there is in the process, the more likely a payer is to actually click through and complete the checkout. This increases sales measurably.
If you need a review step after PayPal before capturing, then you can show one after approval (in the 'onApprove' function) before doing the capture. If you are not going to be capturing immediately, the button text of the last action at PayPal should be changed from the default 'Pay Now' to say 'Continue'. To do so, when creating the order set a top level (not inside purchase units) application_context object with a user_action key of CONTINUE. This only changes the text of the button, it is up to you to make the behavior after approval match (and it must match).
To change the details of the PayPal order before capture, use an Update Order Details API call, which is an HTTP patch operation (not post) that gives no success response other than a 204 code.
For payer approval, use this flow; it has the necessary client-side error handling of a v2/checkout/orders capture response (restarting in case of a recoverable funding failure)
At the beginning of last week I was able to process two orders and was unaware of any other possible orders. These two orders were correctly received, processed and shipped.
I have received no further processed payments since these two. However multiple customers have told me that they had tried to purchase and were either UNABLE to log into their paypayl account through my payment buttons, OR thought their orders were received after using the "pay with debit" option on the button through my website.
Those who used the "pay with debit" were actually shown a "thank you for your purchase" message afterwards.
Questions:
Are my buttons broken?
Can I see how many people attempted to use the buttons?
Is there any way to contact those who entered their payment information to inform them that their payments were not received?
website pages with buttons:
https://www.fungetarian.com/oyster-mushroom-grow-kit
https://www.fungetarian.com/lions-mane-mushroom-grow-kit
Those appear to be normal hosted PayPal "Add to Cart" buttons, although there is an extra step of having to click a "Buy Now" button on the website to make them appear.
When a payment is made with such a button, it's very clear. Notifications are sent by email with a transaction ID, and there is a transaction record in both PayPal accounts (or the receiving account alone, of the sender didn't use one).
There shouldn't be any confusion here, either payments were made or they weren't.
No you cannot see whether someone "attempted" to make a payment.
I am using a PayPal button that redirects to a checkout/payment confirmation page that has payment info, payment methods, etc.
However, it is not obvious if the payment is one time or recurring.
The user could click on the amount and see more details, but I was wondering if I could show the subscription info by default to avoid confusion.
The subscription info is also presented after the payment has been processed in the receipt which is informative, but not ideal.
Here is the amount:
here is the amount after click/expansion:
PayPal's checkout is designed to be equally usable from a mobile device or small/pop-up minibrowser, so the space on the right in your screenshot isn't available cross-platform.
The details of what is being paid for are meant to be shown by your own site before, on the page and in the receipt after, and are also available via the drop-down as shown in your screenshot.
You can't expand it by default.
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.
I'm having some trouble choosing between PayPal's Instant Payment Notification (IPN) and Payment Data Transfer (PDT).
Basically, users buy a one-off product on my site, pay on PayPal, and return to my site. I understand how IPN works but I'm now seeing that I might be able to trigger the various actions that take place after a successful purchase more easily with PDT, as the data gets returned there and then (as opposed to needing a separate listener).
However, PayPal's PDT documentation contains this cryptic line: "PDT is not meant to be used with credit card or Express Checkout transactions." ... but I can't find anything further whatsoever on the topic.
Are credit cards REALLY not meant to be used with PDT? I would like more than a sentence.
Does that mean that a user must have/create a PayPal account to pay?
Does it mean that if I want to allow users to pay with their PayPal accounts AND/OR with credit cards directly, I must implement IPN?
Could anyone who's gone through this kindly shed some light?
The APIs for PDT and IPN are similar. The main difference is when you receive the notification. For that reason I would recommend implementing both.
With PDT you get the notification instantly and can do any additional processing required and show the user a confirmation page.
With IPN you are guaranteed to be notified that the payment was received even if the user's computer explodes before it can send you the PDT.
Implement both and get the best of both worlds. But if you're only doing one, IPN is the reliable one.
One catch: if you implement both then there's a chance your payments could be processed twice. Take care to ensure that doesn't happen. The application I wrote handles the PDT and IPN almost identically (the backend part is the same) and that code acquires a per-web-user lock in the database, so that if the same user tries to submit the exact same payment multiple times it can only be processed once. Once processed the result of that process is re-used for any subsequent attempts to process it.
Edit
One more thing: IPN carries more information than PDT. There are lots of different messages that you can receive from IPN, such as chargeback notification, etc, and thus you really should implement it.
PayPal's PDT system sends order confirmations to merchant sites that use PayPal Payments Standard and lets them authenticate this information. Such sites can then display this data locally in an "order confirmation" page.
When to Use PDT?
IPN provides the same capabilities described above. So, when should you choose PDT instead of IPN?
With PDT, your site is notified immediately when a customer completes payment. With IPN, however, there is a material lag between the time a customer completes payment and the time your site receives notification of this event.
So, use PDT if your site includes a feature that requires immediate payment notification.
For example, consider a digital music store. With PDT, this store can let customers download their purchases right away since PDT sends order confirmations immediately. With IPN, such immediate order fulfillment is not possible.
Advantages of IPN
PDT has a a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually guaranteed since IPN resends a confirmation until your site acknowledges receipt. For this reason, PayPal recommends that you implement IPN rather than PDT.
Another advantage of IPN is that it sends many types of notifications, while PDT sends just order confirmations. So, using IPN, your site can receive, for example, chargeback notifications as well as order confirmations.
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT. However, if you do, your site will receive two order confirmations for each sale. As a result, you must be careful to take action (say, ship a product) on just one copy of a given confirmation message.
Documentation Here
Re 1. PDT is meant to use with Auto Return for Website Payments feature. Auto Return redirects to PDT site after paying money to seller. Unfortunately it's not possible to use that feature along with PayPal Account Optional - used to enable Credit Card payment. Here is note from PayPal: 'If you have turned on Auto Return and have chosen to turn on PayPal Account Optional for new users, a new user will not be automatically directed back to your website, but will be given the option to return.'. User will have an option to go back to your site(PDT step) or stay on PayPal site. To sum it up when paying by Credit Card user can skip PDT step if user will not click 'return to store link'.
Re 2. It is up to you what paying options do you want to allow. If you want to allow paying without a PayPal Account you can enable Account Optional. If you want to allow only users with PayPal accounts disable that feature. There might be more options.
Re 3. In your case you need to trigger action after successful purchase. Recommended way would be to implement IPN. PDT doesn't work for all cases and doesn't guarantee message delivery. Here is link to doc covering that topic PDT vs IPN.
This is an old question, but my simple answer would be - Why not use both PDT and IPN? They will work fine for card transactions.
PDT can provide the immediate transaction status to your website, where you can quickly check the payment success or failure status and provide the user with appropriate message.
Meanwhile, you can await the full verification from IPN in the background. Once received, you can use this to further update your DB and process the order.
You can follow this step-by-step guide which I found to be very clear and helpful - and it's still valid in 2018.
https://www.codexworld.com/paypal-standard-payment-gateway-integration-php/