I’ve integrated with Stripe.js and my system includes recurring payments (I’m handling the scheduling system myself, not relying on Stripe for that).
What I’m trying to do is make it so that on the 1st of the month, it checks all of the payments scheduled for that day and processes them all sequentially.
There could be tens of thousands or more.
I have everything working, except for one issue. My issue is that the API Workflow runs on the list of scheduled payments, but it times out and says the app is too busy. Maximum, it could reliable handle 25-40 sequential payments, before timing out .
Does anyone know how i can get it to be able to handle as many payments as I need to process?
Now that we have the ability for an api workflow to call itself, I think you should be able to break this into batches to get over the (sometimes referenced as 4 minute and sometimes 5 minute) maximum duration for a workflow.
Here’s a quick mockup that uses a list of contacts:
You can probably optimize and remove the batch_end, because if you have the batch size and start, you know the end…but in doing this mockup I wasn’t readily able to add the batch size to when filtering the item’s…probably can be done though.
I haven’t tested this a lot, as I normally offload these types of things to an external server.
EDIT: important piece missing…A condition that halts the loop once the end of the list is reached!
But, even with this, is this not going to take an extraordinarily long time to complete? If there are indeed “tens of thousands” of records, and OP is getting 40 processed per timeout period, it’s going to take more than 20 hours to process 10K.
So, I think letting Stripe do all the subscription mgmt seems like the right answer here.
And thank you @keith for the suggestion of using Stripe directly. Unless I’m mistaken, it looks like I would need to use Stripe’s Billing/Subscription system in order to do that - but from what I can tell (unless I’m seeing things wrong), it doesn’t have a way for me to charge an application fee with the subscription system.
Am i missing something?
(Because you are correct - if there are a look of transactions, it will take a long time to process them all…)
Do you know if Bubble has some way of doing multiple concurrent calls of an API Workflow?
So that if my call can do let’s say 25 in one call, then I could somehow call it 10 times?
Or what about if I create 9 other duplicates of the same API Workflow and I initiate all 10 of them, one after another… would the Bubble servers be able to handle them concurrently, or would the 2nd wait for the 1st to finish?
And if this IS doable, then perhaps i could run 10 of these with the “looping” mechanism you’ve described here?
Thoughts?
would this work? or would some variation of it work?
I don’t think anything prevents you from calling the same api multiple times, you probably would just be constrained by the overall horse power of the app. If I had to process tens of thousands regularly, I’d be creating an external endpoint and handing it off to something more suited to this. But my first choice would be, as @keith notes, let stripe do it… But I’m assuming you are doing it yourself for a reason.
Can you suggest what external thing I could use to do it?
Would I need to learn a new software from scratch to do that?
Note: I don’t know if deciding to do it myself is the best idea - I had done it to have/keep internal control over it, mostly because I don’t know specifically if Stripe gives me full control of changing any of the “subscription” details…
Can I ask… Are we really talking about tens of thousands… TODAY? Or is the volume much lighter right now?
But to answer your question, there are several ways to do this. My personal choice was to fire up a google cloud linux instance and build a python app. It gives me a way to rapidly process data and just tell bubble when it’s done.
Lamda from Amazon is another option that allows you to launch apps and only paying for actual usage. I’m sure others here have their favorites.
You might give stripe another look, I use it for our subscriptions and very happy with it so far. As long as you are paying their fees, you might as well use their servers to process it all.
And lastly, sometimes it is better to change the business rules, and adapt to what the vendor (in this case stripe) has to offer.
Well, Stripe can model pretty much any kind of payment thing. You’re saying that there’s something akin to a one-time setup fee at the start of a subscription, yes? I think you just handle that as (1) Charge the user (the initial fee) and (2) sign the user up for the sub.
User would wind up with two invoices, which may not be ideal, but not really an issue.
There may be other facilities within Stripe for this, but what u describe is easy enough.
Is the one-time charge truly one time? (Or is it like: User has annual subscription to your site, and also some other (some interval) subscription?)
@mebeingken thanks for the feedback. No no, it isn’t tens of thousands today - I just want to build an infrastructure that can at least decently scale.
I looked futher at the Stripe.js plugin and with the Subscriptions option, it doesn’t look like I can charge an application fee, unless I’m missing something?
I’m fairly sure the stripe.Js plugin can do this, and if not, i know the stripe api can, so you could supplement stripe.Js with your own api call. Take a look at invoice items:
I have it implemented as charging an application fee as a percentage of every payment processed and my current implementation gets each recipient to create a Platform Seller connected account.
Do you have a suggestion of another or better way I could handle this?
This entire thread, i thought we were discussing payments to you, not payments to sellers… I’ve not dealt with sellers, so I’ll leave that for the experts!
Yeah. The original post is “why does Bubble suck for iteration?” (A: There’s no technical explanation. Bubble is that way for reasons that aren’t totally clear, but apparently relate to cost.)
The rest of this is about Stripe features and those are very extensive and nobody uses all of them, so the answer is just “read the Stripe docs which are more or less pretty good.”
The subtext with stripe is that honestly the built in (minimal) Stripe support is good for many use cases. And I’m sure cobubble’s plug in is fine too, but if you are getting fancy with Stripe, just set up your own API calls (the ones you need) in the way that you want and you’ll likely save yourself a lot of brain damage.
(I’m super ambivalent about Bubble plug-ins that just set up an API for you. It’s not hard and though installing the plug-in saves you time at the outset, it may not in the long run. Bite the bullet and configure your own calls and then you’re not reliant on the plug-in “author” and their assumptions.)
Yes, I’m doing charges on behalf of Seller connected accounts, and then taking off an application fee from each charge.
It looks to me like Stripe has some limitations when it comes to handling subscriptions on a platform…
So hypothetically I’m going to handle this in Bubble, would the best way be to create an API Workflow (like @mebeingken described above), and have it keep calling itself until complete?
And if the list is very long, then I could call that API Workflow 5-10 times in quick succession?
Would Bubble be able to handle this if I increase the capacity/units?
