Is it possible to integrate within Adalo a (“bank”, “Loyalty”) account in which a user can top off to add funds and pay for items using the credits in that account.
The easiest example I can give is the Starbucks app.
Where users can top off their credits and pay using credits within the Adalo app.
Is this at all possible?
All you need to do is to find a service that offers that and then link it through the database.
The alternative is that you just create a trust fund and money is stored in there.
Any links or some reading I can do on the topic you presented, of trust fund and storing money in there?
Or additionally, how to link third-party (external) “plugins” or whatever the like to the Adalo Database?
I’ve read Adalo Documentation and didn’t see anything about it.
Appreciate the help!
Hello there!
Not sure if my use case is similar to yours, but I’m building a yoga studio booking app. Users are required to buy class packs (1 credit, 3 credits, 5 credits, 10 credits, etc.) before they can book classes. This sounds similar to what you want to achieve.
Instead of buying class packs, you can have it as “top up credits”. Use an input field and Stripe component to achieve that. The Stripe component should pull the amount the user keys into the input field.
You’ll have to set up the logic too:
Hope that makes sense! I’ll share more when my yoga studio booking app is out, maybe it could help you and others who are trying to achieve something like this 
Hey Vance - that actually sounds pretty spot on.
A couple of Qs:
Instead of credits, I can have set dollar amounts that can be packages in Stripe. Once the purchase is complete, the part of recording the payment to the balance of the user’s account seems to be the troubling part.
Additionally, how do you make products only purchaseable by using “credits” or aka, the user’s balance? Are you using some If Balance’s Value > 0, show products’s check out button, else show checkout button as hidden? Or what other logic scheme are you using?
Your add/deduct logic is what I am looking for. Any help/guidance you can provide would be greatly appreciated mate.
Hey Kevin, long reply ahead… But I’m gonna share some screenshots of the app we’re building currently so you’ll have a visual rep in your head. The design is still very raw because we’re ironing out the logic first haha.
Recording payment/credits to the balance of the user’s account:
For us, when the Stripe payment is successful, we’ll add the amount of credits they bought to their existing balance. Because there’s a validity date too, we have to add to the user’s existing credits’ expiry too.
Apart from that, we’ll create a payment record in a separate database that has a relationship with the users, so it appears in their transaction history:
And there must be some feedback to the user that the payment went through, so it’s good to link them to a payment successful screen:
For the second part of your question on how to restrict users from using only credits, here’s how we’re doing it. When a user clicks on the “confirm booking” button, a credit will be deducted from the account:
But it must only happen “sometimes”, ie. when the user has more than 0 credits:
For your case, if there’s a specific cost to the product, you can use the magic text. Eg. You’ll only allow users to purchase/checkout the product if their balance is greater than or equal to the product cost.
If they don’t have enough balance in the account, they’ll be sent to a screen that prompts them to top-up. In our case, it’s insufficient class credits and they’ll have to purchase a class pack before continuing:
Hope this makes sense and helps you with figuring out the logic. As mentioned, when our app is ready to test, I’d be happy to send you the preview to help you with your own app’s logic and user flow (if it’s useful). In return, you can send any feedback or bug reports (hopefully, minimal)
Cheers mate
UPDATE: I used a list for the “Book Class” page, which is for the user to confirm the booking. That shouldn’t be the case. It should be a group of elements by itself, instead of a list, to prevent more than 1 record appearing on this page.
Hey Vance,
Just wanted to send a note of huge thanks for putting such a detailed explanation. I’ve yet to digest it all, but I really appreciate it.
This might be a silly Question but entertain me if you will.
I’m assuming you’re making a mobile app, which the other assumption is that you’re going to push this ultimately to either Apple App Store or Google Play (or both).
I see you implemented Stripe.
Any purchases that your customers make through Stripe are subject to Apple’s in app purchase as well? (30%). And whatever Google Play may charge for in-app purchases.
Or am I mistaken? In other words, paying double (Stripe Fees + In app Purchases) will eat too much into the margins. Or is it simply that you only pay Stripe Fees, and no other payments to Apple/Google Play.
Hey Kevin, glad to help
Yes, we’re building a mobile app.
Good question, actually. I doubt we’ll have to pay Apple for that because we’re not using Apple’s in-app store to perform the transaction — we’re using Stripe.
I think Apple’s in-app store is more for digital services and goods. In those cases, I believe it’s mandatory to use their in-app store to sell, say, a mobile game perk or a digital subscription to gated content on your app.
For us, we’re an online yoga studio now, but we’ll eventually provide in-studio classes. We’ll have to clarify on our end too haha.
Hope this helps!
Hey Vance - wanna leave me your e-mail? I’ll message you off from these boards, so we can discuss. I think we’re in the same boat. Ultimately, what we’re trying to accomplish is through Stripe, and not having to pay in-app purchase fees IN ADDITION to Stripe. That would be major no no. I doubt I can get Adalo to give me the answer to our Qs, but I’ll do some research and get back to you via e-mail.
Thank you again for being a rockstar with your detailed reply.
Just throwing this out there -
From what I can read and gather, it seems like in-app purchases are for digital like you said. Where pricing for services can flow directly through Stripe. As in, we’re safe, no double - dipping.
Hey Kevin, sure. You can reach me at hey (at) vancewong.com.
Yea, we’re safe because we’re not selling digital goods or services like game perks and such (eg. cosmetic items in games, diamonds or gems as in-game credits, etc.).
I’ll be glad to test out your app too when it’s ready 
Cheers
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
