What's a recommended or reliable way to programmatically test a PayPal payment flow that uses the PayPal Smart Payment Button? window.paypal.Buttons() is loaded from https://www.paypal.com/sdk/js .
Tests are running against PayPal Sandbox.
I tried to end-to-end test the flow in node.js with jest via puppeteer but am not sure this is a good way to test this, considering that the intervals of PayPal may be subject to change.
Furthermore, when trying to automatically log in via puppeteer, PayPal sometimes seems to show the account homepage with the funds.
However, it's supposed to show the payment methods selection view instead after login, with no errors, which could be some bot protection mechanism kicking in or some other non-deterministic smart behavior, rendering the test to unable to proceed.
Operating my UI manually, I did not observe this behavior.
Related
I’m developing a delivery application that will work with PayPal for payments. Ionic/Cordova has a native library that makes things easy, yet the flow is not the way i’d like it to be.
With “PayPal-Cordova-Plugin”, the authentication window opens for every payment and the user must click the button to confirm the payment.
What I would like to implement was something more direct, transparent. The user would authenticate with PayPal within my application and with the probable token that would receive this authentication, I would execute the checkout requests (an example would be the payment by PayPal on Uber).
With the PayPal developer documentation I could not find a way to perform this implementation on Ionic, so I would like help with that.
The old PayPal Mobile SDKs used by the cordova plugin are ancient. Do not use those. Do not use those for anything. If you try to use those, you are going to have a bad time.
The first paragraph at the top of the Readme of https://github.com/paypal/PayPal-Cordova-Plugin points you to the things you should be using instead.
As is mentioned there, PayPal Express Checkout via the Braintree Mobile SDK is a worldwide option for those who need a native SDK. It is documented here: https://developer.paypal.com/docs/accept-payments/express-checkout/ec-braintree-sdk/get-started/
You will need a webservice for the server-side portion.
I would like to be able to test our integration with PayPal. We have sandbox accounts set up, etc, and I can even create payments. However, I'd like to be able to also issue refunds, query for refunds, and all the other APIs, all via integration tests and without human or even browser involvement. The difficult part seems to be that, of course, the PayPal flow requires someone to interact with a PayPal URL and approve the purchase.
Some more detail : We use the standard e-commerce flow on our site. User shows up, puts a product in a cart, proceeds to buy flow, selects a payment method, in this case PayPal. Of course, in PayPal's case, we create the Payment in PayPal and then simply show the embedded popup of palpal's flow where the user logs into their PayPal account and approves the purchase. PayPal does all this work. We simply get the response that 'yes, the purchase has been approved'.
So.. in an integration test environment, we can create the Payment entity in PayPal but.. how do we, in a sandbox environment integration test, get that payment approved? Is there a developer API available on the sandbox environment that says 'hey, this PayPal user approves this payment' or 'hey, this PayPal user rejects this payment', so that in test code we can simulate the buyer's flow. Or is there a way to set up a sandbox account to just 'auto approve' purchases or 'auto reject' purchases, simply for a test environment?
Yes, you can do anything in the sandbox that you can do on the live servers. This is a very broad question, though, so it's tough to answer.
For example, if you want to process payments without the need for any browser flow you'll need to have a billing agreement setup or a Pro transaction so you can run reference transactions. This would involve Express Checkout APIs and/or Payments Pro APIs, and reference transactions APIs. Depending on whether you're using Classic or REST, though, the API calls would be different.
In any case, once a transaction exists in the PayPal sandbox system you could then use the API to refund it. Same thing, though...you'd either be using REST APIs or Classic.
If you can provide more specifics in your question I can update this answer to be more specific as well.
I'm in the process of developing a feature to accept payments in my website, and I already did it using a paypal button and IPN (a PHP listener to process data to a DB once the payment is completed, this one actually https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.php, properly customized).
I never touched PayPal API and I wonder if I am missing something... I'm kind of new to this kind of development and I want to be sure I'm doing it right and not missing any obvious thing which might compromise the security of the payment or whatever... I already tested things in Sandbox and everything works as expected, but I am concerned about the API and I see many people using it...
So, am I missing anything?
Thanks!
What you've done is accurate and will work just fine so long as it's suiting your needs.
One potential security risk would be if you are not using a hosted button. Did you choose to "Save this button at PayPal" when you created the button? If so, you should see a hosted_button_id included in the HTML for the button. In this case it's protected.
If the button code includes individual parameters for things like item_name, amount, etc. then that code could be adjusted by people in their browser and then the button could be submitted with different pricing, for example.
You could check for this sort of thing in your IPN script and setup an automatic refund if the price doesn't match your database, but I generally try to avoid that sort of thing.
I prefer using the Express Checkout API instead. If you were comfortable getting IPN working with PHP then you should be plenty comfortable using this PayPal PHP SDK to integrate Express Checkout.
The three calls you'll need to work with are SetExpressCheckout, GetExpressCheckoutDetails, and DoExpressCheckoutPayment.
This documentation will cover the general steps and where those calls come into play, and that library will make each of those calls very simple for you.
Express Checkout will eliminate any potential adjustments users could make to code (because they won't be able get to the code at all unlike HTML) and it also has more advanced features and options that PayPal Standard does not have. Most importantly, the ability to force the "guest checkout" experience so that non-PayPal account holders can easily checkout using a credit card without any confusion.
They can do it with PayPal Standard, too, but depending on cookies set in their browser it may make the guest checkout option tough to find. Express Checkout makes it very prominent at all times, and generally results in increased checkout conversion rates.
PayPal has explicitly stated that their IPN service should not be relied on during the user checkout process. I believe the idea here is that IPN should be a tracking mechanism to keep our back end data in sync with PayPal's data. What I want to do is to use express checkout but enforce an "IPN" to hit my server, and for my server to appropriately respond, before anything is finalized.
I can then ensure that I only give out content to users once they've paid, and that if a user does pay for a piece of content they do not have to refresh or wait for the IPN to come in. One of the problems with doing this using a return url and query string, is that i have a single page website on the firefox phone. The phone gets data from our API web service. So i need this endpoint to be hit regardless of the return url.
I know there are some more features with PayPal advanced developer, at a fee. I'm fine with that if that's the case, but i just want to know my options first.
As the name implies, IPN is instant. There are rare occasions where it may be slightly delayed, but that doesn't happen often, especially on the live servers.
You can build your IPN listener to do whatever you need as far as updating a database, generating custom email notifications, hitting 3rd party web services, etc. and those actions will be triggered in real-time.
You just need to get your listener created and configured in the PayPal IPN settings, or you can also pass the IPN URL in the NotifyURL parameter of your Express Checkout API calls.
If you happen to be using WordPress you may be interested in my PayPal IPN for WordPress plugin. It gets you up-and-running with IPN very quickly, and then you can hook into the plugin to trigger your own functions based on different IPN types or payment statuses.
Extra Info from Comments
As mentioned, IPN is a post-transaction thing. What you could do, though, is setup Auth and Capture on your checkout system. When the order comes through you would run it as an Authorization, and when you're ready to "finalize" you would run the capture.
You would get an IPN for both the authorization and the capture. So, one thing you could do, if it suits you, would be to run the order as an Authorization, and then within your IPN script, go ahead and run the capture. That way you could do whatever checks you want to do and only capture if they pass.
In passing cases, the capture would take place "almost" instantly when the order takes place. Cases where it doesn't pass, you could either void the Auth or let it sit there in a pending state.
I have created response for recurring payments using ipnsimulator. ipnsimulator send transaction details without subscr_id. How can I get subscr_id for recurring payments using ipnsimulator?
Unfortunately, the IPN Simulator is not yet setup to include subscriptions or recurring payments. You'll need to find a sample of what IPN's look like for a given transaction (which you can find with Google, of course) and then you can create your own simulator. Samples are provided at http://developer.paypal.com in the docs, but they're kind of buried so Google really is faster.
You can build your own simulator by creating a basic HTML form with the action set to your IPN URL. Include hidden fields in the form with names/values that you would expect to get from an actual PayPal IPN based on samples you find. Then you can load this in a browser and submit it manually to trigger the simulated IPN. This can help with troubleshooting script problems, too, because you can see the result on screen.
Keep in mind that when testing this way the IPN data is not coming from PayPal's server. Therefore, the verification will come back as INVALID. Just make sure you remember that if you're building logic around VERIFIED or INVALID IPN results, and adjust accordingly.