Process credit card payments with Stripe


Hi guys, if you wondered how to process credit card transactions in Dropsource, we put together a guide with a demo for you. The video below describes the process for importing the Stripe API into Dropsource and processing CC payments without writing any code. Enjoy!


Thanks Mark for another great tutorial.

Nice idea in the credit card formatting and image display.

I have one important question about this process though.
What is the security implication of this process especially with the way you’re collecting credit card information?
Will this approach be PCI compliant?

I noticed (and you also mentioned it) that you’ve created an endpoint POST /services/Stripe/charge/card that does both the tokenization and charging.
Can you please explain how this endpoint works, specifically what data hits the Backendless server?
Is there any point in this whole flow that the sensitive card details will hit the Backendless server even if not saved?

From looking at this video it seems you’re using Stripe REST api directly.
Stripe strongly discourages users from directlying passing payment information to the Stripe API since there is no guarantee that you can’t maliciously send the credit card details to a server.
Therefore when you integrate stripe in this manner you will have to prove PCI Compliance yourself by filling the Self Assessment Questionaire which isn’t an easy task at all after looking through the process.
Below is what Stripe says about integrating directly with their API like you’ve done (if my assumption is correct).

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.

It is for this reasons why you see some people using that webview workaround where they use Stripe’s own secure Checkout element.

Here is a link from Stripe on how to collect card information securely and PCI Compliance.


Regardless of how one uses Stripe, they must validate their PCI compliance. In fact Stripe themselves disclose that in the link you referenced. So regardless whether credit card info is passed via REST API, or Stripe’s mobile SDK or their Checkout form/js, PCI compliance must be demonstrated/declared/documented and the questionnaire must be filled out.

We at Backendless believe in providing choices to our customers. One can use our public cloud or run Backendless in their own infrastructure. The latter is used by major banks, hospitals and public universities where the security is of utmost importance. So in short, yes, we have passed PCI compliance in more than one occasion.

As for how the endpoint works: it takes the information received from the client and passes it to Stripe. There are several approaches here implemented by the API service. If one wants to use the tokenized approach, there is an endpoint which returns a token from Stripe in exchange for the credit card info and subsequently there is another endpoint to process a transaction where you pass the token and the amount. The approach demonstrated in the video is the simplified process where both steps (getting a token and running a transaction) are combined into a single call from the Dropsource client perspective.

Hope this helps.


Hi Mark, thanks for the explanation.

Yes you’re right but depending on the approach used, what one is required to be PCI compliant may differ.
For example if one uses Stripe Checkout or Elements they don’t have to do anything because Stripe automatically generates the PCI validation for them as stated below:

For users that have developed their own integration and are using either Checkout or Stripe.js and Elements to collect card details from customers, you are eligible for the simplest method of PCI validation: SAQ A. Stripe automatically creates a combined SAQ A and Attestation of Compliance (AoC) for you, available for you to download in your account’s compliance settings, and no action is required on your part to submit further proof of your PCI compliance.

While if one implements their own card details collection like in this video, to show PCI compliance they must meet all the requirements in the 40 page SAQ D themselves.

But at the end like you said its all about providing choices and people understanding the choice they make.


There’s certainly a trade-off: one could implement it with the approach demonstrated in the video (no coding required and yields a 100% native app) vs. downloading the code and integrating Stripe’s SDK or Stripe.js/Elements, potentially creating a hybrid app. With the former approach, the development time is minimal, however, there is more “paperwork” with filing for PCI compliance, with the latter approach there is more time spent on development, but smaller effort on the compliance side.


Do you work for Backendless? I sent an email to them asking some questions a few weeks ago. Would appreciate an introduction to someone from sales.


Yes, I do. You can contact me directly at


I been reading this thread as I have a lot to learn on this front. This conversation has been incredibly valuable. Thank you for sharing and thank you for providing a tutorial that integrates with Backendless on this front. This is a wonderful value!