#cheezdude

1 messages · Page 1 of 1 (latest)

serene sigilBOT
low bobcat
#

And what do you mean by a 'parent/child structure'?

patent imp
#

req_Qu72jBIcWxvHFg

#

The parent/child structure is intended to represent the relationship between our organisations headquarters and their branches/sites

#

so a user would subscribe to a product for a given branch (child) but the merchant of record would be the HQ (parent) connected account

low bobcat
#

And you're attempting to make API calls involving the child account (as o_b_o) without a direct connection from the platform?

Platform -> HQ -> Branch
??

patent imp
#

I'm trying to make an API call authenticated as the child account, but setting the parent as the obo. A fee is then added as well, which should go to the platform. If I understand you correctly.

low bobcat
#

call authenticated as the child account, but setting the parent as the obo
Yeah, that won't work

patent imp
#

ok.... thanks, perhaps we need a rethink to work this out

low bobcat
#

I can see 3 accounts: acct_1M7gggFsJldiqk4P, acct_1M7ghcC6y4IJupI8, acct_1M4PN7CETnRl16Iu

#

Can you help me understand which is which in your scenario?

#

You're trying to set o_b_o as acct_1M7gggFsJldiqk4P when authenticated as acct_1M7ghcC6y4IJupI8, but there's no connection between those 2 accounts

patent imp
#

Sure, so:

acct_1M7gggFsJldiqk4P = Parent
acct_1M7ghcC6y4IJupI8 = Child

#

I think the other is the platform

#

How would we create a connection between them? If there is a way to do this it might be what we're missing in setting up these relationships

low bobcat
#

Well, if acct_1M7gggFsJldiqk4P is the parent then it has no relation to its child (acct_1M7ghcC6y4IJupI8)

#

They're both just directly connected to the platform, which explains the error you're seeing

patent imp
#

yes that makes sense, and is what I thought

low bobcat
#

But you can't do this tiered levelling of Connect

#

i.e. a platform within a platform

#

The model you've described includes 2 platforms - acct_1M7gggFsJldiqk4P (the parent) and acct_1M4PN7CETnRl16Iu (who's API keys you're using, and both other accounts are connected to)

#

Not sure what purpose acct_1M4PN7CETnRl16Iu serves? Seems redundant?

patent imp
#

so that would be our platform which our organisations pay their fees to, so "us" in this model.

low bobcat
#

Yeah, you're going to need to model this differently

#

Can you outline how you envisioned this working in context with the account IDs you've shared and relevance to the API request? Trying to think of an alternative way

patent imp
#

Sure - I'm just on a call right now but will fire this over as soon as I can. Thanks so much for your help so far

patent imp
#

So, the way we would like this to work is as follows: A customer would exist under a child connected account: acct_1M7ghcC6y4IJupI8. This represents an individual site, and the customer being a customer of that site. The customer would visit our application and see the products associated with that site (acct_1M7ghcC6y4IJupI8). They would subscribe to one on a monthly basis and a subscription would be created which sends the funds to the site account (acct_1M7ghcC6y4IJupI8) but makes the parent HQ account (acct_1M7gggFsJldiqk4P) the o_b_o. In addition, a percentage charge would be taken from the subscription and sent to our platform (acct_1M4PN7CETnRl16Iu) as a fee for using our service.

So our platform offers the service to a number of organisations (parent) which may optionally have a number of sites (children). Hope this helps.

low bobcat
#

They would subscribe to one on a monthly basis and a subscription would be created which sends the funds to the site account (acct_1M7ghcC6y4IJupI8) but makes the parent HQ account (acct_1M7gggFsJldiqk4P) the o_b_o.
I don't believe you can specify the platform on o_b_o. You'd just use destination charges instead.

#

Ultimately though you have one too many levels of Connect here to accomodate the flow of funds you're describing

#

Let me check with a colleague and see if they can think of a better way to model this

patent imp
#

Ok thanks - if not there may be another way we can model it internally and do away with the need for nested parent/child accounts. I'll check here too.