I suppose anyone could do this to take advantage of silly users, but this is encouraging users to trust 3rd party websites by design.
Seems wide open for phishing.
If someone malicious gets my credit card info, I have a lot of ways to defend myself. Someone malicious getting my PayPal login info could be much, much more dangerous, and I'd have considerably less protection. Essentially we're talking about leaking login info here -- that's very different than credit card info.
It appears that the PayPal is a header, rather than a button, it has no call to action. Separating the credit card form from the button and giving it a clear header (Like: "Pay With Credit Card") would help indicate the choice of PayPal or Credit Card.
Also, I'm not sure if it's intentional, but the credit card form doesn't actually do anything. Completing the form with a test credit card gives no follow-up call to action. This could be confusing to people wanting to see a "working" integration.
On native mobile we,ve taken the approach to render the call to action for you and allow you to configure the text. Is that something you would find useful on web as well? It's definitely something we've debated internally.
They'll "drop" you, and suddenly your "drop in" SDK is completely worthless and you're forced to write your billing system from the ground up.
From a risk perspective, using a solution like Chargebee, that integrates with multiple merchant accounts (including Braintree), is a much better choice. If for whatever reason your merchant drops you (it does happen!), you don't need to make any code changes. You only need to swap out the backend merchant account in your Chargee dashboard.
These "batteries included" payment solutions are nice for getting up and running quickly, but if you have any semblance of long term planning, it's a bad idea to build your entire billing infrastructure around the API of a single merchant account provider.
