Spreedly API spec - Integrate once and get 120 payment gateways


I know virtually nothing about Spreedly but what little I’ve seen echoes your impression that they don’t actually integrate via SDKs for the mobile platform

-Spreedly stores credit cards safely and allows companies to avoid setting up their own PCI compliant servers. They also integrate with 220 gateways worldwide for you so you only have to integrate once with Spreedly.
-I believe this is true about the SDK. I read in the spreedly documentation that phones are inherently insecure because they can be jail broken and also because it is impossible to send the transaction directly from the phone to the payment provider. It must go through a backend: https://docs.spreedly.com/guides/mobile/
-This increases complexity for PCI compliance slightly as well.

I think, like you say Sue, to integrate it with a specific backend is a good idea, whether its Spreedly or Stripe. For me personally, Bubble is very convenient because thats where ive built everything else, so I can’t objectively say which solution is the best :slight_smile: . Moreover, there are 200k+ users on Bubble and they are growing very quickly at the moment, so it could make Dropsource more appealing to a “self-growing” audience.

Sean mentioned Spreedly costs money. Very true, but Spreedly can give access to payment providers that are cheaper than Stripe is. I did some math yesterday for my use case in Mexico where Stripe is slightly more expensive than other providers. I compared Stripe in Mexico which charges 3.6% plus 3 pesos (~$0.15 usd) per transaction, vs Conekta.com (essentially the Mexican Stripe) which charges 2.9% plus $2.5 pesos per transaction. When the monthly transactions hit approximately 50k USD, combining Spreedly and Conekta is the cheaper option. I don’t know how it would be in other countries, but that could lead to substantial savings if monthly transactions are higher than 50k in this use case. Since Dropsource is focused on larger enterprises more so than small business, Spreedly is a clear winner (at least financially) in my view and I think its a compelling argument for a large business. If i’m Loreal, Lyft or Mcdonalds, its a no-brainer.

Another factor to consider that favors Spreedly is that you would only need to integrate once. Spreedly has integrated with all these gateways, and you can add a new gateway to your Spreedly environment very easily. With a Stripe plugin only, a big business is back to square one if they want to use their Dropsource app in a non-stripe country (26 countries at the moment).

Lastly, Dropsource is all about speed. Prototype quickly and get through the feedback cycle as soon as you can to improve your product. Being able to switch payment gateways extremely fast aligns well with that idea.

-At the end of the day i think its a judgement call. A Spreedly-Bubble integration could work, and so could a Stripe-Bubble integration.


Lot’s of good discussions here…

Personally I would never use Spreedly even if it’s possible due to it’s high monthly price.

I’m interested in being able to use Stripe as a standalone integration. Bubble seemed way too confusing for me to grasp, at least during the few hours I spent on it, and I think it’s very important that Dropsource not be dependent on another platform for such a highly sought after feature. Optimally Stripe integration would be just like the PayPal integration, standalone and independent. I use Stripe exclusively for payment processing due to it being way better than PayPal.

While Spreedly may have advantages for big corporations it in no way would be an easy plug and play like solution that Dropsource needs or be something any of my projects or potential clients would want to pay for. I highly doubt anyone here is working with McDonald’s or any other super large corporation.

Most low code platforms have a user base primarily made up of citizen developers. I assume this is true with Dropsource. I personally would never be able to pay the spreedly monthly or api fees.


Good points @Asger and @mackenly.j.
One thing we need to look at is a balance between desirability, affordability and feasibility.

Ideally we all desire to have a payment system that will work in several countries and also independent of any one backend.

At the same time it has to be something most of the userbase of the platform can pay for.
It is only Dropsource who can say who current userbase is and who their target it. Eventually how affordable a platform is can also affect the kind of users it attracts.

The there is one of the most important aspect, feasibility. As i mentioned earlier from my little understanding, spreedly is designed for the web and if you want to use it on mobile, you will have to create your own forms, get the card data from the form and send it to save it securely on spreedly servers. The problem here is that this is still not save as sensitive data can hit your server therefore making it very hard to be PCI compliant.
I’ve also looked at the Stripe mobile sdk and what Sue mentioned is correct. It requires some integration with a backend to work. Specifically it will requires you to expose an api endpoint in your backend that will generate some form of a session key.

So in terms of desirability, spreedly is the winner here.
Spreedly may be affordable or not depending on whether you’re a big business or small one.
But in terms of feasibility it looks to me like Stripe is the clear winner. And because stripe requires some integration with a backend a backend platform has to be chosen and personally i’m happy with Bubble since i’m a bubble developer and i also think bubble and dropsource work together.
I’ve actually mentioned before that i wish Dropsource and Bubble could merge. I don’t see it happening any time soon because of their funding situations.


Thanks for all these comments guys, feeding them all into the discussion. And cheers @seanhoots for summing up those key factors, you’ve hit the nail on the head re the competing concerns here and I think your analysis indicates why @Nate thought of a Bubble-specific Stripe integration…


@Asger I just contacted Stripe about the issue of the stripe checkout not working in android webview unless you change the UserAgent.
And their response was that they’re aware of the issue and may fix it in the future but recommended using the Stripe Element to create forms to collect card details which will work well in all webviews.

I’ve tried Stripe Elements before and even started working on a bubble plugin for it.
I still like the Checkout button though as its so easy to integrate requiring no work at all.

So @sue is it possible for your engineers to expose the setUserAgendString for the Webview element in the Dropsource eidtor so that those that still want to use Stripe from a webview can do so?
If this property of webview is exposed we can easily use the workaround i posted above. I’ve tried it and it works perfectly.
It’s really painful to always go back to code to just add this simple like.

Even when there is a native stripe element in dropsource there are still going to be users who will just be using dropsource to convert their with the webview. So been able to get the stripe working in a webview will be a great addition to the platform.

Webview User Agent

Let me check with engineering on the web view question…


Android team are discussing adding this, sounds like it would be straightforward to implement…


@seanhoots thanks a lot for supporting with this, completely changes the game. I have never done something like this before so it will take quite some effort from the looks of it. My app is near completion, I “just” need this. I have found these course on Udemy that go through it, but perhaps you have a better recommendation for learning about how to do this.


-just out of curiosity. This should be possible to do with the express form Spreedly has built as well, right?

I just saw your other discussion about storing passwords in device variables to log your user in through the web view. Will that be required in order to pull this off?-- My guess is no, since it just needs an amount to charge.

Another question: Do you know if this will allow for saving the credit card information? I know in the PayPal plugin you only need to enter the credit card details once and it keeps it for the next time the user wants to make a purchase.


Technically it should.
But you will have to try to know there are no issues like how the Stripe one has an issue on Android unless unless you do the workaround i explained above.
I looked at their documentation on the express integration and it will require some bit of javascript.
But you can hire some bubble element plugin developer to implement it for you if you don’t have some programming background.

You’re right. This is one of the reasons. In bubble if you want to use the Stripe Checkout popup, it requires the current user to log in.

Yes you can implement saving the card for future transactions. That shouldn’t even be hard to do.
In fact you can easily implement Stripe integration using the API except that one step of collecting the card info.
In bubble all the stripe calls are done through API calls. That means you can easily create a stripe swagger.json and make the calls in dropsource.
The only one issue is collection of the card details which requires having a UI form element and some jaavascript for processing. But after this stage everything is through API calls.


Okay thanks for the tip about bubble developers, I will look into that, although I am on a very limited budget so I don’t know how feasible that is at the moment.

Yes you can implement saving the card for future transactions. That shouldn’t even be hard to do.
In fact you can easily implement Stripe integration using the API except that one step of collecting the card info.
In bubble all the stripe calls are done through API calls. That means you can easily create a stripe swagger.json and make the calls in dropsource.
The only one issue is collection of the card details which requires having a UI form element and some jaavascript for processing. But after this stage everything is through API calls.

I may not have followed you 100% here. Do you mean that once the user has filled out the card collection form once, the second time the API request can be done directly from the app, using that users Stripe token?


Yes. If you have a stripe token for a charge, you just need to make an api call and this can be done easily through Dropsource API.
In fact if you’ve used the Bubble stripe.js pluging before, all the calls you can make are api calls which can easily be done in dropsource by providing a swagger spec. The only non-api feature in the stripe.js plugin is collecting users card details to obtain the stripe token.


Just a headsup that the android web view user agent string setting is in development and we’re hoping you’ll see it in the platform next week…


Hi Sean,

I am thinking about a strategy for setting the webview up with Stripe.

I have been told that it’s not possible to pass information through the webview to Bubble. Is that true? I am wondering what the process for logging the user in is when i forward them to my Stripe plugin in bubble.

Do you do a normal post request to the backend? Perhaps you a guide sitting around somewhere…


Who said it’s not possible?
It should be possible through the url parameters.
For stripe you can just pass the users email address through the parameter and retrieve it for the stripe checkout.


Not sure I am remember who said it, its a while ago.

Interesting about the email. Does this mean the email is enough and we don’t need to pass the password in a device variable? I believe you mentioned above that the user has to be logged in.


Yes initially I thought the bubble stripe checkout needed Current user, but later realized it was my own specific application that I needed the Current user (because I was saving the card to the current user).
In general all you need is an email address.
You will only have to deal with the logged in user if you save the users card against the user.
And even in that case I’m thinking you can retrieve the card using an api call in dropsource and pass that to the webview through url parameter.
Note I haven’t tested any of these, so right now they’re just ideas but I can’t see why it won’t work.


Are you sure saving the card to the user in Bubble is the best way to do it?

I think it might be better to save the cus_ id and then you charge the user instead of their card token.

To make a card available for later charging, including subscriptions, create a new Customer instead of a Charge. Be certain to store the customer ID on your side for later use. You can subsequently charge that customer by passing the customer ID—instead of a card representation—in the charge request.


Depends on what you think “Card” means.
By card i’m not referring to storing the credit card details like credit card number, expiry and CCV.
Stripe has a card object that contains information such as a card_id, last 4 digits, card type (e.g. visa).
This allows you to save multiple cards to a single customer.
If your application just allows saving one card, then its enough to just store a cus_id and use it for charging like you describe.

But if you want the user to save multiple cards on their account then you will have to deal with the stripe card object.
This will allow you to show the user what cards they have attached to their account, to give them the option to update the card information and also to use this information to display an error message such as – “Your card has expired, please update your information”.
Think about how Amazon allow you to save multiple cards to your account and view and update these cards.
Amazon is not saving these credit cards sensitive information directly in their database. They only have a card representation in their database that they can show to users.

So in my setup my bubble database has a Card object (card_id, last_4_digits, type)
And each User has a list of Cards.
This is why i mentioned at first that needed to log in to have access to Current User so i can retrieve their list of cards.
But what i’m thinking now is that i can display the cards to the user in dropsource, then when they select the card for a payment, pass the card id as well as the email of the user as url parameters to the webview.

Note that when you create a stripe charge object with only a customer id, the default card is charged.
In the case where the user wants to use a different card for a particular payment without making it the default card, you will have to pass the card id as well as the customer id in the charge call.


A few moments ago, I deployed a patch which includes a new property on the Android Web View element: User Agent. Leaving this property blank will just use the default, system-provided User Agent. But if an explicit value is provided, it will use that instead. Hopefully this will enable the Stripe Checkout workflow until we have a more formal method of doing it. Let us know if you encounter any issues with it!


Thanks @scheatham, it works.