IAPhub Registration Payment Logic

Hi everyone,

I currently have a working setup using IAPhub to handle ad submissions, and I’m successfully limiting the number of posts per user** using Adalo logic. That part works great.

However, I’m trying to implement a **€1 yearly registration fee (for content viewing access), and no matter how many times I tweak the logic, I can’t get it to reliably trigger the correct paywall or update the user fields properly.

ChatGPT suggested switching to Stripe + Make.com where I could simply use a webhook to set fields like hasAccess = true, etc., but there’s a concern:

Since my app is published on the Google Play Store, and the registration fee gives access to digital content, Stripe may not be allowed. Google requires Google Play Billing for digital content subscriptions.

So I’m wondering:

If I stay on the Play Store, I probably must use IAPHUB (which uses Google Billing).
Or if I switch to Stripe, it might work more easily, but I might not be allowed to charge for digital content inside the app.

Has anyone successfully implemented registration payments with IAPHUB in Adalo? Or would switching to Stripe (and handling things outside the app) be a more reliable approach?

Any advice or experience is welcome

Thank you in advance!

Just to summarize: ad submissions work perfectly — no issues at all.
But the registration payment (access_view) is the part that simply doesn’t work, no matter what I try.

Hello darkness, my old friend,
Has my app come to an end?
There is no more free advice,
Everybody has a price,
But I don’t have money at all…
Sound of sorrow.

1 Like

Hi @Domba,

IAPHub instructions are quite comprehensive and if you follow them properly, you can set up IAPHub payment with success.

What you need to understand that IAPHub Start component gives you the info if the user is subscribed or not, and for which plan. After that you can direct user to one path or to another path, and implement your logic there.

Setting up Stripe + Make properly is no easier than IAPHub, especially that you’ll have to develop the callback to Adalo by yourself, use Collections API in Adalo, and understand how Stripe webhooks work. They have an excellent documentation but it contains a lot of information.

Of course you can set up a simple Stripe one-off payment and do not care about callbacks.

But as you’ve mentioned, this content viewing can be treated as a digital purchase by Google moderation, so there is a chance the app could be rejected.

Best,
Victor.

1 Like

Hi @Victor,

First of all, thank you so much for taking the time to respond — I really appreciate it!

Just to clarify the situation:

The payment for ad submission works perfectly. The premium_1godina product (100 €) is correctly recognized by IAPHUB, and the user gets access to the “Submit Ad” screen without issues, and everything is connected through Make — webhooks are working.

The problem is with the registration payment. I’ve added a second product in IAPHUB called access_view (1 € per year), and it’s in a separate group from the ad subscription product. It’s correctly added to the same paywall in Adalo.

However, when a user purchases the access_view product (intended only for viewing content), Adalo/IAPHUB still behaves as if they bought the premium_1godina product. In other words, it grants full access, including ad submission — which should only be allowed with the 100 € product.

It seems like IAPHUB or the Adalo component doesn’t properly distinguish between the two products in different groups. Or maybe I missed something in the configuration logic.

I’m still trying to solve this, and just wanted to thank you again for your input — it really helps to know someone out there is listening!

Best regards,
Domba

Hi @Domba,

Ok, with these explanations your issue is much more clear. This wasn’t mentioned in previous messages.
IAPHub start component also returns the product ID:

Based on this product ID you can create the routing logic in your app. As an option - on the next screen.
This is not very well documented, so you have to explore and experiment. Also you can contact IAPHub support - they usually respond to user’s questions.

Best,
Victor.

1 Like

Thank you so much for taking the time to help me — I truly appreciate your guidance and the way you clarified things.

Your support really means a lot — especially since I’m doing all of this on my own. Thanks again!

Best regards,
Domba

Hi again,

I’ve been using IAPHUB for over a year and half and everything works fine for my main subscription (premium_1godina) for posting ads and viewing content. Now I’m just trying to add a second, smaller subscription (access_view, 1 €) that gives users view only access to content.

I created a new product group for access_view in IAPHUB, added it to the listing, and connected it to Google Play.

I followed Victor’s advice and tried using productId and extra fields (hasAccess and productId) to separate the two flows in one IAPHUB Start screen and one Paywall but it doesn’t work. The problem is: after purchase, the app treats both products the same, and users with just the access_view plan can also post ads, which they shouldn’t be able to do.

Victor already said this isn’t well documented. I’ve tried all possible logic combinations to separate the two subscriptions, but nothing has worked so far, that’s why I had to contact IAPHUB support directly. But they just told me to check the documentation, which doesn’t explain this situation. I think they also misunderstood what I was asking, like I don’t know how to use the component, when actually I do. I just need help creating clear separation between the two product types after purchase.

I use ChatGPT to help explain complex issues, but sometimes that also causes confusion. So if anyone can help me write a short message that clearly explains this to IAPHUB, I’d really appreciate it.

Thanks in advance!

Hi @Victor,

I just got a reply from IAPHUB support, and based on that, ChatGPT suggested the following logic for what I’m trying to achieve.

Could you please take a quick look and let me know if you think this could work? I’ve already tried at least 40 different logic combinations, so I’m really hoping this one is solid.

Here’s the suggestion:

:puzzle_piece: 1. “IAPHUB on Adalo only supports one subscription group”

➤ What does that mean?
Adalo’s integration with IAPHUB currently supports only one subscription group.

That means both of your products (access_view and premium_1godina) must be in the same group for IAPHUB to manage them correctly.

➤ The current issue:
You have two products in different groups, even though they’re listed on the same paywall.

As a result, IAPHUB doesn’t treat them as mutually exclusive — meaning a user can have both subscriptions active (which you don’t want).

So when a user buys access_view, they still get hasActiveSubscription = true, which incorrectly allows them to post ads.

:white_check_mark: The fix:
Put both products into the same subscription group (e.g., main_access_group):

  • access_view = Tier 1 (cheaper, view-only access)
  • premium_1godina = Tier 2 (more expensive, can post and view)

IAPHUB will then automatically handle upgrades/downgrades and recognize which level the user has.

:compass: 2. “Add a filter on the Start Success action based on the product ID”

➤ What does that mean?
On the IAPHUB Start screen, after the purchase is confirmed, you can add multiple ‘Update Logged In User’ actions.

Each action can have a Sometimes condition based on the productId.

That way, you can set different values for hasAccess and hasActiveSubscription.

:white_check_mark: For your case:
If the user buys access_view:

  • hasAccess = true, hasActiveSubscription = false

If the user buys premium_1godina:

  • hasAccess = true, hasActiveSubscription = true

You set all this logic on the IAPHUB Start screen using multiple Update Logged In User actions with productId conditions.

:repeat_button: Immediate steps:

In IAPHUB:

  • Move both products to the same subscription group
  • Ensure both are active and visible on the paywall

In Adalo (IAPHUB Start screen):

  • First reset hasAccess and hasActiveSubscription
  • Then add two separate Update Logged In User actions:
    • One for access_viewhasAccess: true, hasActiveSubscription: false
    • One for premium_1godinahasAccess: true, hasActiveSubscription: true
  • Use Sometimes conditions to route the user to the correct screen:
    • If they only have viewing access → go to viewing screen
    • If they have full subscription → go to ad posting screen

:white_check_mark: In short:
Max from IAPHUB is completely right — the core issue is using two different subscription groups, which Adalo’s IAPHUB integration doesn’t support. Once everything is in the same group and filtered by productId, the logic should work as expected.

Thanks so much in advance for reviewing this!

Best,
Domba

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.