Spreedly API spec - Integrate once and get 120 payment gateways


#1

Hi out there, And @mackenly.j @seanhoots @sue @wade :slight_smile:

I am trying to add a payment gateway to my app and am exploring different options (can’t use the paypal plugin because of issues with currency compatibility). I am using bubbe as my backend. I wanted to ask if any Dropsource users have experience with connecting with a credit card vault service named spreedly?

From the looks of it, it seems like you could fairly easily connect to spreedly with an API specification file. The benefit of spreedly is that you would have access to 120 payment gateways all over the world, while also storing peoples credit card information in a PCI compliant way. And you only need to integrate once! Theoretically it sounds nice, but am not sure how feasible it is. Any input from wiser people than me would be great.

The alternative way is to do it through the bubble backend, but doing it through Dropsource would just be cool!

Have any dropsourcers out there ever done this? How did it go?

https://docs.spreedly.com/
https://spreedly.com/

  • List item

Asger


#2

Hi Asger, I don’t know anything about Spreedly but one reservation I’d have off the top of my head is that in order to authenticate with the other payment gateways you often need the user to navigate away from the app and back again - that’s the part that’s problematic to implement on mobile without integrating an SDK (and in Dropsource exposing that via a plugin). From this page it looks like they advise actually processing payments with them via your backend rather than directly from the mobile app:

It also mentions using a web view, but I couldn’t honestly say whether the standard web view will support the necessary processing - and you would essentially need to host the web content outside of Dropsource. Unfortunately I don’t think it’s going to be quite as easy as integrating with the API via the spec… :disappointed:


#3

I’m by no means a lawyer or anything but I’d also like to add to @sue’s comment that you should be sure to verify that making a payment form in app and transferring it over API is PCI compliant/legal.

I personally can’t use PayPal too due to certain restrictions in the terms.


#4

Hi Mackenly,

Thanks for giving the heads up about PCI compliance, i have been reading about this too. How do you do payments if not through the paypal login?
From what I can read you need PCI compliance to do it through a webview, but if you use the one made by Spreedly you need the lowest level of PCI compliance there is.

@sue it looks like you are right. When you say you don’t know whether the standard web view will support it, what exactly does that mean?


#5

The web view is restricted in quite a few ways (as opposed to a browser) in terms of the types of client side processing it can carry out e.g. the javascript it can execute, we’ve come across it a few times in the past in terms of things like not being able to upload files, so I’m just a little wary there could be something this type of functionality might attempt that may not work out of the box… hopefully I’m wrong though…!


#6

I see. Thats good to know. I think i might have to look for other solutions than this. It seems like it might complicate rather than simplify matters.

Wouldn’t life be easy with a stripe plugin! :innocent: :upside_down_face:


#7

Stripe is the ultimate payment platform!


#8

To add to the discussion, i personally think Dropsource should implement Stripe themselves instead of waiting to finish the plugin system for third parties to implement it.
I strongly believe every platform like Dropsource needs to provide basic elements and for mobile app, a payment system is very essential.

Paypal is very restricted as has been discussed several times here so Stripe should be provided.

You don’t have to implement all the different options available with Stripe (there are a tons of them), you implement the basic and most frequently used ones and let 3rd parties add more features when the plugin system opens up.

This is the route Bubble took and it has worked very well.
Out of the box basic Stripe is available in bubble. Later someone implemented a stripe.js plugin providing extra features. Then i recently added a plugin allowing payment request button powered by Stripe- that enables accepting Apple Pay, Google Pay and Microsoft Pay in your bubble app.
I think Dropsource can follow this strategy.


#9

@seanhoots I like your idea very much. The faster Stripe is here the better.

@mackenly.j i have also worked with both Stripe and Paypal, and Stripe is a clear winner in all aspects I can think of from pricing to functionality.


#10

Hi @seanhoots, thanks for providing this interesting take, definitely seeing a lot of value in it. I’m going to make sure the rest of the team see this feedback. :+1:


#11

@seanhoots I am curios about plugin development. What is typically the amount of work required for a developer to build a plugin like the Stripe plugin discussed here? Would such a thing typically require collaborating with Stripes own developers?

Also, while waiting for something like a Stripe plugin in Dropsource, do you think it would be possible to use a webview to forward the user to my own Bubble page and use the Bubble plugin (considering the potential limitations of the webview that Sue mentioned)?

Thanks for your time.


#12

Hi guys, just a headsup that the engineering team is going to look into the possibility of integrating Spreedly SDK.


#13

That is excellent news!!


#14

Personally i will prefer to see a Stripe Implementation that covers most of the stripe payment options than see a Spreedly implementation.
My main reason is pricing. Spreedly charges a monthly fees (lowest $200/month) on top of a fees per API call. A credit card transaction from spreedly may take 1 to 3 API calls.
And i’m not sure if you will still have to pay the charges from the payment gateway like Stripe.

I looked at all the several other payment gateways Spreedly provide and i think most of them are not what most people will use.
Stripe has tons of options that I think will probably cover most of the markets that those other payment gateways work.

Also if i’m not wrong i don’t think Spreedly has an Android/IOS SDK to collect payment information.
What they have is a Javascript sdk, IFrame and direct method. So in a mobile environment you will be left to use the direct method, which means users credit card information can hit your server making it hard for you to meet PCI Compliance.
I believe Spreedly currently is more geared towards web than mobile.

Based on this reason i personally suggest going with Stripe and try providing a lot of the stripe options as much as possible.
Almost all bubble applications are using Stripe and it seems so far its been enough in most cases.

Hopefully your engineers after looking into this will come to a better understanding and make the right choice for us.


#15

Note that currently the Dropsource plugin system is not opened yet.
Unless you want to consider creating APIs endpoints as some form of a plugin.
In Bubble world there are two kinds of plugins, API Plugins and Element plugins.
API plugins are kind of easy to do, you can think of them as similar to how you add swagger specification to provide API endpoints in Dropsource.
Element plugins are a whole beast which requires a javascript programming background and understanding of the bubble plugin system (which has some learning curve).
An element plugin requires writing code and can take anywhere from about 2hrs to 100hrs. My Air Date/Time picker plugin in bubble has about 500 lines of code and i’ve put in over 100hrs of work.

In most cases, both API and Element plugins you don’t need to contact the service provider like Stripe. Most element plugins are based on existing (open source) javascript/jquery libraries.

Again since we’re still waiting for the plugin system in dropsource no one can comment on it.
Technically if you already have a users card stored with stripe, you can create API endpoints for charging the card.
The main issue is how to collect the users payment information without letting the data hit your server.


#16

Simple answer YES, but with a catch.
The Stripe checkout button should work in a webview on IOS. Unfortunately on android you have to add some small one line code to the webview for it to work. This means you will have to export your code and add that line.
I’ve tried it on android and can confirm it works.

So for whatever reason, the Stripe checkout in a webview works out of the box in IOS but doen’t on Android.
So the hack is to trick the Stripe to think webview is running on IOS device by adding the following line in your android source code to the webview code.

webView.getSettings().setUserAgentString("Mozilla/5.0 (iPhone; CPU iPhone OS 9_3 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13E233 Safari/601.1");

One thing to consider though is how to transition seamlessly from your native pages to the webview and back and shared data between them.


#17

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 - so have passed this info back to make sure we’re all on the same page. I don’t think engineering had actually done any investigating into this, they were really just opening the door to looking into integrating a payment provider, so no decisions have been made or anything, just a high level conversation at this stage - which you guys are very much part of… :slightly_smiling_face:

Re the plugin system, we still have a lot of unknowns around what that is going to look like, what developing plugins will involve etc. It’s also possible that the platform itself will be undergoing significant changes to build out some more core functionality in conjunction with the plugin system opening up - we’re in slightly uncertain territory at the moment so please bear with us… @seanhoots If you have any initial thoughts around what your expectations would be as a prospective plugin developer based on your experiences with Bubble though I’d absolutely love to hear them…!


#18

Another quick update here guys, it turns out engineering did actually look into Stripe integration before but there were some potential complexities around authentication and how tightly coupled it is to your backend - it could pose some challenges in terms of integrating with the Dropsource editor. Will keep you in the loop as we explore this stuff…!


#19

It looks like it might be more feasible to integrate with Stripe if we do it in conjunction with Bubble integration - what would you guys think about a Stripe integration that only works if you’re using a Bubble backend…?


#20

p.s. If any of you are using an existing Stripe plugin with your Bubble apps could you link to it so we can check it out…?