FYI, I just implemented Stripe, but I did it on my own backend, which is where you will have to do yours. It won’t have anything to do with your front end (Dropsource) code, other than the UI you create to pass the payment data to your server. My payments are processing seamlessly
This is an approach I have never considered. Keep in mind that we do not store user payment information and our backend is SSL encrypted. By handling payment on our backend, which is were I tokenize the data, we have more granular control over things like, storing user payment info if they give us permission, and encrypting that stored field. We also still remain out of scope because Stripe ultimately handles this payment request. But no objections to your route at all. It’s like using a JQuery CDN so you don’t have to maintain local libraries, which is what you have to do having libraries directly on your server. Thanks for sharing!
You can tokenize data directly from an api call to strip client-side.
And you can also get all the user payment info (e.g. last 4 digits of card) that you want to store in your backend after the charge.
Even with the approach I proposed stripe discourages that but at least it will help you when you’re applying for your PCI compliance. With your approach where you send data to your backend its going to complicate your PCI compliance approval.
This part of what stripe says.
We strongly discourage passing card information directly to Stripe’s API as it means your integration is directly handling card information. Even if you do not store any payment information, we can only help simplify PCI compliance if you’ve integrated with Checkout, Elements, or our mobile SDKs.
If you continue to send card details directly to our API, you’ll be required to upload your SAQ D annually to prove your business is PCI compliant. SAQ D is the most onerous of all the SAQs, with over 40 pages of requirements you must implement to remain PCI compliant. We highly recommend you migrate to client-side tokenization of card information to substantially reduce the scope of your PCI compliance.
In addition to the significant PCI burden that this method places on you, it is not supported by Radar, our fraud prevention toolset. Radar’s functionality (e.g., risk evaluation, rules, etc.) is only available when using any of our methods of client-size tokenization.
If you’re processing more than 6 million transactions per year, you are not eligible to use a SAQ to prove PCI compliance. Payment brands require you to complete a Report on Compliance (RoC) to validate your PCI compliance annually.
Currently unless you use a webview (which has its own challenges) or implement stripe in code after downloading your source code whatever integration you do natively in dropsource by creating your own form elements won’t be covered by stripe PCI compliance.
Dropsource will have to implement stripe plugin for you to be covered under stripe’s PCI compliance.