ihadeed
commented
2 years ago tl;dr: Web is convenient and secure by default, uses built-in UI components and very basic logic, requires internet to load client-side logic. While native libraries give you fine control over UX/UI, more functionality, and don't require internet until you send data to Stripe.
My information might be outdated, but here are some features & limitations of both options to think about:
Stripe JS (Web)
Convenient when network stability isn't an issue
Stripe JS library offers a convenient and secure way to collect sensitive payment information from your customers without doing much work. It requires loading a JS script in run-time from their servers.
When using a <script> tag to load Stripe, it's possible that the app might:
- take longer to load
- not be usable for the user until everything is loaded
- not work as expected if it the script failed to load, a complete app restart is required
The above scenarios are usually not relevant when dealing with web apps, since you need internet access to load the app in the first place.
Limited functionality that's secure by default
The web library doesn't give you fine control over how to collect information and process them. Stripe removed most direct API calls in the latest versions, and are encouraging the use of their Stripe Elements UI components.
Stripe Elements UI components are displayed inside an isolated Iframe which is hosted on their servers, making it more challenging
Native mobile libraries
Compiled logic
This plugin is a wrapper for the native Android and iOS Stripe SDKs which have all the logic built in and don't require internet connectivity until they perform an action (they send HTTPS requests to Stripe API). This comes in handy for mobile applications since you can't always guarantee a network connection, and the <script> tag that's used in web applications doesn't handle network outages by default.
With the compiled logic you only need internet connectivity when making requests, and therefore be able to handle network related errors in smaller chunks with ability to retry without restarting the app.
Fine control
Mobile libraries provide high level API calls which gives you the freedom to collect information in any way you want. You get to design the interface from scratch, and connect it with a logic controller that relays that info via API calls (or Capacitor plugin functions).
The libraries also come with UI components and views, but they're more challenging to expose via this wrapper. However, with Capacitor you have the ability to utilize those native views directly without going through this plugin.
More Power = More Responsibility
Designing your own views and UI components makes it your responsibility to ensure the security of them. It's up to you to ensure that sensitive user information doesn't leak anywhere, and isn't stored in the app or on your servers.
rdlabo
I use Stripe in my web app, which is not using Capacitor yet. Why would I need this wrapper once I add Capacitor?