Is It Possible To Integrate Stripe After Download?


Does the exported Dropsource code allow another developer to manually integrate Stripe?

If so, what will happen with future exports of the drop source code?

Obviously, the stripe components will be missing, but will this create any additional issues or concerns other than Stripe not being installed?

Currently exploring options… Would love it if Stripe was able to be installed or if it could be sponsored by some of us here and have Dropsource integrate it @wade


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



What back end are you using?

You are sending the data to your backend first, and then to Stripe?

Or are you sending from Dropsource directly into Stripe?


My backend is a Linux server.

And yes, I’m sending data to my backend first, from the custom UI I built in Dropsource. I then prep that data with my backend code to send to Stripe for processing.


Awesome Collaborations Here! @chris knows more on this part than us currently. Great job all around! Chris, congrats on those sales too!


A friendly advice here.

This is very bad design decision because of data privacy and you’re going to find it extremely hard to be PCI complaint.

Stripe strongly advice against sending sending sensitive information like credit card number to your database.

You should rather call the stripe api directly from dropsource without any user data hitting your backend

@justincrabbe See this video tutorial on how to integrate stripe without sending data to your backend.

Also search for PCI compliance on this forum and you will see some discussions on this.


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.

You can read more here


Definitely going to have to refactor the workflow sooner than later, thanks for the insight.


Have you successfully integrated Stripe into Dropsource and at the same time remained PCI complaint or otherwise within the recommendations of Stripe?


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.


They need to do that, Braintree is a joke!